Summary:
Makes functions with implicit calling convention compatible with
function types with a matching explicit calling convention. This fixes
things like calls to qsort(), which has an explicit __cdecl attribute on
the comparator in Windows headers.
Clang will now infer the calling convention from the declarator. There
are two cases when the CC must be adjusted during redeclaration:
1. When defining a non-inline static method.
2. When redeclaring a function with an implicit or mismatched
convention.
Fixes PR13457, and allows clang to compile CommandLine.cpp for the
Microsoft C++ ABI.
Excellent test cases provided by Alexander Zinenko!
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1231
llvm-svn: 189412
loop processing the candidates can cause new declerations to be added to
the context, invalidating lookup_result. To avoid that, make a copy of
the list of declarations to iterate over.
I don't have a way to check in a test case for this as it involves
a giant pile of source code and a generated PCH file used to accelerate
code completion, all of this running under ASan.
llvm-svn: 188623
When a local extern declaration redeclares some other entity, the type of that
entity is merged with the prior type if the prior declaration is visible (in C)
or is declared in the same scope (in C++).
- Make LookupRedeclarationWithLinkage actually work in C++, use it in the right
set of cases, and make it track whether it found a shadowed declaration.
- Track whether we found a declaration in the same scope (for C++) including
across serialization and template instantiation.
llvm-svn: 188307
of local classes. We were previously handling this by performing qualified
lookup within a function declaration(!!); replace it with the proper scope
lookup.
llvm-svn: 188050
sufficient to only consider names visible at the point of instantiation,
because that may not include names that were visible when the template was
defined. More generally, if the instantiation backtrace goes through a module
M, then every declaration visible within M should be available to the
instantiation. Any of those declarations might be part of the interface that M
intended to export to a template that it instantiates.
The fix here has two parts:
1) If we find a non-visible declaration during name lookup during template
instantiation, check whether the declaration was visible from the defining
module of all entities on the active template instantiation stack. The defining
module is not the owning module in all cases: we look at the module in which a
template was defined, not the module in which it was first instantiated.
2) Perform pending instantiations at the end of a module, not at the end of the
translation unit. This is general goodness, since it significantly cuts down
the amount of redundant work that is performed in every TU importing a module,
and also implicitly adds the module containing the point of instantiation to
the set of modules checked for declarations in a lookup within a template
instantiation.
There's a known issue here with template instantiations performed while
building a module, if additional imports are added later on. I'll fix that
in a subsequent commit.
llvm-svn: 187167
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.
llvm-svn: 186546
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.
llvm-svn: 186331
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.
llvm-svn: 186199
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.
llvm-svn: 186185
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.
llvm-svn: 186040
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.
llvm-svn: 185487
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.
llvm-svn: 185486
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)
llvm-svn: 181832
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.
llvm-svn: 180789
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'?".
llvm-svn: 179067
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.
llvm-svn: 178711
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.
llvm-svn: 178668
This created 2 issues:
1) Performance issue, since typo-correction with PCH/modules is rather expensive.
2) Correctness issue, since if it managed to "correct" 'super' then bogus compiler errors would
be emitted, like this:
3.m:8:3: error: unknown type name 'super'; did you mean 'super1'?
super.x = 0;
^~~~~
super1
t3.m:5:13: note: 'super1' declared here
typedef int super1;
^
t3.m:8:8: error: expected identifier or '('
super.x = 0;
^
llvm-svn: 177126
This reduces the "ambiguous reference" errors (which are rather strange in C/ObjC) and fixes an assertion hit
with an invalid code test case.
llvm-svn: 175869
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>.
llvm-svn: 172665
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)
llvm-svn: 170482
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
getUnderlyingDecl()) so that derivatives of
CorrectionCandidateCallback::ValidateCandidate(...) don't have to worry
about being thrown by UsingDecls and such.
llvm-svn: 168317
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 ).
llvm-svn: 165817
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>.
llvm-svn: 164656
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.
llvm-svn: 159494
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.
llvm-svn: 158109
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.
llvm-svn: 158104
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.
llvm-svn: 157823
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).
llvm-svn: 157781
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.
llvm-svn: 155869
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).
llvm-svn: 155218
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
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.
llvm-svn: 122896
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.
llvm-svn: 122744
class to be passed around. The line between argument and return types and
everything else is kindof vague, but I think it's justifiable.
llvm-svn: 121752
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.
llvm-svn: 121416
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.
llvm-svn: 120429
typo. This can happen with context-sensitive keywords like "super",
when typo correction didn't know that "super" wasn't permitted in this
context.
llvm-svn: 117372
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.
llvm-svn: 117163
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.
llvm-svn: 116901
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.
llvm-svn: 116849
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.
llvm-svn: 116586
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.
llvm-svn: 116528
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.
llvm-svn: 116511
(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>.
llvm-svn: 112691
- 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.
llvm-svn: 111667
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.
llvm-svn: 111093
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>.
llvm-svn: 110806
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>.
llvm-svn: 107551
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.
llvm-svn: 104941
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
llvm-svn: 104206
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.
llvm-svn: 104117
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.
llvm-svn: 104023
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.
llvm-svn: 104022
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.
llvm-svn: 102317
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.
llvm-svn: 102164
look from an Objective-C class or category to its implementation, to
pick up synthesized ivars. Fixes a problem reported by David
Chisnall.
llvm-svn: 101792
in case it ends up doing something that might trigger diagnostics
(template instantiation, ambiguity reporting, access
reporting). Noticed while working on PR6831.
llvm-svn: 101412
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.
llvm-svn: 101274
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.
llvm-svn: 101259
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.
llvm-svn: 99920
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.
llvm-svn: 98899
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.
llvm-svn: 98544
fixing up a few callers that thought they were propagating NoReturn
information but were in fact saying something about exception
specifications.
llvm-svn: 96766
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>.
llvm-svn: 96677
conversions. Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path. Prepare for friends.
llvm-svn: 95775
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.
llvm-svn: 95376
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.
llvm-svn: 95330
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.
llvm-svn: 95049
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
llvm-svn: 94956
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.
llvm-svn: 94530
Change LookupResult to use UnresolvedSet. Also extract UnresolvedSet into its
own header and make it templated over an inline capacity.
llvm-svn: 93959
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.
llvm-svn: 93497
after adding the ability to determine whether our lookup is a
base-class lookup. Eliminate CollectMemberLookupResults, since it is
no longer used (yay).
llvm-svn: 93428
(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.
llvm-svn: 93162
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.
llvm-svn: 92879
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.
llvm-svn: 92449
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.
llvm-svn: 92341
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.
llvm-svn: 92308
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.
llvm-svn: 92245
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).
llvm-svn: 91677
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.
llvm-svn: 91676
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.
llvm-svn: 91045
into transparent contexts; instead, we'll look into their nearest
enclosing non-transparent contexts further up the stack. Fixes PR5479.
llvm-svn: 90859
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.
llvm-svn: 90367
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.
llvm-svn: 89785
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.
llvm-svn: 89544
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.
llvm-svn: 89184
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.
llvm-svn: 89061
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.
llvm-svn: 89027
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)
llvm-svn: 88969
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.
llvm-svn: 86777
using directives, and fix a bug thereby exposed: since we're playing
tricks with pointers, we need to make certain we're always using the same
pointers for things.
Also tweak an existing error message.
llvm-svn: 86679
for bases, members, overridden virtual methods, etc. The operations
isDerivedFrom and lookupInBases are now provided by CXXRecordDecl,
rather than by Sema, so that CodeGen and other clients can use them
directly.
llvm-svn: 83396
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
all of the parent DeclContexts that aren't represented within the
Scope chain. This fixes some name-lookup problems in out-of-line
definitions of members of nested classes.
llvm-svn: 81451
x->Base::f
We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.
We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.
I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.
llvm-svn: 80843
declarations of same, introduce a single AST class and add appropriate bits
(encoded in the namespace) for whether a decl is "real" or not. Much hackery
about previously-declared / not-previously-declared, but it's essentially
mandated by the standard that friends alter lookup, and this is at least
fairly non-intrusive.
Refactor the Sema methods specific to friends for cleaner flow and less nesting.
Incidentally solve a few bugs, but I remain confident that we can put them back.
llvm-svn: 80353
their members, including member class template, member function
templates, and member classes and functions of member templates.
To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,
template<typename X> template<typename Y>
X Outer<X>::Inner1<Y>::foo(Y) {
return X();
}
we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.
Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.
llvm-svn: 80044
FriendFunctionDecl, and create instances as appropriate.
The design of FriendFunctionDecl is still somewhat up in the air; you can
befriend arbitrary types of functions --- methods, constructors, etc. ---
and it's not clear that this representation captures that very well.
We'll have a better picture when we start consuming this data in access
control.
llvm-svn: 78653
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
llvm-svn: 77510
A template name can refer to a set of overloaded function
templates. Model this in TemplateName, which can now refer to an
OverloadedFunctionDecl that contains function templates. This removes
an unspeakable hack in Sema::isTemplateName.
llvm-svn: 77488
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
llvm-svn: 76193
This method is intended to eventually replace the individual
Type::getAsXXXType<> methods.
The motivation behind this change is twofold:
1) Reduce redundant implementations of Type::getAsXXXType() methods. Most of
them are basically copy-and-paste.
2) By centralizing the implementation of the getAs<Type> logic we can more
smoothly move over to Doug Gregor's proposed canonical type smart pointer
scheme.
Along with this patch:
a) Removed 'Type::getAsPointerType()'; now clients use getAs<PointerType>.
b) Removed 'Type::getAsBlockPointerTypE()'; now clients use getAs<BlockPointerType>.
llvm-svn: 76098
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
llvm-svn: 74506
The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.
This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.
llvm-svn: 74501
templates.
For example, this now type-checks (but does not instantiate the body
of deref<int>):
template<typename T> T& deref(T* t) { return *t; }
void test(int *ip) {
int &ir = deref(ip);
}
Specific changes/additions:
* Template argument deduction from a call to a function template.
* Instantiation of a function template specializations (just the
declarations) from the template arguments deduced from a call.
* FunctionTemplateDecls are stored directly in declaration contexts
and found via name lookup (all forms), rather than finding the
FunctionDecl and then realizing it is a template. This is
responsible for most of the churn, since some of the core
declaration matching and lookup code assumes that all functions are
FunctionDecls.
llvm-svn: 74213
<rdar://problem/6952203>.
To do this, we actually remove a not-quite-correct optimization in the
C++ name lookup routines. We'll revisit this optimization for the
general case once more C++ is working.
llvm-svn: 73659
preprocessor and initialize it early in clang-cc. This
ensures that __has_builtin works in all modes, not just
when ASTContext is around.
llvm-svn: 73319
references. There are several smallish fixes here:
- Make sure we look through template parameter scope when
determining whether we're parsing a nested class (or nested class
*template*). This makes sure that we delay parsing the bodies of
inline member functions until after we're out of the outermost
class (template) scope.
- Since the bodies of member functions are always parsed
"out-of-line", even when they were declared in-line, teach
unqualified name lookup to look into the (semantic) parents.
- Use the new InstantiateDeclRef to handle the instantiation of a
reference to a declaration (in DeclRefExpr), which drastically
simplifies template instantiation for DeclRefExprs.
- When we're instantiating a ParmVarDecl, it must be in the current
instantiation scope, so only look there.
Also, remove the #if 0's and FIXME's from the dynarray example, which
now compiles and executes thanks to Anders and Eli.
llvm-svn: 72481
specialization" within a C++ template, and permit name lookup into the
current instantiation. For example, given:
template<typename T, typename U>
struct X {
typedef T type;
X* x1; // current instantiation
X<T, U> *x2; // current instantiation
X<U, T> *x3; // not current instantiation
::X<type, U> *x4; // current instantiation
X<typename X<type, U>::type, U>: *x5; // current instantiation
};
llvm-svn: 71471
As part of this, make ObjCImplDecl inherit from NamedDecl (since
ObjCImplementationDecls now need to have names so that they can be
found). This brings ObjCImplDecl very, very close to
ObjCContainerDecl; we may be able to merge them soon.
llvm-svn: 69941
their own namespace (IDNS_Protocol) and use the normal name-lookup
routines to find them. Aside from the simplification this provides
(one less DenseMap!), it means that protocols will be lazily
deserialized from PCH files.
Make the code size of the selector table block match the code size of
the type and decl blocks.
llvm-svn: 69939
identifiers from a precompiled header.
This patch changes the primary name lookup method for entities within
a precompiled header. Previously, we would load all of the names of
declarations at translation unit scope into a large DenseMap (inside
the TranslationUnitDecl's DeclContext), and then perform a special
"last resort" lookup into this DeclContext when we knew there was a
PCH file (see Sema::LookupName). Now, when we see an identifier named
for the first time, we load all of the declarations with that name
that are visible from the translation unit into the IdentifierInfo's
chain of declarations. Thus, the explicit "look into the translation
unit's DeclContext" code is gone, and Sema effectively uses the same
IdentifierInfo-based name lookup mechanism whether we are using a PCH
file or not.
This approach should help PCH scale with the size of the input program
rather than the size of the PCH file. The "Hello, World!" application
with Carbon.h as a PCH file now loads 20% of the identifiers in the
PCH file rather than 85% of the identifiers.
90% of the 20% of identifiers loaded are actually loaded when we
deserialize the preprocessor state. The next step is to make the
preprocessor load macros lazily, which should drastically reduce the
number of types, declarations, and identifiers loaded for "Hello,
World".
llvm-svn: 69737
de-serialization of abstract syntax trees.
PCH support serializes the contents of the abstract syntax tree (AST)
to a bitstream. When the PCH file is read, declarations are serialized
as-needed. For example, a declaration of a variable "x" will be
deserialized only when its VarDecl can be found by a client, e.g.,
based on name lookup for "x" or traversing the entire contents of the
owner of "x".
This commit provides the framework for serialization and (lazy)
deserialization, along with support for variable and typedef
declarations (along with several kinds of types). More
declarations/types, along with important auxiliary structures (source
manager, preprocessor, etc.), will follow.
llvm-svn: 68732
failures that involve malformed types, e.g., "typename X::foo" where
"foo" isn't a type, or "std::vector<void>" that doens't instantiate
properly.
Similarly, be a bit smarter in our handling of ambiguities that occur
in Sema::getTypeName, to eliminate duplicate error messages about
ambiguous name lookup.
This eliminates two XFAILs in test/SemaCXX, one of which was crying
out to us, trying to tell us that we were producing repeated error
messages.
llvm-svn: 68251
pointer. Its purpose in life is to be a glorified void*, but which does not
implicitly convert to void* or other OpaquePtr's with a different UID.
Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>. Change the
entire parser/sema interface to use DeclPtrTy instead of DeclTy*. This
makes the C++ compiler enforce that these aren't convertible to other opaque
types.
We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
but I don't plan to do that in the short term.
The one outstanding known problem with this patch is that we lose the
bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
bitmangle the success bit into the low bit of DeclPtrTy. I will rectify
this with a subsequent patch.
llvm-svn: 67952
qualified name, e.g.,
foo::x
so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.
The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
::foo::bar::x
The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled).
The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).
Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.
llvm-svn: 67265
Type pointer. This allows our nested-name-specifiers to retain more
information about the actual spelling (e.g., which typedef did the
user name, or what exact template arguments were used in the
template-id?). It will also allow us to have dependent
nested-name-specifiers that don't map to any DeclContext.
llvm-svn: 67140
- C++ function casts, e.g., T(foo)
- sizeof(), alignof()
More importantly, this allows us to verify that we're performing
overload resolution during template instantiation, with
argument-dependent lookup and the "cached" results of name lookup from
the template definition.
llvm-svn: 66947
C++ templates. In particular, keep track of the overloaded operators
that are visible from the template definition, so that they can be
merged with those operators visible via argument-dependent lookup at
instantiation time.
Refactored the lookup routines for argument-dependent lookup and for
operator name lookup, so they can be called without immediately adding
the results to an overload set.
Instantiation of these expressions is completely wrong. I'll work on
that next.
llvm-svn: 66851
template. More importantly, start to sort out the issues regarding
complete types and nested-name-specifiers, especially the question of:
when do we instantiate a class template specialization that occurs to
the left of a '::' in a nested-name-specifier?
llvm-svn: 66662
giving them rough classifications (normal types, never-canonical
types, always-dependent types, abstract type representations) and
making it far easier to make sure that we've hit all of the cases when
decoding types.
Switched some switch() statements on the type class over to using this
mechanism, and filtering out those things we don't care about. For
example, CodeGen should never see always-dependent or non-canonical
types, while debug info generation should never see always-dependent
types. More switch() statements on the type class need to be moved
over to using this approach, so that we'll get warnings when we add a
new type then fail to account for it somewhere in the compiler.
As part of this, some types have been renamed:
TypeOfExpr -> TypeOfExprType
FunctionTypeProto -> FunctionProtoType
FunctionTypeNoProto -> FunctionNoProtoType
There shouldn't be any functionality change...
llvm-svn: 65591
etc.) when we perform name lookup on them. This ensures that we
produce the correct signature for these functions, which has two
practical impacts:
1) When we're supporting the "implicit function declaration" feature
of C99, these functions will be implicitly declared with the right
signature rather than as a function returning "int" with no
prototype. See PR3541 for the reason why this is important (hint:
GCC always predeclares these functions).
2) If users attempt to redeclare one of these library functions with
an incompatible signature, we produce a hard error.
This patch does a little bit of work to give reasonable error
messages. For example, when we hit case #1 we complain that we're
implicitly declaring this function with a specific signature, and then
we give a note that asks the user to include the appropriate header
(e.g., "please include <stdlib.h> or explicitly declare 'malloc'"). In
case #2, we show the type of the implicit builtin that was incorrectly
declared, so the user can see the problem. We could do better here:
for example, when displaying this latter error message we say
something like:
'strcpy' was implicitly declared here with type 'char *(char *, char
const *)'
but we should really print out a fake code line showing the
declaration, like this:
'strcpy' was implicitly declared here as:
char *strcpy(char *, char const *)
This would also be good for printing built-in candidates with C++
operator overloading.
The set of C library functions supported by this patch includes all
functions from the C99 specification's <stdlib.h> and <string.h> that
(a) are predefined by GCC and (b) have signatures that could cause
codegen issues if they are treated as functions with no prototype
returning and int. Future work could extend this set of functions to
other C library functions that we know about.
llvm-svn: 64504
This commit adds a new attribute, "overloadable", that enables C++
function overloading in C. The attribute can only be added to function
declarations, e.g.,
int *f(int) __attribute__((overloadable));
If the "overloadable" attribute exists on a function with a given
name, *all* functions with that name (and in that scope) must have the
"overloadable" attribute. Sets of overloaded functions with the
"overloadable" attribute then follow the normal C++ rules for
overloaded functions, e.g., overloads must have different
parameter-type-lists from each other.
When calling an overloaded function in C, we follow the same
overloading rules as C++, with three extensions to the set of standard
conversions:
- A value of a given struct or union type T can be converted to the
type T. This is just the identity conversion. (In C++, this would
go through a copy constructor).
- A value of pointer type T* can be converted to a value of type U*
if T and U are compatible types. This conversion has Conversion
rank (it's considered a pointer conversion in C).
- A value of type T can be converted to a value of type U if T and U
are compatible (and are not both pointer types). This conversion
has Conversion rank (it's considered to be a new kind of
conversion unique to C, a "compatible" conversion).
Known defects (and, therefore, next steps):
1) The standard-conversion handling does not understand conversions
involving _Complex or vector extensions, so it is likely to get
these wrong. We need to add these conversions.
2) All overloadable functions with the same name will have the same
linkage name, which means we'll get a collision in the linker (if
not sooner). We'll need to mangle the names of these functions.
llvm-svn: 64336
Also, put Objective-C protocols into their own identifier
namespace. Otherwise, we find protocols when we don't want to in C++
(but not in C).
llvm-svn: 63877
- Changes Lookup*Name functions to return NamedDecls, instead of
Decls. Unfortunately my recent statement that it will simplify lot of
code, was not quite right, but it simplifies some...
- Makes MergeLookupResult SmallPtrSet instead of vector, following
Douglas suggestions.
- Adds %qN format for printing qualified names to Diagnostic.
- Avoids searching for using-directives in Scopes, which are not
DeclScope, during unqualified name lookup.
llvm-svn: 63739
a.k.a. Koenig lookup) in C++. Most of the pieces are in place, but for
two:
- In an unqualified call g(x), even if the name does not refer to
anything in the current scope, we can still find functions named
"g" based on ADL. We don't yet have this ability.
- ADL will need updating for friend functions and templates.
llvm-svn: 63692
LookupName et al. Instead, use an enum and a bool to describe its
contents.
Optimized the C/Objective-C path through LookupName, eliminating any
unnecessarily C++isms. Simplify IdentifierResolver::iterator, removing
some code and arguments that are no longer used.
Eliminated LookupDeclInScope/LookupDeclInContext, moving all callers
over to LookupName, LookupQualifiedName, or LookupParsedName, as
appropriate.
All together, I'm seeing a 0.2% speedup on Cocoa.h with PTH and
-disable-free. Plus, we're down to three name-lookup routines.
llvm-svn: 63354
that every declaration lives inside a DeclContext.
Moved several things that don't have names but were ScopedDecls (and,
therefore, NamedDecls) to inherit from Decl rather than NamedDecl,
including ObjCImplementationDecl and LinkageSpecDecl. Now, we don't
store empty DeclarationNames for these things, nor do we try to insert
them into DeclContext's lookup structure.
The serialization tests are temporarily disabled. We'll re-enable them
once we've sorted out the remaining ownership/serialiazation issues
between DeclContexts and TranslationUnion, DeclGroups, etc.
llvm-svn: 62562
even when we are still defining the TagDecl. This is required so that
qualified name lookup of a class name within its definition works (see
the new bits in test/SemaCXX/qualified-id-lookup.cpp).
As part of this, move the nested redefinition checking code into
ActOnTag. This gives us diagnostics earlier (when we try to perform
the nested redefinition, rather than when we try to complete the 2nd
definition) and removes some code duplication.
llvm-svn: 62386
This change refactors and cleans up our handling of name lookup with
LookupDecl. There are several aspects to this refactoring:
- The criteria for name lookup is now encapsulated into the class
LookupCriteria, which replaces the hideous set of boolean values
that LookupDecl currently has.
- The results of name lookup are returned in a new class
LookupResult, which can lazily build OverloadedFunctionDecls for
overloaded function sets (and, eventually, eliminate the need to
allocate member for OverloadedFunctionDecls) and contains a
placeholder for handling ambiguous name lookup (for C++).
- The primary entry points for name lookup are now LookupName (for
unqualified name lookup) and LookupQualifiedName (for qualified
name lookup). There is also a convenience function
LookupParsedName that handles qualified/unqualified name lookup
when given a scope specifier. Together, these routines are meant
to gradually replace the kludgy LookupDecl, but this won't happen
until after we have base class lookup (which forces us to cope
with ambiguities).
- Documented the heck out of name lookup. Experimenting a little
with using Doxygen's member groups to make some sense of the Sema
class. Feedback welcome!
- Fixes some lingering issues with name lookup for
nested-name-specifiers, which now goes through
LookupName/LookupQualifiedName.
llvm-svn: 62245
Serge Pavlov