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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187167 91177308-0d34-0410-b5e6-96231b3b80d8
r186331).
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186546 91177308-0d34-0410-b5e6-96231b3b80d8
This breaks the build of basic patterns with repeated friend
declarations. See the added test case in SemaCXX/friend.cpp or the test
case reported to the original commit log.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186331 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186199 91177308-0d34-0410-b5e6-96231b3b80d8
fix is.
Original commit log:
If we friend a declaration twice, that should not make it visible to
name lookup in the surrounding context. Slightly rework how we handle
friend declarations to inherit the visibility of the prior
declaration, rather than setting a friend declaration to be visible
whenever there was a prior declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186185 91177308-0d34-0410-b5e6-96231b3b80d8
lookup in the surrounding context. Slightly rework how we handle friend
declarations to inherit the visibility of the prior declaration, rather
than setting a friend declaration to be visible whenever there was a prior
declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186040 91177308-0d34-0410-b5e6-96231b3b80d8
The removal is tried by retrying the failed lookup of a correction
candidate with either the MemberContext or SS (CXXScopeSpecifier) or
both set to NULL if they weren't already. If the candidate identifier
is then looked up successfully, make a note in the candidate that the
SourceRange should include any existing nested name specifier even if
the candidate isn't adding a different one (i.e. the candidate has a
NULL NestedNameSpecifier).
Also tweak the diagnostic messages to differentiate between a suggestion
that just replaces the identifer but leaves the existing nested name
specifier intact and one that replaces the entire qualified identifier,
in cases where the suggested replacement is unqualified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185487 91177308-0d34-0410-b5e6-96231b3b80d8
CorrectTypo will now see and consider those corrections that are effectively
shadowed by other declarations in a closer context when resolved via an
unqualified lookup. This involves adding any parent namespaces to the set of
namespaces as fully-qualified name specifiers, and also adding potential
corrections that passed name lookup but were rejected by the given
CorrectionCandidateCallback into the set of failed corrections that should be
tried with the set of namespace specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185486 91177308-0d34-0410-b5e6-96231b3b80d8
ASTDumper was already trying to do this & instead got an implicit bool
conversion by surprise (thus printing out 0 or 1 instead of the name of
the declaration). To avoid that issue & simplify call sites, simply make
it the normal/expected operator<<(raw_ostream&, ...) overload & simplify
all the existing call sites. (bonus: this function doesn't need to be a
member or friend, it's just using public API in DeclarationName)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181832 91177308-0d34-0410-b5e6-96231b3b80d8
are now two distinct canonical 'AutoType's: one is the undeduced 'auto'
placeholder type, and the other is a deduced-but-dependent type. All
deduced-to-a-non-dependent-type cases are still non-canonical.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180789 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a regression I introduced in r178136, where we would not
consider the using directives from the semantic declaration contexts
that aren't represented by the lexical scopes (Scope) when performing
unqualified name lookup. This lead to horribly funny diagnostics like
"no identifier named 'foo'; did you mean 'foo'?".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179067 91177308-0d34-0410-b5e6-96231b3b80d8
Normal name lookup ignores any hidden declarations. When name lookup
for builtin declarations fails, we just synthesize a new
declaration at the point of use. With modules, this could lead to
multiple declarations of the same builtin, if one came from a (hidden)
submodule that was later made visible. Teach name lookup to always
find builtin names, so we don't create these redundant declarations in
the first place.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178711 91177308-0d34-0410-b5e6-96231b3b80d8
smarts so that it doesn't approve of keywords and/or type names when it
knows (based on its flags) that those kinds of corrections are not
wanted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178668 91177308-0d34-0410-b5e6-96231b3b80d8
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;
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177126 91177308-0d34-0410-b5e6-96231b3b80d8
This reduces the "ambiguous reference" errors (which are rather strange in C/ObjC) and fixes an assertion hit
with an invalid code test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175869 91177308-0d34-0410-b5e6-96231b3b80d8
consider (sub)module visibility.
The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:
visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.
known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.
visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.
known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.
The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.
Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.
Part two of <rdar://problem/10634711>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172665 91177308-0d34-0410-b5e6-96231b3b80d8
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170482 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
an implicit special member, rather than sometimes using '!hasDeclared<special
member>'. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169075 91177308-0d34-0410-b5e6-96231b3b80d8
getUnderlyingDecl()) so that derivatives of
CorrectionCandidateCallback::ValidateCandidate(...) don't have to worry
about being thrown by UsingDecls and such.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168317 91177308-0d34-0410-b5e6-96231b3b80d8
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165817 91177308-0d34-0410-b5e6-96231b3b80d8
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.
<rdar://problem/12296776>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164656 91177308-0d34-0410-b5e6-96231b3b80d8
This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159494 91177308-0d34-0410-b5e6-96231b3b80d8
are otherwise too short to try to correct.
The TODOs added to two of the tests are for existing deficiencies in the
typo correction code that could be exposed by using longer identifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158109 91177308-0d34-0410-b5e6-96231b3b80d8
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@158104 91177308-0d34-0410-b5e6-96231b3b80d8
but different nested name specifiers to quietly clobber each other so
only one remains if they do not refer to the same NamedDecl. Fixes
PR12951.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157823 91177308-0d34-0410-b5e6-96231b3b80d8
the confusion among all of the uses of Best* in relation to the set of
possible typo correction results. Also add a method to return the set of
typo corrections that have the single best edit distance--it returns the
second half of the first pair in TypoEditDistanceMap (with
getBestEditDistance already returning the first half).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157781 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to r155808 - this mistake has been made in a few iterators.
Based on Chandler Carruth's feedback to r155808 I added an implicit conversion
to Decl* to ease adoption/usage. Useful for the pointer comparison, but not the
dyn_cast (due to template argument deduction causing the conversion not to be
used) - there for future convenience, though. This idiom (op T* for iterators)
seems to be fairly idiomatic within the LLVM codebase & I'll likely add it as I
fix up the other iterators here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155869 91177308-0d34-0410-b5e6-96231b3b80d8
non-const reference parameter type if the class had any subobjects with deleted
copy constructors. This causes a rejects-valid if the class's copy constructor
is explicitly defaulted (as happens for some implementations of std::pair etc).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155218 91177308-0d34-0410-b5e6-96231b3b80d8
a view over the contents of a DeclContext without exposing the implementation
details of the StoredDeclsMap. Use this in LookupVisibleDecls to find the
visible declarations. Fixes PR12339!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153970 91177308-0d34-0410-b5e6-96231b3b80d8
Infinite recursion was happening when DiagnoseInvalidRedeclaration
called ActOnFunctionDeclarator to check if a typo correction works when
the correction was just to the nested-name-specifier because the wrong
DeclContext was being passed in. Unlike a number of functions
surrounding typo correction, the DeclContext passed in for a function is
the context of the function name after applying any nested name
specifiers, not the lexical DeclContext where the
function+nested-name-specifier appears.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153962 91177308-0d34-0410-b5e6-96231b3b80d8
typo correction to introduce a nested-name-specifier; we aren't
prepared to handle it here. Fixes PR12297 / <rdar://problem/11075219>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153445 91177308-0d34-0410-b5e6-96231b3b80d8
don't, and clean up the places that do it.
The change to ASTWriter is surprising, but the deleted code is a no-op as of
r152608.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152609 91177308-0d34-0410-b5e6-96231b3b80d8
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152608 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
When an error made a record member invalid, the record would stay as "isBeingDefined" and
not "completeDefinition". Even easily recoverable errors ended up propagating records in
such "beingDefined" state, for example:
struct A {
~A() const; // expected-error {{'const' qualifier is not allowed on a destructor}}
};
struct B : A {}; // A & B would stay as "not complete definition" and "being defined".
This weird state was impending lookups in the records and hitting assertion in the ASTWriter.
Part of rdar://11007039
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152432 91177308-0d34-0410-b5e6-96231b3b80d8
associated classes, since it can find friend functions declared within them,
but overload resolution does not otherwise require argument types to be
complete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151434 91177308-0d34-0410-b5e6-96231b3b80d8
decent diagnostics. Finish the work of combining all the 'ShouldDelete'
functions into one. In unifying the code, fix a minor bug where an anonymous
union with a deleted default constructor as a member of a union wasn't being
considered as making the outer union's default constructor deleted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150862 91177308-0d34-0410-b5e6-96231b3b80d8
Snooping in other namespaces when the identifier being corrected is
already qualified (i.e. a valid CXXScopeSpec is passed to CorrectTypo)
and ranking synthesized namespace qualifiers relative to the existing
qualifier is now performed. Support for disambiguating the string
representation of synthesized namespace qualifers has also been added
(the change to test/Parser/cxx-using-directive.cpp is an example of an
ambiguous relative qualifier).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150622 91177308-0d34-0410-b5e6-96231b3b80d8
Replace the simple Levenshtein edit distance for typo correction
candidates--and the hacky way adding namespace qualifiers would affect
the edit distance--with a synthetic "edit distance" comprised of several
factors and their relative weights. This also allows the typo correction
callback object to convey more information about the viability of a
correction candidate than simply viable or not viable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150495 91177308-0d34-0410-b5e6-96231b3b80d8
MaxEditDistance was effectively unused as it being initialized to the max
unsigned valued but never updated. Removing it avoids conversion
headaches once the "edit distance" of a typo correction is a weighted
composite of several values instead of roughly the number of characters
changed; comparing the weighted composite value to the number of
characters in a typo would require some form of normalization to make it
comparable to the old, character-based notion of edit distance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149953 91177308-0d34-0410-b5e6-96231b3b80d8
cleans up and improves a few things:
- We get rid of the ugly dance of computing all of the captures in
data structures that clone those of CapturingScopeInfo, centralizing
the logic for accessing/updating these data structures
- We re-use the existing capture logic for 'this', which actually
works now.
Cleaned up some diagnostic wording in minor ways as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149516 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, for unqualified lookups, a positive cache hit is used as the
only non-keyword correction and a negative cache hit immediately returns
an empty TypoCorrection. With the new callback objects, this behavior
causes false negatives by not accounting for the fact that callback
objects alter the set of potential/allowed corrections. The new behavior
is to seed the set of corrections with the cached correction (for
positive hits) to estabilishing a baseline edit distance. Negative cache
hits are only stored or used when either no callback object is provided
or when it returns true for a call to ValidateCandidate with an empty
TypoCorrection (i.e. when ValidateCandidate does not seem to be doing
any checking of the TypoCorrection, such as when an instance of the base
callback class is used solely to specify the set of keywords to be accepted).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148720 91177308-0d34-0410-b5e6-96231b3b80d8
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).
Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148187 91177308-0d34-0410-b5e6-96231b3b80d8
multiple name lookup results in C/Objective-C. Fixes a regression a
caused in r147533, found by Enea Zaffanella!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148154 91177308-0d34-0410-b5e6-96231b3b80d8
are still added if the cached correction fails validation.
Also fix a copy-and-paste error in a comment from my previous commit.
Finally, add an example of the benefit the typo correction callback adds
to TryNamespaceTypoCorrection--which happens to also tickle the above
caching problem, as the only way a non-namespace Decl would be added to
the possible corrections is if it was cached as the correction for a
previous instance of the same typo where the typo was corrected to a
non-namespace via a different code path.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147968 91177308-0d34-0410-b5e6-96231b3b80d8
Also includes two examples of the callback: a wrapper/replacement for
the CorrectTypoContext enum, and a conversion of the two calls to
CorrectTypo in SemaDeclCXX.cpp (one of which provides verifiable
improvement to the typo correction, as demonstrated in the added test).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147962 91177308-0d34-0410-b5e6-96231b3b80d8
to Redeclarable<NamespaceDecl>, so that we benefit from the improveed
redeclaration deserialization and merging logic provided by
Redeclarable<T>. Otherwise, no functionality change.
As a drive-by fix, collapse the "inline" bit into the low bit of the
original namespace/anonymous namespace, saving 8 bytes per
NamespaceDecl on x86_64.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147729 91177308-0d34-0410-b5e6-96231b3b80d8
chain to determine whether any declaration of the given entity is
visible, eliminating the redundant (and less efficient)
getPreviousDeclaration() implementation.
This tweak uncovered an omission in the handling of
RedeclarableTemplateDecl, where we weren't making sure to search for
additional redeclarations of a template in other module files. Things
would be cleaner if RedeclarableTemplateDecl actually used Redeclarable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147687 91177308-0d34-0410-b5e6-96231b3b80d8
to see hidden declarations because every tag lookup is effectively a
redeclaration lookup. For example, image that
struct foo;
is declared in a submodule that is known but hasn't been imported. If
someone later writes
struct foo *foo_p;
then "struct foo" is either a reference or a redeclaration. To keep
the redeclaration chains sound, we treat it like a redeclaration for
name-lookup purposes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147588 91177308-0d34-0410-b5e6-96231b3b80d8
modules, so long as the typedefs refer to the same underlying
type. This ensures that the typedefs end up in the same redeclaration
chain.
To test this, fix name lookup for C/Objective-C to properly deal with
multiple declarations with the same name in the same scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147533 91177308-0d34-0410-b5e6-96231b3b80d8
the AST reader doesn't actually perform a merge, because name lookup
knows how to merge identical typedefs together.
As part of this, teach C/Objective-C name lookup to return multiple
results in all cases, rather than first digging through the attributes
to see if the value is overloadable. This way, we'll catch ambiguous
lookups in C/Objective-C.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147498 91177308-0d34-0410-b5e6-96231b3b80d8
forward declarations and definitions of an Objective-C protocol are
represented within a single chain of ObjCProtocolDecls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147412 91177308-0d34-0410-b5e6-96231b3b80d8
for Objective-C protocols, 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 that we know which declaration is the definition
- Serialization support for redeclaration chains and for adding
definitions to already-serialized declarations.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCProtocolDecls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147410 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
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
Basically typo correction will try to offer a correction instead of looking into type dependent base classes.
I found this problem while parsing Microsoft ATL code with clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145772 91177308-0d34-0410-b5e6-96231b3b80d8
unknown specialization, treat this the same way as if the name were
not found in the current instantiation. No actual functionality
change, since apparently nothing depends on this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142862 91177308-0d34-0410-b5e6-96231b3b80d8
synthesis. This new feature is currently placed under
-fobjc-default-synthesize-properties option
and is off by default pending further testing.
It will become the default feature soon.
// rdar://8843851
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138913 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the code duplication of implicit special member handling even worse,
but the cleanup will have to come later. For now, this works.
Follow-up with tests for explicit defaulting and enabling the __has_feature
flag to come.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138821 91177308-0d34-0410-b5e6-96231b3b80d8
, such as list of forward @class decls, in a DeclGroup
node. Deal with its consequence throught clang. This
is in preparation for more Sema work ahead. // rdar://8843851.
Feel free to reverse if it breaks something important
and I am unavailable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138709 91177308-0d34-0410-b5e6-96231b3b80d8
Change TypoCorrection to store a set of NamedDecls instead of a single
NamedDecl. Also add initial support for performing function overload
resolution to Sema::DiagnoseEmptyLookup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136807 91177308-0d34-0410-b5e6-96231b3b80d8
implicit ivar accesses to go through the 'self' variable
rather than the real 'self' for the method. // rdar://9730771
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134992 91177308-0d34-0410-b5e6-96231b3b80d8
It would be cool if we could do overload resolution to suggest
the right function, but at least this fixes the crashing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134976 91177308-0d34-0410-b5e6-96231b3b80d8
to the same declaration when correcting typos. This is done by
essentially sorting the corrections as they're added.
Original patch by Kaelyn Uhrain, but modified for style and correctness
by accounting for more than just the textual spelling.
This still is a bit of a WIP hack to make this deterministic. Kaelyn
(and myself) are working on a more principled solution going forward.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134038 91177308-0d34-0410-b5e6-96231b3b80d8
up several places where we never expect to have NULL pointers to assert
early.
This fixes a valgrind error within CorrectTypo, but not the
non-determinism.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134032 91177308-0d34-0410-b5e6-96231b3b80d8
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134007 91177308-0d34-0410-b5e6-96231b3b80d8
conventions. I then discovered a typo in the using declaration bit in
LookupSpecialMember. This led to discovering [namespace.udecl]p15, which
clang implements incorrectly. Thus I've added a comment and implemented
the code consistently with the rest of clang - that is incorrectly.
And because I don't want to include tests of something incorrect, I've
ripped the test out.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133784 91177308-0d34-0410-b5e6-96231b3b80d8
FunctionTemplateDecl. I'm not quite sure what else it could be, though,
and would appreciate some insight.
This ought to fix the broken builds
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133600 91177308-0d34-0410-b5e6-96231b3b80d8
lookup. Previously, it was breaking self-host, but it's been a week and
a half and I can't reproduce, so I need to see if it's still failing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133581 91177308-0d34-0410-b5e6-96231b3b80d8
I believe, upon, careful review, that this code causes us to incorrectly
handle exception specifications of copy assignment operators in C++03
mode. However, we currently do not seem to properly implement the subtle
distinction between copying of members and bases made by implicit copy
constructors and assignment operators in C++03 - namely that they are
limited in their overload selection - in all cases. As such, I feel that
committing this code is correct pending a careful review of our
implementation of these semantics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132841 91177308-0d34-0410-b5e6-96231b3b80d8
isn't yet used for the less controlled environments of initialization.
Also a few random text fixups.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132833 91177308-0d34-0410-b5e6-96231b3b80d8
destructors are implemented but other special members are on the way,
which is where the real benefits of this will be visible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@132572 91177308-0d34-0410-b5e6-96231b3b80d8
hasTrivialDefaultConstructor() really really means it now.
Also implement a fun standards bug regarding aggregates. Doug, if you'd
like, I can un-implement that bug if you think it is truly a defect.
The bug is that non-special-member constructors are never considered
user-provided, so the following is an aggregate:
struct foo {
foo(int);
};
It's kind of bad, but the solution isn't obvious - should
struct foo {
foo (int) = delete;
};
be an aggregate or not?
Lastly, add a missing initialization to FunctionDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131101 91177308-0d34-0410-b5e6-96231b3b80d8
provides proper support for. This was caught by
-Wundefined-reinterpret-cast, and I think a reasonable case for it to
warn on.
Also use is<...> instead of dyn_cast<...> when the result isn't needed.
This whole thing should probably switch to using UsuallyTinyPtrVector.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130707 91177308-0d34-0410-b5e6-96231b3b80d8
Add an interface for last resort, unqualified lookup. It can provide results for unqualified lookup when Sema fails to find anything itself.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126387 91177308-0d34-0410-b5e6-96231b3b80d8
bugs from other clients that don't expect to see a LabelDecl in a DeclStmt,
but if so they should be easy to fix.
This implements most of PR3429 and rdar://8287027
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125817 91177308-0d34-0410-b5e6-96231b3b80d8
expansions with something that is easier to use correctly: a new
template argment kind, rather than a bit on an existing kind. Update
all of the switch statements that deal with template arguments, fixing
a few latent bugs in the process. I"m happy with this representation,
now.
And, oh look! Template instantiation and deduction work for template
template argument pack expansions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122896 91177308-0d34-0410-b5e6-96231b3b80d8
don't have access to (e.g., fprintf, which needs the library type
FILE), fail with a warning and forget about the builtin
entirely. Previously, we would actually provide an error, which breaks
autoconf's super-lame checks for fprintf, longjmp, etc. Fixes PR8316.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122744 91177308-0d34-0410-b5e6-96231b3b80d8
class to be passed around. The line between argument and return types and
everything else is kindof vague, but I think it's justifiable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121752 91177308-0d34-0410-b5e6-96231b3b80d8
global code completions are disabled (e.g., because they are
cached). Also, make sure that forward-declared protocols are visited
when we look for all visible names within a declaration context.
Previously, we would end up with duplicate completions for protocols.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121416 91177308-0d34-0410-b5e6-96231b3b80d8
a specific language. We are adding such language info. by
extensing Builtins.def and via a language flag added
to LIBBUILTIN/BUILTIN and check for that when deciding
a name is builtin or not. Implements //rdar://8689273.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120429 91177308-0d34-0410-b5e6-96231b3b80d8
typo. This can happen with context-sensitive keywords like "super",
when typo correction didn't know that "super" wasn't permitted in this
context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117372 91177308-0d34-0410-b5e6-96231b3b80d8
members in class subobjects of different types. So long as the
underlying declaration sets are the same, and the declaration sets
involve non-instance members, this is not an ambiguity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117163 91177308-0d34-0410-b5e6-96231b3b80d8
kinds of lookup into Objective-C classes were tangled together, a
situation that was compounded by automatically synthesized ivars.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116907 91177308-0d34-0410-b5e6-96231b3b80d8
don't repeatedly loop through identifiers, correcting the same typo'd
identifier over and over again.
We still bail out after 20 typo corrections, but this should help
improve performance in the common case where we're typo-correcting
because the user forgot to include a header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116901 91177308-0d34-0410-b5e6-96231b3b80d8
computation to compute the lower bound of the edit distance, so that
we can avoid computing the edit distance for names that will clearly
be rejected later. Since edit distance is such an expensive algorithm
(M x N), this leads to a 7.5x speedup when correcting NSstring ->
NSString in the presence of a Cocoa PCH.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116849 91177308-0d34-0410-b5e6-96231b3b80d8
we did was an acceptable lookup. If it is, then we can re-use that
lookup result. If it isn't, we have to perform the lookup again. This
is almost surely the cause behind the mysterious typo.m failures on
some builders; we were getting the wrong lookup results returned.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116586 91177308-0d34-0410-b5e6-96231b3b80d8
typo correction prefers "super" over other, equivalent completions. I
believe this will fix the regression on the buildbot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116574 91177308-0d34-0410-b5e6-96231b3b80d8
identifiers to determine good typo-correction candidates. Once we've
identified those candidates, we perform name lookup on each of them
and the consider the results.
This optimization makes typo correction > 2x faster on a benchmark
example using a single typo (NSstring) in a tiny file that includes
Cocoa.h from a precompiled header, since we are deserializing far less
information now during typo correction.
There is a semantic change here, which is interesting. The presence of
a similarly-named entity that is not visible can now affect typo
correction. This is both good (you won't get weird corrections if the
thing you wanted isn't in scope) and bad (you won't get good
corrections if there is a similarly-named-but-completely-unrelated
thing). Time will tell whether it was a good choice or not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116528 91177308-0d34-0410-b5e6-96231b3b80d8
solely based on the names it sees, rather than actual declarations it
gets. In essence, we determine the set of names that are "close
enough" to the typo'd name. Then, we perform name lookup for each of
those names, filtering out those that aren't actually visible, and
typo-correct from the remaining results.
Overall, there isn't much of a change in the behavior of typo
correction here. The only test-suite change comes from the fact that
we make good on our promise to require that the user type 3 characters
for each 1 character corrected.
The real intent behind this change is to set the stage for an
optimization to typo correction (so that we don't need to deserialize
all declarations in a translation unit) and future work in finding
missing qualification ("'vector' isn't in scope; did you mean
'std::vector'?). Plus, the code is cleaner this way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116511 91177308-0d34-0410-b5e6-96231b3b80d8
(and thus protocol_begin(), protocol_end()) now only contains the list of protocols that were directly referenced in
an @interface declaration. 'all_referenced_protocol_[begin,end]()' now returns the set of protocols that were referenced
in both the @interface and class extensions. The latter is needed for semantic analysis/codegen, while the former is
needed to maintain the lexical information of the original source.
Fixes <rdar://problem/8380046>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112691 91177308-0d34-0410-b5e6-96231b3b80d8
#include Sema.h while keeping all the AST declarations opaque. That may
not be reasonably attainable, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111907 91177308-0d34-0410-b5e6-96231b3b80d8
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111667 91177308-0d34-0410-b5e6-96231b3b80d8
declarations (in addition to macros). Each kind of declaration maps to
a certain set of completion contexts, and the ASTUnit completion logic
introduces the completion strings for those declarations if the actual
code-completion occurs in one of the contexts where it matters.
There are a few new code-completion-context kinds. Without these,
certain completions (e.g., after "using namespace") would need to
suppress all global completions, which would be unfortunate.
Note that we don't get the priorities right for global completions,
because we don't have enough type information. We'll need a way to
compare types in an ASTContext-agnostic way before this can be
implemented.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111093 91177308-0d34-0410-b5e6-96231b3b80d8
that actually refer to the same underlying type, it is not an
ambiguity; add uniquing support based on the canonical type of type
declarations. Fixes <rdar://problem/8296180>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110806 91177308-0d34-0410-b5e6-96231b3b80d8
spell-checking. By default, spell-checking is enabled for Clang
(obviously) but disabled in CIndex for performance reasons.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107992 91177308-0d34-0410-b5e6-96231b3b80d8
declarations for implicit default constructors, copy constructors,
copy assignment operators, and destructors. On a "simple" translation
unit that includes a bunch of C++ standard library headers, we
generate relatively few of these implicit declarations now:
4/159 implicit default constructors created
18/236 implicit copy constructors created
70/241 implicit copy assignment operators created
0/173 implicit destructors created
And, on this translation unit, this optimization doesn't really
provide any benefit. I'll do some more performance measurements soon,
but this completes the implementation work for <rdar://problem/8151045>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107551 91177308-0d34-0410-b5e6-96231b3b80d8
the x86-64 __va_list_tag with this attribute. The attribute causes the
affected type to behave like a fundamental type when considered by ADL.
(x86-64 is the only target we currently provide with a struct-based
__builtin_va_list)
Fixes PR6762.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104941 91177308-0d34-0410-b5e6-96231b3b80d8
class for UnresolvedLookupExprs, even when occuring on template
names" along with a fix for an Objective-C++ crasher it introduced.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104277 91177308-0d34-0410-b5e6-96231b3b80d8
instance variables:
- Use isRecordType() rather than isa<RecordType>(), so that we see
through typedefs in ivar types.
- Mark the destructor as referenced
- Perform C++ access control on the destructor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104206 91177308-0d34-0410-b5e6-96231b3b80d8
template names. We were completely missing naming classes for many unqualified
lookups, but this didn't trigger code paths that need it. This removes part of
an optimization that re-uses the template name lookup done by the parser to
determine if explicit template arguments actually form a template-id.
Unfortunately the technique for avoiding the duplicate lookup lost needed data
such as the class context in which the lookup succeeded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104117 91177308-0d34-0410-b5e6-96231b3b80d8
non-function-local declarations with names similar to what the user
typed. For example, this allows us to correct 'supper' to 'super' in
an Objective-C message send, even though the C function 'isupper' has
the same edit distance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104023 91177308-0d34-0410-b5e6-96231b3b80d8
consider "super" as a candidate whenever we're parsing an expression
within an Objective-C method in an interface that has a superclass. At
some point, we'd like to give "super" a little edge over non-local
names; that will come later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104022 91177308-0d34-0410-b5e6-96231b3b80d8
already knows what context it's looking in. Just pass that context in
instead of (questionably) recalculating it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102818 91177308-0d34-0410-b5e6-96231b3b80d8
using declaration, look at its underlying declaration to determine the
lookup result kind (e.g., overloaded, unresolved). Fixes at least one
issue in Boost.Bimap.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102317 91177308-0d34-0410-b5e6-96231b3b80d8
way that C does. Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might imagine, does not
include typedefs. Rework our use of IDNS masks to capture the semantics
of different kinds of declarations better, and remove most current lookup
filters. Removing the last remaining filter is more complicated and will
happen in a separate patch.
Fixes PR 6885 as well some spectrum of unfiled bugs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102164 91177308-0d34-0410-b5e6-96231b3b80d8
aren't and never were used. There's a gap in the bit pattern for IDNS
now, but I'm sure *someone* will fill it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102143 91177308-0d34-0410-b5e6-96231b3b80d8
look from an Objective-C class or category to its implementation, to
pick up synthesized ivars. Fixes a problem reported by David
Chisnall.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101792 91177308-0d34-0410-b5e6-96231b3b80d8
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101412 91177308-0d34-0410-b5e6-96231b3b80d8
generally recover from typos in keywords (since we would effectively
have to mangle the token stream). However, there are still benefits to
typo-correcting with keywords:
- We don't make stupid suggestions when the user typed something
that is similar to a keyword.
- We can suggest the keyword in a diagnostic (did you mean
"static_cast"?), even if we can't recover and therefore don't have
a fix-it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101274 91177308-0d34-0410-b5e6-96231b3b80d8
than just a bool indicating that correction occurred. No actual
functionality change (it's still always used like a bool), but this
refactoring will be used to support typo correction to keywords.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101259 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces FunctionType::ExtInfo to hold the calling convention and the
noreturn attribute. The next patch will extend it to include the regparm
attribute and fix the bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99920 91177308-0d34-0410-b5e6-96231b3b80d8
operators, make sure that the implicitly-declared global new and
delete operators are always available. Fixes PR5904.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99382 91177308-0d34-0410-b5e6-96231b3b80d8
access to the (elevated) access of the accessed declaration, if applicable,
rather than plunking that access onto the end after we've calculated the
inheritance access.
Also, being a friend of a derived class gives you public access to its
members (subject to later modification by further inheritance); it does
not simply ignore a single location of restricted inheritance.
Also, when computing the best unprivileged path to a subobject, preserve
the information that the worst path might be AS_none (forbidden) rather
than a minimum of AS_private.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98899 91177308-0d34-0410-b5e6-96231b3b80d8
comparing DeclContext pointers, to avoid having to remember to call
getPrimaryContext() everywhere. This is the last part PR6594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98546 91177308-0d34-0410-b5e6-96231b3b80d8
parameter hides a namespace-scope declararion with the same name in an
out-of-line definition of a template. The lookup requires a strange
interleaving of lexical and semantic scopes (go C++), which I have not
yet handled in the typo correction/code completion path.
Fixes PR6594.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98544 91177308-0d34-0410-b5e6-96231b3b80d8
fixing up a few callers that thought they were propagating NoReturn
information but were in fact saying something about exception
specifications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96766 91177308-0d34-0410-b5e6-96231b3b80d8
from an instance method. Previously, we were following the Objective-C
name lookup rules for ivars, which are of course completely different
from and incompatible with the Objective-C++ rules.
For the record, the Objective-C++ rules are the sane ones.
This is another part of <rdar://problem/7660386>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96677 91177308-0d34-0410-b5e6-96231b3b80d8
conversions. Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path. Prepare for friends.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95775 91177308-0d34-0410-b5e6-96231b3b80d8
may be some other places that could take advantage of this new information,
but I haven't really looked yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95600 91177308-0d34-0410-b5e6-96231b3b80d8
context. This happens fairly rarely (which is why we got away with
this bug). Fixes PR6184, where we skipped over the template parameter
scope while tentatively parsing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95376 91177308-0d34-0410-b5e6-96231b3b80d8
category implementation, which showed up during (attempted) typo
correction. Fixes <rdar://problem/7605289>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95334 91177308-0d34-0410-b5e6-96231b3b80d8
of a C++ record. Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition. Also cuts down on memory usage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95330 91177308-0d34-0410-b5e6-96231b3b80d8
This is to address a serious performance problem observed when running
'clang -fsyntax-only' on really broken source files. In one case,
repeatedly calling CorrectTypo() caused one source file to be rejected
after 2 minutes instead of 1 second.
This patch causes typo correction to take neglible time on that file
while still providing correction results for the first 20 cases. I
felt this was a reasonable number for moderately broken source files.
I don't claim this is the best solution. Comments welcome. It is
necessary for us to address this issue because it is a serious
performance problem.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95049 91177308-0d34-0410-b5e6-96231b3b80d8
change.
PS: I'm under the impression formatting-only patches don't need pre-commit
review, but feel free to yell at me if I should post these first! =D
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94956 91177308-0d34-0410-b5e6-96231b3b80d8
This solution relies on an O(n) scan of redeclarations, which means it might
scale poorly in crazy cases with tons of redeclarations brought in by a ton
of distinct associated namespaces. I believe that avoiding this
is not worth the common-case cost.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94530 91177308-0d34-0410-b5e6-96231b3b80d8
Triggers lots of assertions about missing access information; fix them.
Will actually consume this information soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94038 91177308-0d34-0410-b5e6-96231b3b80d8
Change LookupResult to use UnresolvedSet. Also extract UnresolvedSet into its
own header and make it templated over an inline capacity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93959 91177308-0d34-0410-b5e6-96231b3b80d8
do not look into base classes if there are any dependent base
classes. Instead, note in the lookup result that we couldn't look into
any dependent bases. Use that new result kind to detect when this case
occurs, so that we can fall back to treating the type/value/etc. as a
member of an unknown specialization.
Fixes an issue where we were resolving lookup at template definition
time and then missing an ambiguity at template instantiation time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93497 91177308-0d34-0410-b5e6-96231b3b80d8
after adding the ability to determine whether our lookup is a
base-class lookup. Eliminate CollectMemberLookupResults, since it is
no longer used (yay).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93428 91177308-0d34-0410-b5e6-96231b3b80d8
(C++ [temp.mem]p5-6), which involves template argument deduction based
on the type named, e.g., given
struct X { template<typename T> operator T*(); } x;
when we call
x.operator int*();
we perform template argument deduction to determine that T=int. This
template argument deduction is needed for template specialization and
explicit instantiation, e.g.,
template<> X::operator float*() { /* ... */ }
and when calling or otherwise naming a conversion function (as in the
first example).
This fixes PR5742 and PR5762, although there's some remaining ugliness
that's causing out-of-line definitions of conversion function
templates to fail. I'll look into that separately.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93162 91177308-0d34-0410-b5e6-96231b3b80d8
we look into a Scope that corresponds to a compound statement whose
scope was combined with the scope of the function that owns it. This
improves typo correction in many common cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92879 91177308-0d34-0410-b5e6-96231b3b80d8
constructs:
- Instance variable lookup ("foo->ivar" and, in instance methods, "ivar")
- Property name lookup ("foo.prop")
- Superclasses
- Various places where a class name is required
- Protocol names (e.g., id<proto>)
This seems to cover many of the common places where typos could occur.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92449 91177308-0d34-0410-b5e6-96231b3b80d8
typo.cpp:22:10: error: use of undeclared identifier 'radious'; did
you mean 'radius'?
return radious * pi;
^~~~~~~
radius
This was super-easy, since we already had decent recovery by looking
for names in dependent base classes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92341 91177308-0d34-0410-b5e6-96231b3b80d8
tring str2;
we produce the following diagnostic + fix-it:
typo.cpp:15:1: error: unknown type name 'tring'; did you mean 'string'?
tring str2;
^~~~~
string
To make this really useful, we'll need to introduce typo correction in
many more places (wherever we do name lookup), and implement
declaration-vs-expression heuristics that cope with typos
better. However, for now this will handle the simple cases where we
already get good "unknown type name" diagnostics.
The LookupVisibleDecls functions are intended to be used by code
completion as well as typo correction; that refactoring will happen
later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92308 91177308-0d34-0410-b5e6-96231b3b80d8
address resolution. This fixes PR5751.
Also, while we're here, remove logic from ADL which mistakenly included the
definition namespaces of overloaded and/or templated functions whose name or
address is used as an argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92245 91177308-0d34-0410-b5e6-96231b3b80d8
nested-name specifier name.
I accidentally checked in the test case for this in the last commit ---
fortunately, that refactor was inspired by having debugged this problem already,
so I can fix the bug quick (though probably not fast enough for the buildbots).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91677 91177308-0d34-0410-b5e6-96231b3b80d8
different functions and pick the function at lookup initialization time.
In theory we could actually divide the criteria functions into N different
functions for the N cases, but it's so not worth it.
Among other things, lets us invoke LookupQualifiedName without recomputing
IDNS info every time.
Do some refactoring in SemaDecl to avoid an awkward special case in LQN
that was only necessary for redeclaration testing for anonymous structs/unions ---
which could be done more efficiently with a scoped lookup anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91676 91177308-0d34-0410-b5e6-96231b3b80d8
are a couple of O(n^2) operations in this, some analogous to the usual O(n^2)
redeclaration problem and some not. In particular, retroactively removing
shadow declarations when they're hidden by later decls is pretty unfortunate.
I'm not yet convinced it's worse than the alternative, though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91045 91177308-0d34-0410-b5e6-96231b3b80d8
into transparent contexts; instead, we'll look into their nearest
enclosing non-transparent contexts further up the stack. Fixes PR5479.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90859 91177308-0d34-0410-b5e6-96231b3b80d8
results in them (which we were doing intentionally as a stopgap). Fix
an DeclContext lookup-table ordering problem which was causing UsingDecls to
show up incorrectly when looking for ordinary results. And oh hey
Clang-Code-Syntax passes now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90367 91177308-0d34-0410-b5e6-96231b3b80d8
LookupResult::getAsSingleDecl() is no more. Shift Sema::LookupSingleName to
return null on overloaded results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90309 91177308-0d34-0410-b5e6-96231b3b80d8
DependentScopeDeclRefExpr support storing templateids. Unite the common
code paths between ActOnDeclarationNameExpr and ActOnTemplateIdExpr.
This gets us to a point where we don't need to store function templates in
the AST using TemplateNames, which is critical to ripping out OverloadedFunction.
Also resolves a few FIXMEs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89785 91177308-0d34-0410-b5e6-96231b3b80d8
into pretty much everything about overload resolution in order to wean
BuildDeclarationNameExpr off LookupResult::getAsSingleDecl(). Replace
UnresolvedFunctionNameExpr with UnresolvedLookupExpr, which generalizes the
idea of a non-member lookup that we haven't totally resolved yet, whether by
overloading, argument-dependent lookup, or (eventually) the presence of
a function template in the lookup results.
Incidentally fixes a problem with argument-dependent lookup where we were
still performing ADL even when the lookup results contained something from
a block scope.
Incidentally improves a diagnostic when using an ObjC ivar from a class method.
This just fell out from rewriting BuildDeclarationNameExpr's interaction with
lookup, and I'm too apathetic to break it out.
The only remaining uses of OverloadedFunctionDecl that I know of are in
TemplateName and MemberExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89544 91177308-0d34-0410-b5e6-96231b3b80d8
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89184 91177308-0d34-0410-b5e6-96231b3b80d8
strip the sugar off in getFoundDecl() and getAsSingleDecl(), but leave it on for
clients like overload resolution who want to use the iterators.
Refactor a few pieces of overload resolution to strip off using declarations in
a single place. Don't do anything useful with the extra context knowledge yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89061 91177308-0d34-0410-b5e6-96231b3b80d8
LookupResult RAII powers to diagnose ambiguity in the results. Other diagnostics
(e.g. access control and deprecation) will be moved to automatically trigger
during lookup as part of this same mechanism.
This abstraction makes it much easier to encapsulate aliasing declarations
(e.g. using declarations) inside the lookup system: eventually, lookup will
just produce the aliases in the LookupResult, and the standard access methods
will naturally strip the aliases off.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89027 91177308-0d34-0410-b5e6-96231b3b80d8
sugared types. The basic problem is that our qualifier accessors
(getQualifiers, getCVRQualifiers, isConstQualified, etc.) only look at
the current QualType and not at any qualifiers that come from sugared
types, meaning that we won't see these qualifiers through, e.g.,
typedefs:
typedef const int CInt;
typedef CInt Self;
Self.isConstQualified() currently returns false!
Various bugs (e.g., PR5383) have cropped up all over the front end due
to such problems. I'm addressing this problem by splitting each
qualifier accessor into two versions:
- the "local" version only returns qualifiers on this particular
QualType instance
- the "normal" version that will eventually combine qualifiers from this
QualType instance with the qualifiers on the canonical type to
produce the full set of qualifiers.
This commit adds the local versions and switches a few callers from
the "normal" version (e.g., isConstQualified) over to the "local"
version (e.g., isLocalConstQualified) when that is the right thing to
do, e.g., because we're printing or serializing the qualifiers. Also,
switch a bunch of
Context.getCanonicalType(T1).getUnqualifiedType() == Context.getCanonicalType(T2).getQualifiedType()
expressions over to
Context.hasSameUnqualifiedType(T1, T2)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@88969 91177308-0d34-0410-b5e6-96231b3b80d8
parameters. Rather than storing them as either declarations (for the
non-dependent case) or expressions (for the dependent case), we now
(always) store them as TemplateNames.
The primary change here is to add a new kind of TemplateArgument,
which stores a TemplateName. However, making that change ripples to
every switch on a TemplateArgument's kind, also affecting
TemplateArgumentLocInfo/TemplateArgumentLoc, default template
arguments for template template parameters, type-checking of template
template arguments, etc.
This change is light on testing. It should fix several pre-existing
problems with template template parameters, such as:
- the inability to use dependent template names as template template
arguments
- template template parameter default arguments cannot be
instantiation
However, there are enough pieces missing that more implementation is
required before we can adequately test template template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86777 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith