r211420 - Driver: enhance MSC version compatibility

[Alp Toker]

On 01/07/2014 01:38, Reid Kleckner wrote:
> On Mon, Jun 30, 2014 at 3:33 PM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>
>     On 01/07/2014 01:28, Saleem Abdulrasool wrote:
>
>         On Jun 30, 2014, at 2:10 PM, Alp Toker <alp at nuanti.com
>         <mailto:alp at nuanti.com>> wrote:
>
>             On 23/06/2014 23:02, Reid Kleckner wrote:
>
>                 On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker
>                 <alp at nuanti.com <mailto:alp at nuanti.com>
>                 <mailto:alp at nuanti.com <mailto:alp at nuanti.com>>> wrote:
>
>                     Please split out and name the new dotted form
>                 something like
>                     "-msc-full-version" to avoid ambiguity.
>
>
>                 I was inclinded to overload the option because it
>                 means we don't have to diagnose this case:
>                 -fmsc-version -fmsc-full-version=17.00.0.  We just do
>                 the obvious thing of "last one always wins".
>                  Diagnosing the conflict isn't too hard, though, so
>                 let's just split the options and do exactly that in
>                 the driver.
>
>             Saleem,
>
>             Do you plan to make that change? If not I guess I can look
>             into it..
>
>         Yes, I was waiting for a response to my last message about
>         what we want to call the option.
>
>
>     The proposal was -msc-full-version because it aligns at least a
>     little with the documentation on MSDN.
>
>
>
>             The reason is that this blocks some other fixes I have
>             related to -msc-ver and the diagnostic engine.
>
>         Ill call it -fmsc-version-ex then for now and we can bike shed
>         it later if we want.
>
>
>     What does -ex signify? Not familiar with that naming scheme.
>
>     Anyway, it seems best to go with the working name
>     -msc-full-version unless something better comes along.
>
>
> You mentioned that you think two 32-bit ints is the right 
> representation for this.  What do you think of -fmsc-version and 
> -fmsc-build-number?  Then there is no need to diagnose anything, with 
> the potential exception of very large build numbers that don't fit 
> into _MSC_FULL_VERSION.

I only meant it in so far as the representation could simplify the bit 
flipping and storage in LangOpts. The old -fmsc-version was always rough 
because it exposed a detail that isn't relevant to users or particularly 
visible, so it'll be nice to deprecate.

As for the version value we receive from users and tools, I'm pretty 
sure one single input version is the right format.

That value's going to come from one of these places:

1) IDE integration, e.g. LLVM's 
tools/msbuild/Microsoft.Cpp.Win32.llvm.props.in

2) Manually taken from the user typing cl.exe /help and copy-pasting the 
version number as an argument to clang.

3) Manually taken from online documentation and passed as an argument to 
clang.

In practice we should make sure the format satisfies those use cases. I 
haven't confirmed but I'm hopeful the dotted format is all we need.

Alp.

-- 
http://www.nuanti.com
the browser experts