rewriting the literal when the value is integral. It is not uncommon to
see code written as:
const int kBigNumber = 42e5;
Without any real awareness that this is no longer an ICE. The note helps
automate and ease the process of fixing code that violates the warning.
llvm-svn: 129243
This patch authored by Eric Niebler.
Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&). This is especially true for the
routines that apply implicit conversions to nodes in-place. This design is
workable only as long as those conversions cannot fail. If they are allowed
to fail, they need a way to report their failures. The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state. Returning ExprResult is de riguour elsewhere in the Sema
interface. We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &. This increases interface consistency and maintainability.
This interface change is important for work supporting MS-style C++
properties. For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can. (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)
llvm-svn: 129143
enumeration type to another in C, classify enumeration constants as if
they had the type of their enclosing enumeration. Fixes
<rdar://problem/9116337>.
llvm-svn: 127514
in the LLVM test suite, this function was consuming 7.4% of -fsyntax-only time. This change fixes this issue
by delaying the check that the warning would be issued within a system macro by as long as possible. The
main negative of this change is now the logic for this check is done in multiple places in this function instead
of just in one place up front.
llvm-svn: 127425
don't let calls to such functions go down the normal type-checking path.
Test this out with __builtin_classify_type and __builtin_constant_p.
llvm-svn: 126539
especially C++ code, and generally expand the test coverage.
Logic adapted from a patch by Kaelyn Uhrain <rikka@google.com> and
another Googler.
llvm-svn: 125775
specifically targets literals which are implicitly converted, a those
are more often unintended and trivial to fix. This can be especially
helpful for diagnosing what makes 'const int x = 1e6' not an ICE.
Original patch authored by Jim Meehan with contributions from other
Googlers and a few cleanups from myself.
llvm-svn: 125745
class and to bind the shared value using OpaqueValueExpr. This fixes an
unnoticed problem with deserialization of these expressions where the
deserialized form would lose the vital pointer-equality trait; or rather,
it fixes it because this patch also does the right thing for deserializing
OVEs.
Change OVEs to not be a "temporary object" in the sense that copy elision is
permitted.
This new representation is not totally unawkward to work with, but I think
that's really part and parcel with the semantics we're modelling here. In
particular, it's much easier to fix things like the copy elision bug and to
make the CFG look right.
I've tried to update the analyzer to deal with this in at least some
obvious cases, and I think we get a much better CFG out, but the printing
of OpaqueValueExprs probably needs some work.
llvm-svn: 125744
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
Most Neon shift intrinsics do not have variants for polynomial types, but
vsri_n and vsli_n do support them, and we need to properly range-check the
shift immediates for them.
llvm-svn: 121509
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
llvm-svn: 121121
not actually frequently used, because ImpCastExprToType only creates a node
if the types differ. So explicitly create an ICE in the lvalue-to-rvalue
conversion code in DefaultFunctionArrayLvalueConversion() as well as several
other new places, and consistently deal with the consequences throughout the
compiler.
In addition, introduce a new cast kind for loading an ObjCProperty l-value,
and make sure we emit those nodes whenever an ObjCProperty l-value appears
that's not on the LHS of an assignment operator.
This breaks a couple of rewriter tests, which I've x-failed until future
development occurs on the rewriter.
Ted Kremenek kindly contributed the analyzer workarounds in this patch.
llvm-svn: 120890
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
no longer depends on Preprocessor, so we can move it out of Sema into
a nice new StringLiteral::getLocationOfByte method that can be used by
any AST client.
llvm-svn: 119481
producing warnings.
This feels really fragile, and I've not audited all other argument index-based
warnings. I suspect we'll grow this bug on another warning eventually. It might
be nice to adjust the argument indices when building up the attribute AST node,
as we already have to remember about the 'this' argument within that code to
produce correct errors.
llvm-svn: 119340
of the enumerators rather than the actual expressible range. This is
great when dealing with opaque *values* of that type, but when computing
the range of the type for purposes of converting *into* it, it produces
warnings in cases we don't care about (e.g. enum_t x = 500;). Divide
the logic into these two cases and use the more conservative range for
targets.
llvm-svn: 118735
Chandler Carruth