<div dir="ltr">On Tue, Jul 15, 2014 at 6:27 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On 15/07/2014 15:54, Aaron Ballman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Jul 14, 2014 at 4:37 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 01/07/2014 23:02, Aaron Ballman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jul 1, 2014 at 3:50 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 01/07/2014 22:40, Aaron Ballman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jul 1, 2014 at 3:15 PM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 01/07/2014 21:53, Aaron Ballman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+1 for -fmsc-full-version.<br>
</blockquote>
What about -fmsc-extended-version?<br>
<br>
I ask because Saleem pointed out in IRC that this really isn't the<br>
full version (it doesn't include the build number).<br>
</blockquote>
<br>
It's only a temporary bug that the build number is ignored, and that'll<br>
will<br>
go away as soon as we add a second variable or more bits to LangOpts.<br>
</blockquote>
I apologize, I wasn't entirely clear with my complaint. Okay, in<br>
reality, I was pretty obtuse. :-) It's that it is optionally full<br>
information (it doesn't require the full information to be present).<br>
Eg) -fmsc-full-version=17<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The input really is the MSC full version so -fmsc-full-version is the<br>
sensible name. Let's not invent new terminology like "extended version"<br>
here.<br>
</blockquote>
There are zero options with "full" in their name. There are two-ish<br>
options with "extended" in their name (fextended-identifiers and<br>
fno-extended-identifiers), but they don't really qualify as examples<br>
for this discussion. So both of these choices would qualify as<br>
"inventing new terminology."<br>
<br>
The goal is to discuss what qualifies as a "sensible" name, and I have<br>
some (relatively weak, but valid) objections to using "full" because<br>
it implies you are required to specify the full version information<br>
when that isn't the case.<br>
</blockquote>
<br>
Oh, I see what you were getting at now.<br>
<br>
I *do* think that's a valid point given that we accept less than the full<br>
version to be written, but in principle we expect people/tools to pass a<br>
verbatim and long dotted version here with shorter forms accepted just<br>
"because we can".<br>
</blockquote>
"Expect" and "will actually happen" doesn't always match up. ;-)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And that's weighed up against the stronger argument that this gets<br>
converted<br>
to an _MSC_FULL_VER, and that the documentation calls it the full<br>
version.<br>
So there's a really neat self-documenting property to -msc-full-version<br>
</blockquote>
That is true. But it also sets more than just _MSC_FULL_VER, and what<br>
gets set here is not exactly what gets pushed into _MSC_FULL_VER.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for -msc-extended-version, the version we accept isn't really an<br>
extension, not is it an extended form of anything, given that it can (a)<br>
be<br>
short as you pointed out yourself and (b) -msc-version is crummy and due<br>
for<br>
deprecation, so we don't want to express the nice new flag as an extended<br>
form of something that's going away and irrelevant to new users.<br>
</blockquote>
It is true that this isn't really an extension either.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For those reasons I'm getting good vibes about -msc-full-version<br>
</blockquote>
I'm still not there yet. But I'm getting slightly worse vibes about<br>
-fmsc-extended-version. ;-)<br>
</blockquote>
<br>
We're generally hovering around -msc-full-version then?<br>
</blockquote>
I don't think we have strong consensus on any name. But since I had<br>
the strongest objections, I'll get the ball rolling by saying<br>
msc-full-version is reasonable enough. My objections were that the<br>
name wasn't perfectly descriptive of the functionality, but as more<br>
names are being proposed, I am starting to think no name will be<br>
perfectly descriptive of the functionality aside from the name we're<br>
replacing (and can't use).<br>
<br>
Assuming Reid still likes the name, I think that gives us at least<br>
weak consensus on msc-full-version.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let's fix forward instead of dropping this patchset from 3.5. Please commit<br>
once Aaron gives a nod<br>
</blockquote>
I don't think "fix-forward" is something we want to do here (I<br>
</blockquote>
<br></div></div>
What I mean is, let's not leave the tree in its current in-between state for too long, with a release round the corner. Either back out the original patch or fix-forward.</blockquote><div><br></div><div>The change is not based on theory, it is addressing an actual issue with use of newer Microsoft SDKs.  What you are proposing is that we knowingly make clang incompatible with a released SDK in order to accommodate a theoretical IDE's use.  I understand that this may make it more difficult for you, but, I think that making clang incompatible with a released SDK is a worse choice here.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
understand option names tend to be long-lived, much like our C API<br>
interfaces, for compatibility reasons). We either want to live with<br>
this name for a long, long time, or we hold off for a bit longer on<br>
the patch. That being said, if there aren't any further objections,<br>
I'm happy for this to go in.<br>
<br>
~Aaron<br>
</blockquote>
<br></div><div class="HOEnZb"><div class="h5">
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div><br>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org
</div></div>