| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
recovering by adding empty parenthesis. Fixes PR16676!
llvm-svn: 188920
|
| |
|
|
|
|
| |
-fdelayed-template-parsing mode. Patch by Will Wilson!
llvm-svn: 187916
|
| |
|
|
|
|
|
|
| |
out of ImpCastExprToType and to the caller site
as appropriate. This is in prep. to do more work for
// rdar://14569171
llvm-svn: 187503
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sufficient to only consider names visible at the point of instantiation,
because that may not include names that were visible when the template was
defined. More generally, if the instantiation backtrace goes through a module
M, then every declaration visible within M should be available to the
instantiation. Any of those declarations might be part of the interface that M
intended to export to a template that it instantiates.
The fix here has two parts:
1) If we find a non-visible declaration during name lookup during template
instantiation, check whether the declaration was visible from the defining
module of all entities on the active template instantiation stack. The defining
module is not the owning module in all cases: we look at the module in which a
template was defined, not the module in which it was first instantiated.
2) Perform pending instantiations at the end of a module, not at the end of the
translation unit. This is general goodness, since it significantly cuts down
the amount of redundant work that is performed in every TU importing a module,
and also implicitly adds the module containing the point of instantiation to
the set of modules checked for declarations in a lookup within a template
instantiation.
There's a known issue here with template instantiations performed while
building a module, if additional imports are added later on. I'll fix that
in a subsequent commit.
llvm-svn: 187167
|
| |
|
|
|
|
| |
PR16561.
llvm-svn: 185887
|
| |
|
|
|
|
| |
Reviewed by Richard Smith.
llvm-svn: 184612
|
| |
|
|
|
|
| |
This is needed to parse libstdc++ 4.7's type_traits, see PR13530.
llvm-svn: 184476
|
| |
|
|
| |
llvm-svn: 184332
|
| |
|
|
|
|
|
|
|
|
| |
candidates
Still missing cases for templates, but this is a step in the right
direction. Also omits suggestions that would be ambiguous (eg: void
func(int = 0); + void func(float = 0); func;)
llvm-svn: 183173
|
| |
|
|
|
|
|
| |
'ivar' was used inside a record/union used
as argument to __typeof. // rdar14037151 pr5984
llvm-svn: 183048
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
llvm-svn: 181677
|
| |
|
|
|
|
| |
consumers which don't create a Parser. Pointed out by Tom Honermann.
llvm-svn: 181251
|
| |
|
|
| |
llvm-svn: 181166
|
| |
|
|
|
|
|
|
|
|
|
| |
Move the creation of CapturedStmt parameters out of CodeGen and into
Sema, making it easier to customize the outlined function. The
ImplicitParamDecls are stored in the CapturedDecl using an
ASTContext-allocated array.
Differential Revision: http://llvm-reviews.chandlerc.com/D722
llvm-svn: 181043
|
| |
|
|
|
|
|
| |
This came up during my Euro LLVM 2013 talk on clang-format and I was
asked to submit it :-).
llvm-svn: 180772
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add a CapturedStmt.h similar to Lambda.h to reduce the typing required to get
to the CapturedRegionKind enum. This also allows codegen to access this enum
without including Sema/ScopeInfo.h.
Also removes some duplicated code for capturing 'this' between CapturedStmt and
Lambda.
Differential Revision: http://llvm-reviews.chandlerc.com/D712
llvm-svn: 180710
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add CapturedDecl to be the DeclContext for CapturedStmt, and perform semantic
analysis. Currently captures all variables by reference.
TODO: templates
Author: Ben Langmuir <ben.langmuir@intel.com>
Differential Revision: http://llvm-reviews.chandlerc.com/D433
llvm-svn: 179618
|
| |
|
|
|
|
| |
Patch by Amin Shali.
llvm-svn: 179180
|
| |
|
|
|
|
|
|
|
|
|
| |
fact be defined and used in another TU.
Reshuffle some test cases because we suppress -Wunused-variable after we've
emitted an error.
This fixes PR15558.
llvm-svn: 179138
|
| |
|
|
|
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
|
| |
|
|
|
|
|
|
|
|
| |
Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb
Revert "Don't compute a patched/semantic storage class."
This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05.
llvm-svn: 178681
|
| |
|
|
|
|
|
|
|
|
|
| |
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
|
| |
|
|
|
|
| |
and warn when a newly-imported module conflicts with an already-imported module.
llvm-svn: 177577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This created 2 issues:
1) Performance issue, since typo-correction with PCH/modules is rather expensive.
2) Correctness issue, since if it managed to "correct" 'super' then bogus compiler errors would
be emitted, like this:
3.m:8:3: error: unknown type name 'super'; did you mean 'super1'?
super.x = 0;
^~~~~
super1
t3.m:5:13: note: 'super1' declared here
typedef int super1;
^
t3.m:8:8: error: expected identifier or '('
super.x = 0;
^
llvm-svn: 177126
|
| |
|
|
|
|
| |
don't write them out to the module file.
llvm-svn: 177000
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we would compute the linkage lazily and cache it. When the
AST was modified in ways that could change the value, we would invalidate the
cache.
That was fairly brittle, since any code could ask for the a linkage before
the correct value was available.
We should change the API to one where the linkage is computed explicitly and
trying to get it when it is not available asserts.
This patch is a first step in that direction. We still compute the linkage
lazily, but instead of invalidating a cache, we assert that the AST
modifications didn't change the result.
llvm-svn: 176999
|
| |
|
|
| |
llvm-svn: 176607
|
| |
|
|
|
|
| |
Post-commit CR feedback from Jordan Rose regarding r175594.
llvm-svn: 175679
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroInfo class
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
llvm-svn: 175585
|
| |
|
|
|
|
| |
defined. Fixes PR14993!
llvm-svn: 174158
|
| |
|
|
|
|
|
| |
filter the elements before emitting them into a PCH. No user-visible
functionality change, except that PCH files may be smaller?
llvm-svn: 174034
|
| |
|
|
|
|
| |
a workaround for this bug from the -Wundefined-internals warning.
llvm-svn: 174020
|
| |
|
|
| |
llvm-svn: 173550
|
| |
|
|
|
|
| |
-Wundefined-internal warnings with PCH.
llvm-svn: 173538
|
| |
|
|
|
|
|
|
| |
never key functions. We did not implement that rule for the
iOS ABI, which was driven by what was implemented in gcc-4.2.
However, implement it now for other ARM-based platforms.
llvm-svn: 173515
|
| |
|
|
| |
llvm-svn: 172939
|
| |
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the source
static void f();
static void f();
template<typename T>
static void g() {
f();
}
static void f() {
}
void h() {
g<int>();
}
the call to f refers to the second decl, but it is only marked used at the end
of the translation unit during instantiation, after the third f decl has been
linked in.
With this patch we mark all subsequent decls used, so that it is easy to check
if a symbol is used or not.
llvm-svn: 171888
|
| |
|
|
| |
llvm-svn: 171367
|
| |
|
|
| |
llvm-svn: 171267
|
| |
|
|
|
|
|
|
| |
This fixes pr14736. It is fairly ugly, but I don't think we can do much better
as we have to wait at least until the end of the typedef to know if the
function will have external linkage or not.
llvm-svn: 171240
|
| |
|
|
|
|
|
| |
Template instantiation can set the canonical decl to used after subsequent
decls have been chained, so we have to check that too.
llvm-svn: 171088
|
| |
|
|
|
|
| |
This fixes pr14691, which I think is a regression from r168519.
llvm-svn: 171077
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
| |
|
|
|
|
|
| |
'getPointerWidth(0) >= 64' test to be a method on TargetInfo, ready to be
properly cleaned up.
llvm-svn: 168856
|
| |
|
|
| |
llvm-svn: 166520
|
| |
|
|
|
|
|
|
|
| |
defined without a previous declaration. This is similar to
-Wmissing-prototypes, but for variables instead of functions.
Patch by Ed Schouten.
llvm-svn: 166498
|
| |
|
|
| |
llvm-svn: 166208
|
| |
|
|
|
|
|
|
|
| |
The infrastructure for -Warc-repeated-use-of-weak got a little too heavy
to leave sitting at the top of Sema.cpp.
No functionality change.
llvm-svn: 164856
|
| |
|
|
|
|
|
|
|
|
| |
Like properties, loading from a weak ivar twice in the same function can
give you inconsistent results if the object is deallocated between the
two loads. It is safer to assign to a strong local variable and use that.
Second half of <rdar://problem/12280249>.
llvm-svn: 164855
|