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 <[email protected]
<mailto:[email protected]>> wrote:
On 01/07/2014 01:28, Saleem Abdulrasool wrote:
On Jun 30, 2014, at 2:10 PM, Alp Toker <[email protected]
<mailto:[email protected]>> wrote:
On 23/06/2014 23:02, Reid Kleckner wrote:
On Sat, Jun 21, 2014 at 11:32 AM, Alp Toker
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
