r211420 - Driver: enhance MSC version compatibility

[Alp Toker]

On 01/07/2014 01:48, Alp Toker wrote:
>
> 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.

One thing we definitely *do* need a separate version option for is the 
MSVC IDE version that our diagnostics will target.

This value, used by the diagnostics engine to determine whether we print 
zero-based MSVC 2010 column numbers is currently piggybacked off of 
-msc-version which is way off, and breaking layering in the diagnostics 
code.

That hack means you essentially have to define all the _MSC_VER macros 
in your compilation just to get the desired format out of 
TextDiagnosticPrinter. It goes without saying that -fdiagnostics-format 
should really be independent of the language standard in use, so that 
IDE integrations could say, cross-compile while still displaying 
diagnostics in MSVC.

I have a patch for that brewing, in which I've tentatively used the MSVC 
IDE year:

   -fdiagnostics-format=msvc2010
   -fdiagnostics-format=msvc2010-fallback
   -fdiagnostics-format=msvc (use the latest format)

(Writing to this thread as it's useful to see the different MS version 
numbers together in context as we figure out how to represent them.)

Alp.




>
> 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