| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
notify the AST deserialization listener so that the AST writer knows
that it can write the macro definition.
llvm-svn: 146994
|
| |
|
|
| |
llvm-svn: 146993
|
| |
|
|
| |
llvm-svn: 146988
|
| |
|
|
|
|
| |
Patch by Dimitry Andric!
llvm-svn: 146982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146980
|
| |
|
|
|
|
| |
the definition of that class. Fixes PR11613 / <rdar://problem/10604077>.
llvm-svn: 146976
|
| |
|
|
|
|
| |
unneeded builtins for SSE pcmp. Change SSE pcmpeqq and pcmpgtq to not use builtins and just use vector == and >.
llvm-svn: 146969
|
| |
|
|
| |
llvm-svn: 146961
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146955
|
| |
|
|
|
|
| |
for-range-declaration. PR11601.
llvm-svn: 146953
|
| |
|
|
|
|
| |
Windows subversion clients isn't setup to default to eol:native again...
llvm-svn: 146952
|
| |
|
|
| |
llvm-svn: 146938
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146933
|
| |
|
|
|
|
| |
error. // rdar://10597832
llvm-svn: 146918
|
| |
|
|
|
|
| |
actually requires non-trivial cleanups, so no cleanups need to be performed.
llvm-svn: 146916
|
| |
|
|
| |
llvm-svn: 146915
|
| |
|
|
| |
llvm-svn: 146910
|
| |
|
|
|
|
| |
that have alignment less than the natural alignment of the type when it comes from a typedef.
llvm-svn: 146908
|
| |
|
|
| |
llvm-svn: 146907
|
| |
|
|
| |
llvm-svn: 146906
|
| |
|
|
|
|
| |
But, warn too. // rdar://10597832
llvm-svn: 146904
|
| |
|
|
| |
llvm-svn: 146898
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146886
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146883
|
| |
|
|
| |
llvm-svn: 146871
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146870
|
| |
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 146869
|
| |
|
|
| |
llvm-svn: 146868
|
| |
|
|
|
|
|
| |
the inner decl being a builtin. This is needed to support the glibc headers
in fedora 16 (2.14).
llvm-svn: 146867
|
| |
|
|
| |
llvm-svn: 146862
|
| |
|
|
| |
llvm-svn: 146857
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146856
|
| |
|
|
|
|
| |
used to store builtinID when serializing identifier table.
llvm-svn: 146855
|
| |
|
|
| |
llvm-svn: 146848
|
| |
|
|
|
|
|
|
|
|
| |
(truncated)
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.
llvm-svn: 146842
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146841
|
| |
|
|
|
|
| |
flags on MIPS paltforms.
llvm-svn: 146837
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 146825
|
| |
|
|
|
|
|
|
|
|
| |
gives us comparative diagnostics
to TextDiagnosticPrinter.
This certainly can be cleaned up a bit.
llvm-svn: 146820
|
| |
|
|
|
|
|
|
| |
macro expansion.
rdar://10588825
llvm-svn: 146818
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146815
|
| |
|
|
| |
llvm-svn: 146813
|
| |
|
|
|
|
| |
declarations without a declarator to structs. Add a warning for ignored attributes. Patch by Michael Han.
llvm-svn: 146796
|
| |
|
|
| |
llvm-svn: 146795
|
| |
|
|
| |
llvm-svn: 146794
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146793
|
| |
|
|
|
|
|
|
| |
intrinsics to use "I" (ICE) markings. Fix avxintrin.h to take them into
account.
Part of rdar://10595450
llvm-svn: 146791
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 146779
|
| |
|
|
|
|
|
|
| |
classes.
Part of rdar://10520586 and a couple others.
llvm-svn: 146778
|
| |
|
|
|
|
|
|
| |
#__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.
llvm-svn: 146765
|