really horrible extensions that are disabled by default but that can
be accepted by -fheinous-gnu-extensions (but which always emit a
warning when enabled).
As our first instance of this, implement PR3788/PR3794, which allows
non-lvalues in inline asms in contexts where lvalues are required. bleh.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66910 91177308-0d34-0410-b5e6-96231b3b80d8
conditions. Currently the analyzer does not reason well about
promotions/truncations of symbolic values, so at branch conditions when we see:
if (condition)
and condition is something like a 'short' or 'char', essentially ignore the
promotion to 'int' so that we track constraints on the original symbolic value.
We only ignore the casts if the underlying type has the same or fewer bits as
the converted type.
This fixes:
<rdar://problem/6619921>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66899 91177308-0d34-0410-b5e6-96231b3b80d8
This solution is much simpler (and doesn't add any per-scope overhead, which concerned Chris).
The only downside is the LabelMap is now declared in two places (Sema and BlockSemaInfo). My original fix tried to unify the LabelMap in "Scope" (which would support nested functions in general). In any event, this fixes the bug given the current language definition. If/when we decide to support GCC style nested functions, this will need to be tweaked.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66896 91177308-0d34-0410-b5e6-96231b3b80d8
include the triplet so that people that run multiple targets in
parallel, say i386 and x86_64 can distinguish between the two.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66849 91177308-0d34-0410-b5e6-96231b3b80d8
width of bitfields.
I'll be burning this down and replacing it with a properly-dispatched
implementation like the one used for types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66796 91177308-0d34-0410-b5e6-96231b3b80d8
- Notably, clang now exits with an error if it can't find a
file. This flushed out a bug in the CGColorSpace.c test case. :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66789 91177308-0d34-0410-b5e6-96231b3b80d8
class members to the corresponding in-class declaration.
Diagnose the erroneous use of 'static' on out-of-line definitions of
class members.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66740 91177308-0d34-0410-b5e6-96231b3b80d8
- This is an ABI incompatiblity, but this is not likely to be a huge
deal in practice. For now we at least generate self consistent code
instead of crashing.
- <rdar://problem/6657601> x86-32 ABI: Bitfields in small structures
are not passed correctly
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66713 91177308-0d34-0410-b5e6-96231b3b80d8
for FieldDecls so that the parser and the template instantiation make
use of the same semantic checking module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66685 91177308-0d34-0410-b5e6-96231b3b80d8
not be consulted for its size expression when operator* was called in the
StmtIterator (this resulted in an assertion failure).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66679 91177308-0d34-0410-b5e6-96231b3b80d8
template. More importantly, start to sort out the issues regarding
complete types and nested-name-specifiers, especially the question of:
when do we instantiate a class template specialization that occurs to
the left of a '::' in a nested-name-specifier?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66662 91177308-0d34-0410-b5e6-96231b3b80d8
The ElementRegion's type depends on the array region's rvalue type. If it was
a pointer type, we would get a loc::SymbolVal for '*p'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66656 91177308-0d34-0410-b5e6-96231b3b80d8
values. Indicating this in 'canReasonAbout' allows GRExprEngine to recover
path-sensitivity in some cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66628 91177308-0d34-0410-b5e6-96231b3b80d8
translation unit.
Thread the various declarations of variables via
VarDecl::getPreviousDeclaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66601 91177308-0d34-0410-b5e6-96231b3b80d8
definitions. We were rejecting tentative definitions of incomplete
(which is bad), and now we don't.
This fix is partial because we don't do the end-of-translation-unit
initialization for tentative definitions that don't ever have any
initializers specified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66584 91177308-0d34-0410-b5e6-96231b3b80d8
context of a template-id for which we need to instantiate default
template arguments.
In the TextDiagnosticPrinter, don't suppress the caret diagnostic if
we are producing a non-note diagnostic that follows a note diagnostic
with the same location, because notes are (conceptually) a part of the
warning or error that comes before them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66572 91177308-0d34-0410-b5e6-96231b3b80d8
only print the template instantiation backtrace for the first error.
Also, if a base class has failed to type-check during instantiation,
just drop that base class and continue on to check other base classes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66563 91177308-0d34-0410-b5e6-96231b3b80d8
'struct A<double, int>'
In the "template instantiation depth exceeded" message, print
"-ftemplate-depth-N" rather than "-ftemplate-depth=N".
An unnamed tag type that is declared with a typedef, e.g.,
typedef struct { int x, y; } Point;
can be used as a template argument. Allow this, and check that we get
sensible pretty-printing for such things.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66560 91177308-0d34-0410-b5e6-96231b3b80d8
to a diagnostic that will be invoked after the diagnostic (if it is
not suppressed). The hooks are allowed to produce additional
diagnostics (typically notes) that provide more information. We should
be able to use this to help diagnostic clients link notes back to the
diagnostic they clarify. Comments welcome; I'll write up documentation
and convert other clients (e.g., overload resolution failures) if
there are no screams of protest.
As the first client of post-diagnostic hooks, we now produce a
template instantiation backtrace when a failure occurs during template
instantiation. There's still more work to do to make this output
pretty, if that's even possible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66557 91177308-0d34-0410-b5e6-96231b3b80d8
done in sema, and is reflected by the existing PR3258. In the meantime,
fix PR3682 by disabling a bogus assertion (which doesn't account for +
operands).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66533 91177308-0d34-0410-b5e6-96231b3b80d8
(default: 99). Beyond this limit, produce an error and consider the
current template instantiation a failure.
The stack we're building to track the instantiations will, eventually,
be used to produce instantiation backtraces from diagnostics within
template instantiation. However, we're not quite there yet.
This adds a new Clang driver option -ftemplate-depth=NNN, which should
eventually be generated from the GCC command-line operation
-ftemplate-depth-NNN (note the '-' rather than the '='!). I did not
make the driver changes to do this mapping.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66513 91177308-0d34-0410-b5e6-96231b3b80d8
such as replacing 'T' in vector<T>. There are a few aspects to this:
- Extend TemplateArgument to allow arbitrary expressions (an
Expr*), and switch ClassTemplateSpecializationType to store
TemplateArguments rather than it's own type-or-expression
representation.
- ClassTemplateSpecializationType can now store dependent types. In
that case, the canonical type is another
ClassTemplateSpecializationType (with default template arguments
expanded) rather than a declaration (we don't build Decls for
dependent types).
- Split ActOnClassTemplateId into ActOnClassTemplateId (called from
the parser) and CheckClassTemplateId (called from
ActOnClassTemplateId and InstantiateType). They're smart enough to
handle dependent types, now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66509 91177308-0d34-0410-b5e6-96231b3b80d8
a warning and then threw away the AST. While I'm in there, tighten up the
code to actually reject completely bogus cases (sending a message to a
struct). We still allow sending a message to an int, which doesn't make
sense but GCC allows it and is easy to support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66468 91177308-0d34-0410-b5e6-96231b3b80d8
Chris Lattner
Ted Kremenek
Steve Naroff
Fariborz Jahanian
Mike Stump
Douglas Gregor
Daniel Dunbar
Zhongxing Xu
Anders Carlsson