<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">+def err_integer_literal_too_large : Error<</div><div class="gmail_extra">+ "integer literal is a value that cannot be represented as %select{a|an}0 "</div>
<div class="gmail_extra">+ "%select{signed|unsigned}0 integer">;</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't think the "is a value that" adds anything here. Also, I'd like to see something that more directly says we don't have a signed/unsigned integer type large enough.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"> def err_integer_too_large : Error<</div><div class="gmail_extra">- "integer constant is larger than the largest %0-bit unsigned integer type">;</div>
<div class="gmail_extra">-def ext_integer_too_large_for_signed : ExtWarn<</div><div class="gmail_extra">- "integer constant is larger than the largest %0-bit signed integer type">,</div><div class="gmail_extra">
+ "integer constant evaluates to value %0 that cannot be represented as a "</div><div class="gmail_extra">+ "%1-bit %select{signed|unsigned}2 integer">;</div><div class="gmail_extra"><br></div><div class="gmail_extra">
Please rename this to something about ICEs, and move it to DiagnosticSemaKinds next to the existing err_ice_ diagnostics. (This is pretty similar to ext_cce_narrowing...)</div></div></div><div class="gmail_extra"><div><br>
</div><div><br></div><div><div>+def ext_integer_literal_too_large_for_signed : ExtWarn<</div><div>+ "integer literal is a value that cannot be represented as a signed integer, "</div><div>+ "and will instead be interpreted as unsigned">,</div>
</div><div><br></div><div>Again, mentioning integer types and not just integers would make this clearer.</div><div><br></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 22, 2014 at 4:17 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">How about something along these lines?<br>
<span class=""><font color="#888888"><br>
~Aaron<br>
</font></span><div class=""><div class="h5"><br>
On Tue, Jul 22, 2014 at 6:57 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> On Tue, Jul 22, 2014 at 3:47 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Tue, Jul 22, 2014 at 6:40 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> wrote:<br>
>> > On Tue, Jul 22, 2014 at 3:39 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> > wrote:<br>
>> >><br>
>> >> def ext_integer_too_large_for_signed : ExtWarn<<br>
>> >> - "integer constant is larger than the largest %0-bit signed integer<br>
>> >> type">,<br>
>> >> - InGroup<DiagGroup<"implicitly-unsigned-literal">>;<br>
>> >> + "integer constant evaluates to value %0 that cannot be represented<br>
>> >> as a<br>
>> >> "<br>
>> >> + "%1-bit signed integer">,<br>
>> >> InGroup<DiagGroup<"implicitly-unsigned-literal">>;<br>
>> >><br>
>> >> This should probably go on to say that we're interpreting the value as<br>
>> >> unsigned.<br>
>> >><br>
>> >> I also think we should have separate diagnostics for the case where we<br>
>> >> evaluate a constant expression (which should include the 'evaluates to<br>
>> >> value<br>
>> >> %0' part) and the case where it's a literal (where we shouldn't). We<br>
>> >> don't<br>
>> >> need to repeat things that are literally present in the source code.<br>
>> >> (Sorry<br>
>> >> for suggesting the unconditional change here, I hadn't really looked at<br>
>> >> the<br>
>> >> use cases other than the one in SemaDeclAttr.cpp)<br>
>> ><br>
>> ><br>
>> > Actually, more than this, I think the original diagnostic text was<br>
>> > better<br>
>> > than any of the updated wordings in the case of a literal. The bit-width<br>
>> > is<br>
>> > incidental; the point is that the literal doesn't fit in the largest<br>
>> > signed<br>
>> > type.<br>
>><br>
>> What about literals whose suffix defines the type, like<br>
>> 90000000000000000000UL?<br>
><br>
><br>
> Such a suffix does not really define the type. L means "no smaller than<br>
> long", not "exactly long". Arguably the new wording is better for the MS<br>
> i32/i64 suffixes, though.<br>
><br>
> ... but the SemaDeclAttr diagnostic and the "integer literal too large"<br>
> diagnostic are different problems and should have separate diagnostics.<br>
</div></div></blockquote></div><br></div></div>