| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
multiple name lookup results in C/Objective-C. Fixes a regression a
caused in r147533, found by Enea Zaffanella!
llvm-svn: 148154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
consider whether this is a redeclaration lookup when determining whether to look for the visible declaration
llvm-svn: 147499
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
ObjCProtocolDecl modules forward declarations properly.
llvm-svn: 147415
|
| |
|
|
|
|
|
| |
forward declarations and definitions of an Objective-C protocol are
represented within a single chain of ObjCProtocolDecls.
llvm-svn: 147412
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
covers both declarations (@class) and definitions (@interface) of an
Objective-C class.
llvm-svn: 147299
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
check whether any previous declarations of the class were visible.
llvm-svn: 146680
|
| |
|
|
|
|
|
| |
is not visible, look for any previous declarations of that entity that
might be visible.
llvm-svn: 146563
|
| |
|
|
|
|
|
|
|
|
| |
function dependent context because it interferes with the "lookup into dependent bases of class templates" feature.
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
|
| |
|
|
| |
llvm-svn: 145700
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
for better self-documenting code, since the semantics
are subtly different from getDefinition().
llvm-svn: 141355
|
| |
|
|
|
|
|
|
| |
committed at the moment to help support C++0x <atomic>, but it should be a solid base for implementing the full specification of C1x _Atomic.
Thanks to Jeffrey Yasskin for the thorough review!
llvm-svn: 141330
|
| |
|
|
|
|
| |
available, but not accessible from the current code completion context.
llvm-svn: 141278
|
| |
|
|
| |
llvm-svn: 139252
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
| |
|
|
|
|
| |
ShadowMapEntry was.
llvm-svn: 135368
|
| |
|
|
|
|
|
| |
implicit ivar accesses to go through the 'self' variable
rather than the real 'self' for the method. // rdar://9730771
llvm-svn: 134992
|
| |
|
|
|
|
|
| |
It would be cool if we could do overload resolution to suggest
the right function, but at least this fixes the crashing.
llvm-svn: 134976
|
| |
|
|
| |
llvm-svn: 134403
|
| |
|
|
|
|
|
| |
"_Bool" (depending on dialect), but not both, since they have the same
edit distance from "Bool".
llvm-svn: 134263
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
don't rely on the existence of a copy constructor.
llvm-svn: 134009
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 133790
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 133671
|
| |
|
|
|
|
| |
implicit move tests.
llvm-svn: 133655
|
| |
|
|
| |
llvm-svn: 133604
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
to study it.
llvm-svn: 132843
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 132835
|
| |
|
|
|
|
|
|
| |
isn't yet used for the less controlled environments of initialization.
Also a few random text fixups.
llvm-svn: 132833
|