On Tue, Jul 22, 2014 at 3:47 PM, Aaron Ballman <[email protected]> wrote:
> On Tue, Jul 22, 2014 at 6:40 PM, Richard Smith <[email protected]> > wrote: > > On Tue, Jul 22, 2014 at 3:39 PM, Richard Smith <[email protected]> > > wrote: > >> > >> def ext_integer_too_large_for_signed : ExtWarn< > >> - "integer constant is larger than the largest %0-bit signed integer > >> type">, > >> - InGroup<DiagGroup<"implicitly-unsigned-literal">>; > >> + "integer constant evaluates to value %0 that cannot be represented > as a > >> " > >> + "%1-bit signed integer">, > >> InGroup<DiagGroup<"implicitly-unsigned-literal">>; > >> > >> This should probably go on to say that we're interpreting the value as > >> unsigned. > >> > >> I also think we should have separate diagnostics for the case where we > >> evaluate a constant expression (which should include the 'evaluates to > value > >> %0' part) and the case where it's a literal (where we shouldn't). We > don't > >> need to repeat things that are literally present in the source code. > (Sorry > >> for suggesting the unconditional change here, I hadn't really looked at > the > >> use cases other than the one in SemaDeclAttr.cpp) > > > > > > Actually, more than this, I think the original diagnostic text was better > > than any of the updated wordings in the case of a literal. The bit-width > is > > incidental; the point is that the literal doesn't fit in the largest > signed > > type. > > What about literals whose suffix defines the type, like > 90000000000000000000UL? > Such a suffix does not really define the type. L means "no smaller than long", not "exactly long". Arguably the new wording is better for the MS i32/i64 suffixes, though. ... but the SemaDeclAttr diagnostic and the "integer literal too large" diagnostic are different problems and should have separate diagnostics.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
