longer have access to the source locations we need to produce the
'replace constexpr with const' fixits, so they're gone for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147273 91177308-0d34-0410-b5e6-96231b3b80d8
case they override virtual functions from a base class. Also fix -print-stats
counting of move assignment/construction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147258 91177308-0d34-0410-b5e6-96231b3b80d8
Explicit instantiations following specializations are no-ops and hence have
no PointOfInstantiation. That was done correctly in most cases, but for a
specialization -> instantiation decl -> instantiation definition chain, the
definition didn't realize that it was a no-op. Fix that.
Also, when printing diagnostics for these no-ops, get the diag location from
the decl name location.
Add many test cases, one of them not yet passing (but it failed the same way
before this change). Fixes http://llvm.org/pr11558 and more.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147225 91177308-0d34-0410-b5e6-96231b3b80d8
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147221 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the FIXMEs in ParseAnalyzeArgs. (Also a
precursor to moving the analyzer into an AST plugin.)
For consistency, do the same with AssemblerInvocation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147218 91177308-0d34-0410-b5e6-96231b3b80d8
building related objc ASTs which require a class definition AST.
These were uncovered when testing objc rewriter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147210 91177308-0d34-0410-b5e6-96231b3b80d8
found within that umbrella directory that were not actually included
by the umbrella header. They should either be referenced in the module
map or included by the umbrella header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147207 91177308-0d34-0410-b5e6-96231b3b80d8
set of (previously-canonical) declaration IDs to the module file, so
that future AST reader instances that load the module know which
declarations are merged. This is important in the fairly tricky case
where a declaration of an entity, e.g.,
@class X;
occurs before the import of a module that also declares that
entity. We merge the declarations, and record the fact that the
declaration of X loaded from the module was merged into the (now
canonical) declaration of X that we parsed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147181 91177308-0d34-0410-b5e6-96231b3b80d8
class that comes from a different module file, make sure that we load
all of the pending declarations for the original declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147168 91177308-0d34-0410-b5e6-96231b3b80d8
\<newline><newline>
don't consume the second newline.
Thanks to David Blaikie for pointing out the crash!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147138 91177308-0d34-0410-b5e6-96231b3b80d8
declaration of that same class that either came from some other module
or occurred in the translation unit loading the module. In this case,
we need to merge the two redeclaration chains immediately so that all
such declarations have the same canonical declaration in the resulting
AST (even though they don't in the module files we've imported).
Focusing on Objective-C classes until I'm happy with the design, then
I'll both (1) extend this notion to other kinds of declarations, and
(2) optimize away this extra checking when we're not dealing with
modules. For now, doing this checking for PCH files/preambles gives us
better testing coverage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147123 91177308-0d34-0410-b5e6-96231b3b80d8
that the information collected by this method is a super set of the captured variables in BlockDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147122 91177308-0d34-0410-b5e6-96231b3b80d8
token locations as coming before the closing ')' of a function macro expansion.
Include a unit test for SourceManager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147056 91177308-0d34-0410-b5e6-96231b3b80d8
redeclaration chains: only ever have the reader search for
redeclarations of the first (canonical) declaration, since we only
ever record redeclaration ranges for the that declaration. Searching
for redeclarations of non-canonical declarations will never find
anything, so it's a complete waste of time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147055 91177308-0d34-0410-b5e6-96231b3b80d8
members of class templates so that their values can be used in ICEs. This
required reverting r105465, to get such instantiated members to be included in
serialized ASTs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147023 91177308-0d34-0410-b5e6-96231b3b80d8
type is a pointer to const. (radar://10595327)
The regions corresponding to the pointer and reference arguments to
a function get invalidated by the calls since a function call can
possibly modify the pointed to data. With this change, we are not going
to invalidate the data if the argument is a pointer to const. This
change makes the analyzer more optimistic in reporting errors.
(Support for C, C++ and Obj C)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147002 91177308-0d34-0410-b5e6-96231b3b80d8
notify the AST deserialization listener so that the AST writer knows
that it can write the macro definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146994 91177308-0d34-0410-b5e6-96231b3b80d8
visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.
As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.
Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146980 91177308-0d34-0410-b5e6-96231b3b80d8
Split out a new ExpressionEvaluationContext flag for this case, and don't treat
it as unevaluated in C++11. This fixes some crash-on-invalids where we would
allow references to class members in potentially-evaluated constant expressions
in static member functions, and also fixes half of PR10177.
The fix to PR10177 exposed a case where template instantiation failed to provide
a source location for a diagnostic, so TreeTransform has been tweaked to supply
source locations when transforming a type. The source location is still not very
good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to
improve it further.
Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for
static data members of class templates which are used in constant expressions.
This fixes a link-time problem, but we still incorrectly treat the member as
non-constant. The rest of the fix for that issue is blocked on PCH support for
early-instantiated static data members, which will be added in a subsequent
patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146955 91177308-0d34-0410-b5e6-96231b3b80d8
hitting a submodule that was never actually created, e.g., because
that header wasn't parsed. In such cases, complain (because the
module's umbrella headers don't cover everything) and fall back to
including the header.
Later, we'll add a warning at module-build time to catch all such
cases. However, this fallback is important to eliminate assertions in
the ASTWriter when this happens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146933 91177308-0d34-0410-b5e6-96231b3b80d8
with a definition pointer (e.g., C++ and Objective-C classes), zip
through the redeclaration chain to make sure that all of the
declarations point to the definition data.
As part of this, realized again why the first redeclaration of an
entity in a file is important, and brought back that idea.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146886 91177308-0d34-0410-b5e6-96231b3b80d8
redeclaration templates (RedeclarableTemplateDecl), similarly to the
way (de-)serialization is implemented for Redeclarable<T>. In the
process, found a simpler formulation for handling redeclaration
chains and implemented that in both places.
The new test establishes that we're building the redeclaration chains
properly. However, the FIXME indicates where we're tickling a
different bug that has to do with us not setting the DefinitionData
pointer properly in redeclarations that we detected after the
definition itself was deserialized. The (separable) fix for that bug
is forthcoming.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146883 91177308-0d34-0410-b5e6-96231b3b80d8
imported modules that don't introduce any new entities of a particular
kind. Allow these entries to be replaced with entries for another
loaded module.
In the included test case, selectors exhibit this behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146870 91177308-0d34-0410-b5e6-96231b3b80d8
which there are no redeclarations. This reduced by size of the PCH
file for Cocoa.h by ~650k: ~536k of that was in the new
LOCAL_REDECLARATIONS table, which went from a ridiculous 540k down to
an acceptable 3.5k, while the rest was due to the more compact
abbreviated representation of redeclarable declaration kinds (which no
longer need to store the 'first' declaration ID).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146869 91177308-0d34-0410-b5e6-96231b3b80d8
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.
Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:
extern const int a;
const int n = a;
const int a = 5;
int arr[n];
Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146856 91177308-0d34-0410-b5e6-96231b3b80d8
floating literal value does not fit into the destination type. Such casts have
undefined behavior at translation time; treating them as non-ICE matches the
behavior of modern gcc versions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146842 91177308-0d34-0410-b5e6-96231b3b80d8
chains. The previous implementation relied heavily on the declaration
chain being stored as a (circular) linked list on disk, as it is in
memory. However, when deserializing from multiple modules, the
different chains could get mixed up, leading to broken declaration chains.
The new solution keeps track of the first and last declarations in the
chain for each module file. When we load a declaration, we search all
of the module files for redeclarations of that declaration, then
splice together all of the lists into a coherent whole (along with any
redeclarations that were actually parsed).
As a drive-by fix, (de-)serialize the redeclaration chains of
TypedefNameDecls, which had somehow gotten missed previously. Add a
test of this serialization.
This new scheme creates a redeclaration table that is fairly large in
the PCH file (on the order of 400k for Cocoa.h's 12MB PCH file). The
table is mmap'd in and searched via a binary search, but it's still
quite large. A future tweak will eliminate entries for declarations
that have no redeclarations anywhere, and should
drastically reduce the size of this table.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146841 91177308-0d34-0410-b5e6-96231b3b80d8
especially nice as the Windows toolchain needs the windows header files,
and has lots of platform specific hooks in it.
To facilitate the split, hoist a bunch of file-level static helpers into
class-level static helpers. Spiff up their doxygen comments while there
as they're now more likely to be looked up via docs.
Hopefully, this will be followed by further breaking apart of the
toolchain definitions. Most of the large and complex ones should likely
live on their own. I'm looking at you Darwin. ;]
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146840 91177308-0d34-0410-b5e6-96231b3b80d8
It had been causing test "Misc/diag-verify.cpp" failure on ms cl.exe. The emission was ordered unexpectedly as below;
First) error: 'error' diagnostics seen but not expected:
Second) error: 'error' diagnostics expected but not seen:
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146830 91177308-0d34-0410-b5e6-96231b3b80d8
over them because more interesting decls can be added during body
deserialization.
Should fix msvc build tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146824 91177308-0d34-0410-b5e6-96231b3b80d8
the policy of how diagnostics are lowered/rendered, while TextDiagnostic handles
the actual pretty-printing.
This is a first part of reworking SerializedDiagnosticPrinter to use the same
inclusion-stack/macro-expansion logic as TextDiagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146819 91177308-0d34-0410-b5e6-96231b3b80d8
including deserializing their bodies, so that any other declarations that
get referenced in the body will be fully deserialized by the time we pass them to the consumer.
Could not reduce to a test case unfortunately. rdar://10587158.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146817 91177308-0d34-0410-b5e6-96231b3b80d8
Stopping at '@' was originally intended to avoid skipping an '@' at the @interface context
when doing parser recovery, but we should not stop at all '@' tokens because they may be part
of expressions (e.g. in @"string", @selector(), etc.), so in most cases we will want to skip them.
This commit caused 'test/Parser/method-def-in-class.m' to fail for the cases where we tried to
recover from unmatched angle bracket but IMO it is not a big deal to not have good recovery
from such broken code and the way we did recovery would not always work anyway (e.g. if there was '@'
in an expression).
The case that rdar://7029784 is about still passes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146815 91177308-0d34-0410-b5e6-96231b3b80d8
because the memory associated with them is going to get released.
We also don't want them to affect later parsing.
(We do the same for C++ inline methods.)
The underlying cause for the leftover tokens is going to be addressed in the
next commit.
Couldn't get a test case for the crash though. rdar://10583033.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146814 91177308-0d34-0410-b5e6-96231b3b80d8
Check if the input parameters are tainted (or point to tainted data) on
a checkPreStmt<CallExpr>. If the output should be tainted, record it in
the state. On post visit (checkPostStmt<CallExpr>), use the state to
make decisions (in addition to the existing logic). Use this logic for
atoi and fscanf.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146793 91177308-0d34-0410-b5e6-96231b3b80d8
intrinsics to use "I" (ICE) markings. Fix avxintrin.h to take them into
account.
Part of rdar://10595450
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146791 91177308-0d34-0410-b5e6-96231b3b80d8
declaration for the type then go ahead and use that, it's still smaller
than creating an all new derived type.
Part of rdar://10335756 and others.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146779 91177308-0d34-0410-b5e6-96231b3b80d8
#__include_macros) in the arguments of a function-style macro. Directives in the
arguments of such macros have undefined behaviour, and GCC does not correctly
support these cases. In some situations, this can lead to better diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146765 91177308-0d34-0410-b5e6-96231b3b80d8
This is equal to alignof(std::max_align_t) on the platform and equal to the
alignment provided by malloc. (Platform owners please double-check your
platform's value.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146762 91177308-0d34-0410-b5e6-96231b3b80d8
might not be an rvalue when checking array accesses. Instead, pass through a
flag indicating the array index is negated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146753 91177308-0d34-0410-b5e6-96231b3b80d8
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146749 91177308-0d34-0410-b5e6-96231b3b80d8
We should exit when matching the '+' even if nothing was found to
prevent searching for all UNIT_MAX items.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146747 91177308-0d34-0410-b5e6-96231b3b80d8
instantiate a class from its template pattern
before it consults the ExternalASTSource. LLDB
in particular will sometimes provide patterns
that need to be completed first.
To make this possible, I have moved the
completion before the code that does the
instantiation, allowing the ExternalASTSource
to provide the required information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146715 91177308-0d34-0410-b5e6-96231b3b80d8
applies to an actual definition. Plus, clarify the purpose of this
field and give the accessor a different name, since getLocEnd() is
supposed to be the same as getSourceRange().getEnd().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146694 91177308-0d34-0410-b5e6-96231b3b80d8
declarations and definitions) as ObjCInterfaceDecls within the same
redeclaration chain. This new representation matches what we do for
C/C++ variables/functions/classes/templates/etc., and makes it
possible to answer the query "where are all of the declarations of
this class?"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146679 91177308-0d34-0410-b5e6-96231b3b80d8
redeclaration chain for Objective-C classes, including:
- Using the first declaration as the canonical declaration.
- Using the definition as the primary DeclContext
- Making sure that all declarations have a pointer to the definition
data, and the definition knows that it is the definition.
- Serialization support for when a definition gets added to a
declaration that comes from an AST file.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCInterfaceDecls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146667 91177308-0d34-0410-b5e6-96231b3b80d8
don't refer to anything. Amusingly, we were relying on this in one
place. Thanks to Chandler for noticing the weirdness in
declaresSameEntity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146659 91177308-0d34-0410-b5e6-96231b3b80d8
separately-allocated DefinitionData structure, which we manage the
same way as CXXRecordDecl::DefinitionData. This prepares the way for
making ObjCInterfaceDecls redeclarable, to more accurately model
forward declarations of Objective-C classes and eliminate the mutation
of ObjCInterfaceDecl that causes us serious trouble in the AST reader.
Note that ObjCInterfaceDecl's accessors are fairly robust against
being applied to forward declarations, because Clang (and Sema in
particular) doesn't perform RequireCompleteType/hasDefinition() checks
everywhere it has to. Each of these overly-robust cases is marked with
a FIXME, which we can tackle over time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146644 91177308-0d34-0410-b5e6-96231b3b80d8
is deterministic.
Non-determinism was the reason for the test which caused the earlier
buildbot failures, so re-enable the test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146628 91177308-0d34-0410-b5e6-96231b3b80d8
expression with an unknown result type, assume that the result type is
'id'. Fixes <rdar://problem/10400663>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146622 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146619 91177308-0d34-0410-b5e6-96231b3b80d8
to declaresSameEntity(), as a baby step toward tracking forward
declarations of Objective-C classes precisely. Part of
<rdar://problem/10583531>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146618 91177308-0d34-0410-b5e6-96231b3b80d8
Some of the test cases do not currently work because the analyzer core
does not seem to call checkers for pre/post DeclRefExpr visits.
(Opened radar://10573500. To be fixed later on.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146536 91177308-0d34-0410-b5e6-96231b3b80d8
Necessary to parse Microsoft ATL code.
Example:
int array[] = {
0,
__if_exists(CLASS::Type) {2, }
3
};
will declare an array of 2 or 3 elements depending on if CLASS::Type exists or not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146447 91177308-0d34-0410-b5e6-96231b3b80d8
The motivation here is a "clever" implementation of strncmp(), which peels the first few comparisons via chained conditional expressions which ensure that the input arrays are known at compile time to be sufficiently large.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146430 91177308-0d34-0410-b5e6-96231b3b80d8
Rafael Espindola
Benjamin Kramer
NAKAMURA Takumi
Craig Topper
Richard Smith
Nico Weber
Anton Yartsev
Dylan Noblesmith
Argyrios Kyrtzidis
Fariborz Jahanian
Douglas Gregor
Ted Kremenek
Nick Lewycky
Kevin Enderby
Sebastian Redl
Eli Friedman
Matt Beaumont-Gay
Anna Zaks
Chandler Carruth
David Blaikie
Bill Wendling
Chris Lattner
Chad Rosier
Eric Christopher
Nicola Gigante
Sean Callanan
Hans Wennborg
Richard Trieu
DeLesley Hutchins
Bob Wilson
Abramo Bagnara
Francois Pichet
Tony Linthicum