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!
llvm-svn: 153970
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.
llvm-svn: 153962
typo correction to introduce a nested-name-specifier; we aren't
prepared to handle it here. Fixes PR12297 / <rdar://problem/11075219>.
llvm-svn: 153445
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.
llvm-svn: 152608
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
llvm-svn: 152432
associated classes, since it can find friend functions declared within them,
but overload resolution does not otherwise require argument types to be
complete.
llvm-svn: 151434
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.
llvm-svn: 150862
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).
llvm-svn: 150622
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.
llvm-svn: 150495
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.
llvm-svn: 149953
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.
llvm-svn: 149516
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).
llvm-svn: 148720
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.
llvm-svn: 148187
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.
llvm-svn: 147968
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).
llvm-svn: 147962
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.
llvm-svn: 147729
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.
llvm-svn: 147687
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.
llvm-svn: 147588
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.
llvm-svn: 147533
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.
llvm-svn: 147498
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.
llvm-svn: 147410
visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.
As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.
Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.
llvm-svn: 146980
chains. The previous implementation relied heavily on the declaration
chain being stored as a (circular) linked list on disk, as it is in
memory. However, when deserializing from multiple modules, the
different chains could get mixed up, leading to broken declaration chains.
The new solution keeps track of the first and last declarations in the
chain for each module file. When we load a declaration, we search all
of the module files for redeclarations of that declaration, then
splice together all of the lists into a coherent whole (along with any
redeclarations that were actually parsed).
As a drive-by fix, (de-)serialize the redeclaration chains of
TypedefNameDecls, which had somehow gotten missed previously. Add a
test of this serialization.
This new scheme creates a redeclaration table that is fairly large in
the PCH file (on the order of 400k for Cocoa.h's 12MB PCH file). The
table is mmap'd in and searched via a binary search, but it's still
quite large. A future tweak will eliminate entries for declarations
that have no redeclarations anywhere, and should
drastically reduce the size of this table.
llvm-svn: 146841
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.
llvm-svn: 145772
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.
llvm-svn: 142862
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
llvm-svn: 138913
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.
llvm-svn: 138821
, 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.
llvm-svn: 138709
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.
llvm-svn: 136807
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.
llvm-svn: 134038
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.
llvm-svn: 134032
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
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.
llvm-svn: 133784
FunctionTemplateDecl. I'm not quite sure what else it could be, though,
and would appreciate some insight.
This ought to fix the broken builds
llvm-svn: 133600
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.
llvm-svn: 133581
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.
llvm-svn: 132841
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.
llvm-svn: 131101
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.
llvm-svn: 130707
Add an interface for last resort, unqualified lookup. It can provide results for unqualified lookup when Sema fails to find anything itself.
llvm-svn: 126387
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
llvm-svn: 125817
Benjamin Kramer