[PATCH] Driver: bifurcate extended and basic MSC versioning

[Aaron Ballman]

On Mon, Jul 14, 2014 at 4:37 PM, Alp Toker <alp at nuanti.com> wrote:
>
> On 01/07/2014 23:02, Aaron Ballman wrote:
>>
>> On Tue, Jul 1, 2014 at 3:50 PM, Alp Toker <alp at nuanti.com> wrote:
>>>
>>> On 01/07/2014 22:40, Aaron Ballman wrote:
>>>>
>>>> On Tue, Jul 1, 2014 at 3:15 PM, Alp Toker <alp at nuanti.com> wrote:
>>>>>
>>>>> On 01/07/2014 21:53, Aaron Ballman wrote:
>>>>>>>
>>>>>>> +1 for -fmsc-full-version.
>>>>>>
>>>>>> What about -fmsc-extended-version?
>>>>>>
>>>>>> I ask because Saleem pointed out in IRC that this really isn't the
>>>>>> full version (it doesn't include the build number).
>>>>>
>>>>>
>>>>> It's only a temporary bug that the build number is ignored, and that'll
>>>>> will
>>>>> go away as soon as we add a second variable or more bits to LangOpts.
>>>>
>>>> I apologize, I wasn't entirely clear with my complaint. Okay, in
>>>> reality, I was pretty obtuse. :-) It's that it is optionally full
>>>> information (it doesn't require the full information to be present).
>>>> Eg) -fmsc-full-version=17
>>>>
>>>>> The input really is the MSC full version so -fmsc-full-version is the
>>>>> sensible name. Let's not invent new terminology like "extended version"
>>>>> here.
>>>>
>>>> There are zero options with "full" in their name. There are two-ish
>>>> options with "extended" in their name (fextended-identifiers and
>>>> fno-extended-identifiers), but they don't really qualify as examples
>>>> for this discussion. So both of these choices would qualify as
>>>> "inventing new terminology."
>>>>
>>>> The goal is to discuss what qualifies as a "sensible" name, and I have
>>>> some (relatively weak, but valid) objections to using "full" because
>>>> it implies you are required to specify the full version information
>>>> when that isn't the case.
>>>
>>>
>>> Oh, I see what you were getting at now.
>>>
>>> I *do* think that's a valid point given that we accept less than the full
>>> version to be written, but in principle we expect people/tools to pass a
>>> verbatim and long dotted version here with shorter forms accepted just
>>> "because we can".
>>
>> "Expect" and "will actually happen" doesn't always match up. ;-)
>>
>>> And that's weighed up against the stronger argument that this gets
>>> converted
>>> to an _MSC_FULL_VER, and that the documentation calls it the full
>>> version.
>>> So there's a really neat self-documenting property to -msc-full-version
>>
>> That is true. But it also sets more than just _MSC_FULL_VER, and what
>> gets set here is not exactly what gets pushed into _MSC_FULL_VER.
>>
>>> As for -msc-extended-version, the version we accept isn't really an
>>> extension, not is it an extended form of anything, given that it can (a)
>>> be
>>> short as you pointed out yourself and (b) -msc-version is crummy and due
>>> for
>>> deprecation, so we don't want to express the nice new flag as an extended
>>> form of something that's going away and irrelevant to new users.
>>
>> It is true that this isn't really an extension either.
>>
>>> For those reasons I'm getting good vibes about -msc-full-version
>>
>> I'm still not there yet. But I'm getting slightly worse vibes about
>> -fmsc-extended-version. ;-)
>
>
> We're generally hovering around -msc-full-version then?

I don't think we have strong consensus on any name. But since I had
the strongest objections, I'll get the ball rolling by saying
msc-full-version is reasonable enough. My objections were that the
name wasn't perfectly descriptive of the functionality, but as more
names are being proposed, I am starting to think no name will be
perfectly descriptive of the functionality aside from the name we're
replacing (and can't use).

Assuming Reid still likes the name, I think that gives us at least
weak consensus on msc-full-version.

> Let's fix forward instead of dropping this patchset from 3.5. Please commit
> once Aaron gives a nod

I don't think "fix-forward" is something we want to do here (I
understand option names tend to be long-lived, much like our C API
interfaces, for compatibility reasons). We either want to live with
this name for a long, long time, or we hold off for a bit longer on
the patch. That being said, if there aren't any further objections,
I'm happy for this to go in.

~Aaron