declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253283 91177308-0d34-0410-b5e6-96231b3b80d8
DR407, the C++ standard doesn't really say how this should work. Here's what we
do (which is consistent with DR407 as far as I can tell):
* When performing name lookup for an elaborated-type-specifier, a tag
declaration hides a typedef declaration that names the same type.
* When performing any other kind of lookup, a typedef declaration hides
a tag declaration that names the same type.
In any other case where lookup finds both a typedef and a tag (that is, when
they name different types), the lookup will be ambiguous. If lookup finds a
tag and a typedef that name the same type, and finds anything else, the lookup
will always be ambiguous (even if the other entity would hide the tag, it does
not also hide the typedef).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252959 91177308-0d34-0410-b5e6-96231b3b80d8
internal linkage entities in different modules from r250884 to apply to all
names, not just function names.
This is really awkward: we don't want to merge internal-linkage symbols from
separate modules, because they might not actually be defining the same entity.
But we don't want to reject programs that use such an ambiguous symbol if those
internal-linkage symbols are in fact equivalent. For now, we're resolving the
ambiguity by picking one of the equivalent definitions as an extension.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252063 91177308-0d34-0410-b5e6-96231b3b80d8
This new builtin template allows for incredibly fast instantiations of
templates like std::integer_sequence.
Performance numbers follow:
My work station has 64 GB of ram + 20 Xeon Cores at 2.8 GHz.
__make_integer_seq<std::integer_sequence, int, 90000> takes 0.25
seconds.
std::make_integer_sequence<int, 90000> takes unbound time, it is still
running. Clang is consuming gigabytes of memory.
Differential Revision: http://reviews.llvm.org/D13786
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252036 91177308-0d34-0410-b5e6-96231b3b80d8
particular don't assume that two declarations of the same kind in the same
context are declaring the same entity. That's not true when the same name is
declared multiple times as internal-linkage symbols within a module.
(getCanonicalDecl is cheap now, so we can just use it here.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251898 91177308-0d34-0410-b5e6-96231b3b80d8
With -fms-extensions it is possible to have a non-class record that is a
template specialization cause an assertion failure via the call to
Type::getAsCXXRecordDecl. Fixes PR 24246.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249090 91177308-0d34-0410-b5e6-96231b3b80d8
it's not sufficient to prefer the declaration with more default arguments, or
the one that's visible; they might both be visible, but one of them might have
a visible default argument where the other has a hidden default argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247486 91177308-0d34-0410-b5e6-96231b3b80d8
pick the most recent declaration, and we can often tell which declaration is
more recent without walking the redeclaration chain. Do so when possible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245794 91177308-0d34-0410-b5e6-96231b3b80d8
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243642 91177308-0d34-0410-b5e6-96231b3b80d8
UsingShadowDecls over other declarations of the same entity in the lookup
results. This ensures that we build correct redeclaration chains for the
UsingShadowDecls (otherwise we could see assertions and other misbehavior in
modules builds, when merging combines multiple redeclaration chains for the
same entity from the same module into one chain).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243592 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us pass functors (and lambdas) without void * tricks. On the
downside we can't pass CXXRecordDecl's Find* members (which are now type
safe) to lookupInBases directly, but a lambda trampoline is a small
price to pay. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243217 91177308-0d34-0410-b5e6-96231b3b80d8
the identifier table. This is redundant, since the TU-scope lookups are also
serialized as part of the TU DeclContext, and wasteful in a number of ways. We
still emit the decls for PCH / preamble builds, since for those we want
identical results, not merely semantically equivalent ones.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242855 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
Support this across module save/reload and extend the 'missing import'
diagnostics with a list of providing modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239750 91177308-0d34-0410-b5e6-96231b3b80d8
modules, and allow use of a default template argument if any of the parameters
providing it is visible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239485 91177308-0d34-0410-b5e6-96231b3b80d8
There are still problems here, but this is a better starting point.
The main part of the change is: when doing a lookup that would accept visible
or hidden declarations, prefer to produce the latest visible declaration if
there are any visible declarations, rather than always producing the latest
declaration.
Thus, when we inherit default arguments (and other properties) from a previous
declaration, we inherit them from the previous visible declaration; if the
previous declaration is hidden, we already suppress inheritance of default
arguments.
There are a couple of other changes here that fix latent bugs exposed by this
change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239371 91177308-0d34-0410-b5e6-96231b3b80d8
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238601 91177308-0d34-0410-b5e6-96231b3b80d8
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237473 91177308-0d34-0410-b5e6-96231b3b80d8
for a DeclContext, and fix propagation of exception specifications along
redeclaration chains.
This reverts r232905, r232907, and r232907, which reverted r232793, r232853,
and r232853.
One additional change is present here to resolve issues with LLDB: distinguish
between whether lexical decls missing from the lookup table are local or are
provided by the external AST source, and still look in the external source if
that's where they came from.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232928 91177308-0d34-0410-b5e6-96231b3b80d8
When we need to build the lookup table for a DeclContext, we used to pull in
all lexical declarations for the context; instead, just build a lookup table
for the local lexical declarations. We previously didn't guarantee that the
imported declarations would be in the returned map, but in some cases we'd
happen to put them all in there regardless. Now we're even lazier about this.
This unnecessary work was papering over some other bugs:
- LookupVisibleDecls would use the DC for name lookups in the TU in C, and
this was not guaranteed to find all imported names (generally, the DC for
the TU in C is not a reliable place to perform lookups). We now use an
identifier-based lookup mechanism for this.
- We didn't actually load in the list of eagerly-deserialized declarations
when importing a module (so external definitions in a module wouldn't be
emitted by users of those modules unless they happened to be deserialized
by the user of the module).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232793 91177308-0d34-0410-b5e6-96231b3b80d8
This guarantees the order and doesn't increase malloc counts a lot as there are
typically very few elements int the map. Provide a little iterator adapter to
keep the same interface as we had with the flat sorted list.
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232173 91177308-0d34-0410-b5e6-96231b3b80d8
We used to save out and eagerly load a (potentially huge) table of merged
formerly-canonical declarations when we loaded each module. This was extremely
inefficient in the presence of large amounts of merging, and didn't actually
save any merging lookup work, because we still needed to perform name lookup to
check that our merged declaration lists were complete. This also resulted in a
loss of laziness -- even if we only needed an early declaration of an entity, we
would eagerly pull in all declarations that had been merged into it regardless.
We now store the relevant fragments of the table within the declarations
themselves. In detail:
* The first declaration of each entity within a module stores a list of first
declarations from imported modules that are merged into it.
* Loading that declaration pre-loads those other entities, so that they appear
earlier within the redeclaration chain.
* The name lookup tables list the most recent local lookup result, if there
is one, or all directly-imported lookup results if not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231424 91177308-0d34-0410-b5e6-96231b3b80d8
already have, check whether the name from the module is actually newer than the
existing declaration. If it isn't, we might (say) replace a visible declaration
with an injected friend, and thus make it invisible (or lose a default argument
or an array bound).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228661 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise, in the most important case and the only case where SS and
TempSS are different (which is when the CXXScopeSpec should be dropped,
and TempSS is NULL) the wrong SourceRange will be used in the fixit for
the typo correction. Fixes the remaining issue in PR20626.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227278 91177308-0d34-0410-b5e6-96231b3b80d8
ambiguity but wasn't.
In the new test case, "click" wasn't being corrected properly because
Sema::ClassifyName would call CorrectTypo for "click" then later
Sema::DiagnoseEmptyLookup would call CorrectTypoDelayed for the same use
of "click" (the former by the parser needing to determine what the
identifier is so it knows how to parse the statement, i.e. is it the
beginning of a declaration or an expression). CorrectTypo would record
that typo correction for "click" failed and CorrectTypoDelayed would see
that and not even try to correct the typo, even though in this case
CorrectTypo failed due to an ambiguity (both "Click" and "clock" having
an edit distance of one from "click") that could be resolved with more
information. The fix is two-fold:
1) Have CorrectTypo not record failed corrections if the reason for
the failure was two or more corrections with the same edit
distance, and
2) Make the CorrectionCandidateCallback used by
Parser::ParseCastExpression reject FunctionDecl candidates when the
next token after the identifier is a ".", "=", or "->" since
functions cannot be assigned to and do not have members that can be
referenced.
The reason for two correction spots is that from r222549 until r224375
landed, the first correction attempt would fail completely but the
second would suggest "clock" while having the note point to the
declaration of "Click".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226334 91177308-0d34-0410-b5e6-96231b3b80d8
Remove Sema::UnqualifiedTyposCorrected, a cache of corrected typos. It would only cache typo corrections that didn't provide ValidateCandidate of which there were few left, and it had a bug when we had the same identifier spelled wrong twice. See the last two tests in typo-correction.cpp for cases this fires.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224375 91177308-0d34-0410-b5e6-96231b3b80d8
Also keep track of the stack of Exprs visited during the tree transform
so the callback can be passed the parent of the TypoExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220697 91177308-0d34-0410-b5e6-96231b3b80d8
matches of the typo.
Also be more proactive about checking a correction's visibility so that
a correction requiring a module import can be distinguished from the
original typo even if it looks identical. Otherwise the correction will
be excluded and the diagnostic about needing the module import won't be
emitted.
Note that no change was made to checkCorrectionVisibility other than
moving where it is at in SemaLookup.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220696 91177308-0d34-0410-b5e6-96231b3b80d8
Part of the infrastructure is a map from a TypoExpr to the Sema-specific
state needed to correct it, along with helpers to ease dealing with the
state.
The the typo count is propagated up the stack of
ExpressionEvaluationContextRecords when one is popped off of to
avoid accidentally dropping TypoExprs on the floor. For example,
the attempted correction of g() in test/CXX/class/class.mem/p5-0x.cpp
happens with an ExpressionEvaluationContextRecord that is popped off
the stack prior to ActOnFinishFullExpr being called and the tree
transform for TypoExprs being run.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220695 91177308-0d34-0410-b5e6-96231b3b80d8
Two additional methods are provided: one to return the current
correction (the last correction returned by getNextCorrection), and one
to "reset" the state so that getNextCorrection will return the previous
corrections before returning any new corrections.
Also ensure that all TypoCorrections have valid source ranges.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220694 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it available outside of SemaLookup.cpp, as
needed for the forthcoming TypoExpr AST node which will
keep a TypoCorrectionConsumer that provides the possible
typo corrections for that TypoExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220691 91177308-0d34-0410-b5e6-96231b3b80d8
This moves some code from SemaType.cpp's hasVisibleDefinition() into
DeclCXX.cpp so that it can be used elsewhere. I found one other instance
of code trying to do the same thing, there are probably more. Search for
getInstantiatedFrom() to try to find more.
No functionality change.
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5783
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219714 91177308-0d34-0410-b5e6-96231b3b80d8
We build a NestedNameSpecifier that records the CXXRecordDecl in which
__super appeared. Name lookup is performed in all base classes of the
recorded CXXRecordDecl. Use of __super is allowed only inside class and
member function scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218484 91177308-0d34-0410-b5e6-96231b3b80d8
FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care
about the other ExtProtoInfo bits and just want to talk about the exception
specification.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214450 91177308-0d34-0410-b5e6-96231b3b80d8
The new flag, WantFunctionLikeCasts, covers a subset of the keywords
covered by WantTypeSpecifiers that can be used in casts that look like
function calls, e.g. "return long(5);", while excluding the keywords
like "enum" and "const" that would be included when WantTypeSpecifiers
is true but cannot be used in something that looks like a function call.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214109 91177308-0d34-0410-b5e6-96231b3b80d8
That's what I get for hurredly splitting the small change out of a much
bigger change that had moved where checkCorrectionVisibility was being
called.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211134 91177308-0d34-0410-b5e6-96231b3b80d8
Also move the constructor for NamespaceSpecifierSet out of line to
improve the class' readability. I meant to do these two things while
cleaning up the previous TypoCorrectionConsumer changes and have them
folded into those changes.
No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210686 91177308-0d34-0410-b5e6-96231b3b80d8
SpecifierInfo is not used outside of NamespaceSpecifierSet except
indirectly through NamespaceSpecifierSet's iterator, so clean up the
code a bit by moving SpecifierInfo into NamespaceSpecifierSet. Also drop
SpecifierInfo's trivial yet verbose constructor since brace
initiialization is sufficient in the only two places the constructor was
being explicitly called.
No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210672 91177308-0d34-0410-b5e6-96231b3b80d8
The SpecifierInfo and NamespaceSpecifierSet are now only used by
TypoCorrectionConsumer, so treat them as the implementation details of
TypoCorrectionConsumer that they are. Also make NamespaceSpecifierSet's
method names more style guide compliant.
No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210671 91177308-0d34-0410-b5e6-96231b3b80d8
The only external/visible functional change that fell out of this
refactoring is that there was one less case where the typo caching
and/or counting didn't work properly. The result is that a test case
had to be moved from typo-correction.cpp to typo-correction-pt2.cpp
to avoid the hard-coded limit on per file/TU typo correction attempts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210669 91177308-0d34-0410-b5e6-96231b3b80d8
This is in preparation for moving TypoCorrection filtering
into the TypoCorrectionConsumer, to separate out some of the purely
mechanical churn. It also makes some of the method names in
NamespaceSpecifierSet be more style guide compliant.
No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210668 91177308-0d34-0410-b5e6-96231b3b80d8
whether the definition of the template is visible rather than checking whether
the instantiated definition happens to be in an imported module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208150 91177308-0d34-0410-b5e6-96231b3b80d8
declaration is not visible. Previously we didn't find hidden friend names in
this redeclaration lookup, because we forgot to treat it as a redeclaration
lookup. Conversely, we did find some local extern names, but those don't
actually conflict with a namespace-scope using declaration, because the only
conflicts we can get are scope conflicts, not conflicts due to the entities
being members of the same namespace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206011 91177308-0d34-0410-b5e6-96231b3b80d8
obviously won't work. Specifically, don't suggest methods (static or
not) from unrelated classes when the expression is a method call
through a specific object.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205653 91177308-0d34-0410-b5e6-96231b3b80d8
complete. We hook into this check from a couple of other places (modules,
debug info) so it's not OK to elide the check if the type was already
complete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203978 91177308-0d34-0410-b5e6-96231b3b80d8
won't work (i.e. when not doing a member lookup and not in a method from
the same class or a descendant class).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202520 91177308-0d34-0410-b5e6-96231b3b80d8
nested-name-specifiers for typos unless the typo already has
a nested-name-specifier that is a template specialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201056 91177308-0d34-0410-b5e6-96231b3b80d8
Because in C++, "anonymous" doesn't mean "nameless" for records. In
other words, RecordDecl::isAnonymousStructOrUnion only returns true if
the record lacks a name *and* is not used as the type in an object's
declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200868 91177308-0d34-0410-b5e6-96231b3b80d8
redeclaration, not just when looking them up for a use -- we need the implicit
declaration to appropriately check various properties of them (notably, whether
they're deleted).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200729 91177308-0d34-0410-b5e6-96231b3b80d8
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
create an implicit declaration of it (because some type it depends on is
unavailable). This had the effect of causing us to not implicitly give it the
right attributes. It turns out that glibc's __sigsetjmp is declared before
sigjmp_buf is declared, and this resulted in us not implicitly giving it
__attribute__((returns_twice)), which in turn resulted in miscompiles in any C
code calling glibc's sigsetjmp.
(See also the vaguely-related sourceware.org/PR4662.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199850 91177308-0d34-0410-b5e6-96231b3b80d8
Lift the getFunctionDecl() utility out of the parser into a general
Decl::getAsFunction() and use it to simplify other parts of the implementation.
Reduce isFunctionOrFunctionTemplate() to a simple type check that works the
same was as the other is* functions and move unwrapping of shadowed decls to
callers so it doesn't get run twice.
Shuffle around canSkipFunctionBody() to reduce virtual dispatch on ASTConsumer.
There's no need to query when we already know the body can't be skipped.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199794 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199209 91177308-0d34-0410-b5e6-96231b3b80d8
scope, be careful about function-scope declarations (which are not declared in
their semantic context).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193671 91177308-0d34-0410-b5e6-96231b3b80d8
Now that CorrectTypo knows how to correctly search classes for typo
correction candidates, there is no good reason to only replace an
existing CXXScopeSpecifier if it refers to a namespace. While the actual
enablement was a matter of changing a single comparison, the fallout
from enabling the functionality required a lot more code changes
(including my two previous commits).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193020 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes PR17019. When doing typo correction, Sema::CorrectTypo uses
correction already seen for the same typo. This causes problems if that
correction is from another scope and cannot be accessed in the current.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192594 91177308-0d34-0410-b5e6-96231b3b80d8
extension. The GCC folks have decided to support this even though the standard
committee have not yet approved this feature.
Patch by Hristo Venev!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192128 91177308-0d34-0410-b5e6-96231b3b80d8
When we check access for lookup results, make sure we propagate the
result's access to the access control APIs; this can be different from
the natural access of the declaration depending on the path used by the lookup.
PR17394.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191726 91177308-0d34-0410-b5e6-96231b3b80d8
Unlike with namespaces, searching inside of classes requires also
checking the access to correction candidates (i.e. don't suggest a
correction to a private class member for a correction occurring outside
that class and its methods or friends).
Included is a small (one line) fix for a bug, that was uncovered while
cleaning up the unit tests, where the decls from a TypoCorrection candidate
were preserved in new TypoCorrection candidates that are derived (copied)
from the old TypoCorrection--notably when creating a new candidate by
changing the NestedNameSpecifier associated with the base idenitifer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191449 91177308-0d34-0410-b5e6-96231b3b80d8
variable from being the function to being the enclosing namespace scope (in
C++) or the TU (in C). This allows us to fix a selection of related issues
where we would build incorrect redeclaration chains for such declarations, and
fail to notice type mismatches.
Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern,
which is only found when searching scopes, and not found when searching
DeclContexts. Such a declaration is only made visible in its DeclContext if
there are no non-LocalExtern declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191064 91177308-0d34-0410-b5e6-96231b3b80d8
When a comma occurs in a default argument or default initializer within a
class, disambiguate whether it is part of the initializer or whether it ends
the initializer.
The way this works (which I will be proposing for standardization) is to treat
the comma as ending the default argument or default initializer if the
following token sequence matches the syntactic constraints of a
parameter-declaration-clause or init-declarator-list (respectively).
This is both consistent with the disambiguation rules elsewhere (where entities
are treated as declarations if they can be), and should have no regressions
over our old behavior. I think it might also disambiguate all cases correctly,
but I don't have a proof of that.
There is an annoyance here: because we're performing a tentative parse in a
situation where we may not have seen declarations of all relevant entities (if
the comma is part of the initializer, lookup may find entites declared later in
the class), we need to turn off typo-correction and diagnostics during the
tentative parse, and in the rare case that we decide the comma is part of the
initializer, we need to revert all token annotations we performed while
disambiguating.
Any diagnostics that occur outside of the immediate context of the tentative
parse (for instance, if we trigger the implicit instantiation of a class
template) are *not* suppressed, mirroring the usual rules for a SFINAE context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190639 91177308-0d34-0410-b5e6-96231b3b80d8
it is an implicit instantiation of a class template specialization), pick the
first-loaded definition to be the canonical definition, and merge all other
definitions into it.
This is still rather incomplete -- we need to extend every form of declaration
that can appear within a CXXRecordDecl to be redeclarable if it came from an
AST file (this includes fields, enumerators, ...).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190315 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Makes functions with implicit calling convention compatible with
function types with a matching explicit calling convention. This fixes
things like calls to qsort(), which has an explicit __cdecl attribute on
the comparator in Windows headers.
Clang will now infer the calling convention from the declarator. There
are two cases when the CC must be adjusted during redeclaration:
1. When defining a non-inline static method.
2. When redeclaring a function with an implicit or mismatched
convention.
Fixes PR13457, and allows clang to compile CommandLine.cpp for the
Microsoft C++ ABI.
Excellent test cases provided by Alexander Zinenko!
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1231
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189412 91177308-0d34-0410-b5e6-96231b3b80d8
loop processing the candidates can cause new declerations to be added to
the context, invalidating lookup_result. To avoid that, make a copy of
the list of declarations to iterate over.
I don't have a way to check in a test case for this as it involves
a giant pile of source code and a generated PCH file used to accelerate
code completion, all of this running under ASan.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188623 91177308-0d34-0410-b5e6-96231b3b80d8
preparation for teaching this function how to diagnose a correction that
includes importing a module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188602 91177308-0d34-0410-b5e6-96231b3b80d8
When a local extern declaration redeclares some other entity, the type of that
entity is merged with the prior type if the prior declaration is visible (in C)
or is declared in the same scope (in C++).
- Make LookupRedeclarationWithLinkage actually work in C++, use it in the right
set of cases, and make it track whether it found a shadowed declaration.
- Track whether we found a declaration in the same scope (for C++) including
across serialization and template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188307 91177308-0d34-0410-b5e6-96231b3b80d8
of local classes. We were previously handling this by performing qualified
lookup within a function declaration(!!); replace it with the proper scope
lookup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188050 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith