- Disallow casting 'super'. GCC allows this, however it doesn't make sense (super isn't an expression and the cast won't alter lookup/dispatch).
- Tighten up lookup when messaging 'self'.
llvm-svn: 66033
multiple sequential case statements instead of doing it with recursion. This
fixes a problem where we run out of stack space parsing 100K directly nested
cases.
There are a couple other problems that prevent this from being useful in
practice (right now the example only parses correctly with -disable-free and
doesn't work with -emit-llvm), but this is a start.
I'm not including a testcase because it is large and uninteresting for
regtesting.
Sebastian, I would appreciate it if you could scrutinize the smart pointer
gymnastics I do.
llvm-svn: 66011
Also necessary to fix:
<rdar://problem/6632061> [sema] non object types should not be allowed in @catch statements
<rdar://problem/6252237> [sema] qualified id should be disallowed in @catch statements
llvm-svn: 65964
response to attempts to diagnose an "incomplete" type. This will force
us to use DiagnoseIncompleteType more regularly (rather than looking at
isIncompleteType), but that's also a good thing.
Implicit instantiation is still very simplistic, and will create a new
definition for the class template specialization (as it should) but it
only actually instantiates the base classes and attaches
those. Actually instantiating class members will follow.
Also, instantiate the types of non-type template parameters before
checking them, allowing, e.g.,
template<typename T, T Value> struct Constant;
to work properly.
llvm-svn: 65924
need them to evaluate redeclarations or call a function that hasn't
already been declared. We now keep a DenseMap of these locally-scoped
declarations so that they are not visible but can be quickly found,
e.g., when we're looking for previous declarations or before we go
ahead and implicitly declare a function that's being called. Fixes
PR3672.
llvm-svn: 65792
And now, when clang check a class implementation to find unimplemented methods, it also checks all methods from the class extensions (unnamed categories).
There is also a test case to check this warning.
This patch contains also a minor update for ObjCImplDecl . getNameAsCString and getNameAsString now returns an empty string instead of crashing for unnamed categories."
Patch by Jean-Daniel Dupas!
llvm-svn: 65744
- Move the 'LabelMap' from Sema to Scope. To avoid layering problems, the second element is now a 'StmtTy *', which makes the LabelMap a bit more verbose to deal with.
- Add 'ActiveScope' to Sema. Managed by ActOnStartOfFunctionDef(), ObjCActOnStartOfMethodDef(), ActOnBlockStmtExpr().
- Changed ActOnLabelStmt(), ActOnGotoStmt(), ActOnAddrLabel(), and ActOnFinishFunctionBody() to use the new ActiveScope.
- Added FIXME to workaround in ActOnFinishFunctionBody() (for dealing with C++ nested functions).
llvm-svn: 65694
As far as I know, this catches all cases of jumping into the scope of a
variable with a variably modified type (excluding statement
expressions) in C. This is missing some stuff we probably want to check
(other kinds of variably modified declarations, statement expressions,
indirect gotos/addresses of labels in a scope, ObjC @try/@finally, cleanup
attribute), the diagnostics aren't very good, and it's not particularly
efficient, but it's a decent start.
This patch is a slightly modified version of the patch I attached to
PR3259, and it fixes that bug. I was sort of planning on improving
it, but I think it's okay as-is, especially since it looks like CodeGen
doesn't have any use for this sort of data structure. The only
significant change I can think of from the version I attached to PR3259
is that this version skips running the checking code when a function
doesn't contain any labels.
This patch doesn't cover case statements, which also need similar
checking; I'm not sure how we should deal with that. Extending the goto
checking to also check case statements wouldn't be too hard; it's just a
matter of keeping track of the scope of the closest switch and checking that
the scope of every case is the same as the scope of the switch. That said,
it would likely be a performance hit to run this check on every
function (it's an extra pass over the entire function), so we probably want
some other solution.
llvm-svn: 65678
array types. Semantic checking for the construction of these types has
been factored out of GetTypeForDeclarator and into separate
subroutines (BuildPointerType, BuildReferenceType,
BuildArrayType). We'll be doing the same thing for all other types
(and declarations and expressions).
As part of this, moved the type-instantiation functions into a class
in an anonymous namespace.
llvm-svn: 65663
stubs for those types we don't yet know how to instantiate (everything
that isn't a template parameter!).
We now instantiate default arguments for template type parameters when
needed. This will be our testbed while I fill out the remaining
type-instantiation logic.
llvm-svn: 65649
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
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
llvm-svn: 65570
Needed to make isPropertyReadonly() non-const (for this fix to compile). I imagine there's a way to retain the const-ness, however I have more important fish to fry.
llvm-svn: 65562
The code for looking up local/private method in Sema::ActOnInstanceMessage() was not handling categories properly. Sema::ActOnClassMessage() didn't have this bug.
Created a helper with the correct logic and changed both methods to use it.
llvm-svn: 65532
anymore. If we want to reuse bits and pieces to add strict checking for
constant initializers, we can dig them out of SVN history; the existing
code won't be useful as-is.
llvm-svn: 65502
specializations. In particular:
- Make sure class template specializations have a "template<>"
header, and complain if they don't.
- Make sure class template specializations are declared/defined
within a valid context. (e.g., you can't declare a specialization
std::vector<MyType> in the global namespace).
llvm-svn: 65476
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
llvm-svn: 65467
external declarations to also support external variable
declarations. Unified the code for these two cases into two new
subroutines.
Note that we fail to diagnose cases like the one Neil pointed
out, where a visible non-external declaration hides an external
declaration by the same name. That will require some reshuffling of
name lookup.
llvm-svn: 65385
- When we are declaring a function in local scope, we can merge with
a visible declaration from an outer scope if that declaration
refers to an entity with linkage. This behavior now works in C++
and properly ignores entities without linkage.
- Diagnose the use of "static" on a function declaration in local
scope.
- Diagnose the declaration of a static function after a non-static
declaration of the same function.
- Propagate the storage specifier to a function declaration from a
prior declaration (PR3425)
- Don't name-mangle "main"
llvm-svn: 65360
(as GCC does), except when we've performed overload resolution and
found an unavailable function: in this case, we actually error.
Merge the checking of unavailable functions with the checking for
deprecated functions. This unifies a bit of code, and makes sure that
we're checking for unavailable functions in the right places. Also,
this check can cause an error. We may, eventually, want an option to
make "unavailable" warnings into errors.
Implement much of the logic needed for C++0x deleted functions, which
are effectively the same as "unavailable" functions (but always cause
an error when referenced). However, we don't have the syntax to
specify deleted functions yet :)
llvm-svn: 64955
First step, handle diagnostics in StringLiteral's that are due to token pasting.
For example, we now handle:
id str2 = @"foo"
"bar"
@"baz"
" b\0larg"; // expected-warning {{literal contains NUL character}}
Correctly:
test/SemaObjC/exprs.m:17:15: warning: CFString literal contains NUL character
" b\0larg"; // expected-warning {{literal contains NUL character}}
~~~^~~~~~~
There are several other related issues still to be done.
llvm-svn: 64924
specialization of class templates, e.g.,
template<typename T> class X;
template<> class X<int> { /* blah */ };
Each specialization is a different *Decl node (naturally), and can
have different members. We keep track of forward declarations and
definitions as for other class/struct/union types.
This is only the basic framework: we still have to deal with checking
the template headers properly, improving recovery when there are
failures, handling nested name specifiers, etc.
llvm-svn: 64848
t.c:4:9: error: invalid type 'short *' to __real operator
__tg_choose (__real__(z), C##f(z), (C)(z), C##l(z)),
^
instead of:
t.c:4:9: error: invalid type 'short *' to __real or __imag operator
__tg_choose (__real__(z), C##f(z), (C)(z), C##l(z)),
^
fixing a fixme. It would be even fancier to get the spelling of the token, but I
don't care *that* much :)
llvm-svn: 64759
CXXRecordDecl that is used to represent class template
specializations. These are canonical declarations that can refer to
either an actual class template specialization in the code, e.g.,
template<> class vector<bool> { };
or to a template instantiation. However, neither of these features is
actually implemented yet, so really we're just using (and uniqing) the
declarations to make sure that, e.g., A<int> is a different type from
A<float>. Note that we carefully distinguish between what the user
wrote in the source code (e.g., "A<FLOAT>") and the semantic entity it
represents (e.g., "A<float, int>"); the former is in the sugared Type,
the latter is an actual Decl.
llvm-svn: 64716
- If a declaration is an invalid redeclaration of an existing name,
complain about the invalid redeclaration then avoid adding it to
the AST (we can still parse the definition or initializer, if any).
- If the declaration is invalid but there is no prior declaration
with that name, introduce the invalid declaration into the AST
(for later error recovery).
- If the declaration is an invalid redeclaration of a builtin that
starts with __builtin_, we produce an error and drop the
redeclaration. If it is an invalid redeclaration of a library
builtin (e.g., malloc, printf), warn (don't error!) and drop the
redeclaration.
If a user attempts to define a builtin, produce an error and (if it's
a library builtin like malloc) suggest -ffreestanding.
This addresses <rdar://problem/6097585> and PR2892. However, PR3588 is
still going to cause some problems when builtins are redeclared
without a prototype.
llvm-svn: 64639
DiagnoseUseOfDeprecatedDecl method. This ensures that they
are treated consistently. This gets us 'unavailable' support
on a few new types of decls, and makes sure we consistently
silence deprecated when the caller is also deprecated.
llvm-svn: 64612
about, whether they are builtins or not. Use this to add the
appropriate "format" attribute to NSLog, NSLogv, asprintf, and
vasprintf, and to translate builtin attributes (from Builtins.def)
into actual attributes on the function declaration.
Use the "printf" format attribute on function declarations to
determine whether we should do format string checking, rather than
looking at an ad hoc list of builtins and "known" function names.
Be a bit more careful about when we consider a function a "builtin" in
C++.
llvm-svn: 64561
we can define builtins such as fprintf, vfprintf, and
__builtin___fprintf_chk. Give a nice error message when we need to
implicitly declare a function like fprintf.
llvm-svn: 64526
printf-like functions, both builtin functions and those in the
C library. The function-call checker now queries this attribute do
determine if we have a printf-like function, rather than scanning
through the list of "known functions IDs". However, there are 5
functions they are not yet "builtins", so the function-call checker
handles them specifically still:
- fprintf and vfprintf: the builtins mechanism cannot (yet)
express FILE* arguments, so these can't be encoded.
- NSLog: the builtins mechanism cannot (yet) express NSString*
arguments, so this (and NSLogv) can't be encoded.
- asprintf and vasprintf: these aren't part of the C99 standard
library, so we really shouldn't be defining them as builtins in
the general case (and we don't seem to have the machinery to make
them builtins only on certain targets and depending on whether
extensions are enabled).
llvm-svn: 64512
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
system. Since C99 doesn't have overloading and C++ doesn't have
_Complex, there is no specification for this. Here's what I think
makes sense.
Complex conversions come in several flavors:
- Complex promotions: a complex -> complex conversion where the
underlying real-type conversion is a floating-point promotion. GCC
seems to call this a promotion, EDG does something else. This is
given "promotion" rank for determining the best viable function.
- Complex conversions: a complex -> complex conversion that is
not a complex promotion. This is given "conversion" rank for
determining the best viable function.
- Complex-real conversions: a real -> complex or complex -> real
conversion. This is given "conversion" rank for determining the
best viable function.
These rules are the same for C99 (when using the "overloadable"
attribute) and C++. However, there is one difference in the handling
of floating-point promotions: in C99, float -> long double and double
-> long double are considered promotions (so we give them "promotion"
rank), while C++ considers these conversions ("conversion" rank).
llvm-svn: 64343
for non-external names whose address becomes the template
argument. This completes C++ [temp.arg.nontype]p1.
Note that our interpretation of C++ [temp.arg.nontype]p1b3 differs
from EDG's interpretation (we're stricter, and GCC agrees with
us). They're opening a core issue about the matter.
llvm-svn: 64317
arguments. This commit covers checking and merging default template
arguments from previous declarations, but it does not cover the actual
use of default template arguments when naming class template
specializations.
llvm-svn: 64229
representation for template arguments. Also simplifies the interface
for ActOnClassTemplateSpecialization and eliminates some annoying
allocations of TemplateArgs.
My attempt at smart pointers for template arguments lists is
relatively lame. We can improve it once we're sure that we have the
right representation for template arguments.
llvm-svn: 64154
to a class template. For example, the template-id 'vector<int>' now
has a nice, sugary type in the type system. What we can do now:
- Parse template-ids like 'vector<int>' (where 'vector' names a
class template) and form proper types for them in the type system.
- Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly,
using (sadly) a bool in the parser to tell it whether '>' should
be treated as an operator or not.
This is a baby-step, with major problems and limitations:
- There are currently two ways that we handle template arguments
(whether they are types or expressions). These will be merged, and,
most likely, TemplateArg will disappear.
- We don't have any notion of the declaration of class template
specializations or of template instantiations, so all template-ids
are fancy names for 'int' :)
llvm-svn: 64153
than a Decl, which gives us some more flexibility to express the
results with the type system. There are no clients using this
flexibility yet, but it's meant to be able to describe qualified names
as written in the source (e.g., "foo::type") or template-ids that name
a class template specialization (e.g., "std::vector<INT>").
DeclSpec's TST_typedef has become TST_typename, to reflect its use to
describe types found by name (that may or may not be typedefs). The
type representation of a DeclSpec with TST_typename is an opaque
QualType pointer. All users of TST_typedef, both direct and indirect,
have been updated for these changes.
llvm-svn: 64141
- Made allocation of Stmt objects using vanilla new/delete a *compiler
error* by making this new/delete "protected" within class Stmt.
- Now the only way to allocate Stmt objects is by using the new
operator that takes ASTContext& as an argument. This ensures that
all Stmt nodes are allocated from the same (pool) allocator.
- Naturally, these two changes required that *all* creation sites for
AST nodes use new (ASTContext&). This is a large patch, but the
majority of the changes are just this mechanical adjustment.
- The above changes also mean that AST nodes can no longer be
deallocated using 'delete'. Instead, one most do
StmtObject->Destroy(ASTContext&) or do
ASTContextObject.Deallocate(StmtObject) (the latter not running the
'Destroy' method).
Along the way I also...
- Made CompoundStmt allocate its array of Stmt* using the allocator in
ASTContext (previously it used std::vector). There are a whole
bunch of other Stmt classes that need to be similarly changed to
ensure that all memory allocated for ASTs comes from the allocator
in ASTContext.
- Added a new smart pointer ExprOwningPtr to Sema.h. This replaces
the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used
'delete' to free memory instead of a Stmt's 'Destroy' method.
Big thanks to Doug Gregor for helping with the acrobatics of making
'new/delete' private and the new smart pointer ExprOwningPtr!
llvm-svn: 63997
redeclarations. For example, checks that a class template
redeclaration has the same template parameters as previous
declarations.
Detangled class-template checking from ActOnTag, whose logic was
getting rather convoluted because it tried to handle C, C++, and C++
template semantics in one shot.
Made some inroads toward eliminating extraneous "declaration does not
declare anything" errors by adding an "error" type specifier.
llvm-svn: 63973
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
unqualified-id '('
in C++. The unqualified-id might not refer to any declaration in our
current scope, but declarations by that name might be found via
argument-dependent lookup. We now do so properly.
As part of this change, CXXDependentNameExpr, which was previously
designed to express the unqualified-id in the above constructor within
templates, has become UnresolvedFunctionNameExpr, which does
effectively the same thing but will work for both templates and
non-templates.
Additionally, we cope with all unqualified-ids, since ADL also applies
in cases like
operator+(x, y)
llvm-svn: 63733
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
sequence. Previously, we weren't permitting the second step to call
copy constructors, which left user-defined conversion sequences
surprisingly broken.
Now, we perform overload resolution among all of the constructors, but
only accept the result if it makes the conversion a standard
conversion. Note that this behavior is different from both GCC and EDG
(which don't agree with each other, either); I've submitted a core
issue on the matter.
llvm-svn: 63450
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
This results in a 1.7% improvement for "Cocoa.h". If we can figure out how to return a "Decl *", rather than a Sema::LookupResult(), we will likely bump the speedup from 1.7%->2.5%. I verified this, however couldn't get it to work without breaking a fair number of C++ test cases. Will discuss with Doug offline.
llvm-svn: 63320
The previous interface was very confusing. This is much more explicit, which will be easier to understand/optimize/convert.
The plan is to eventually deprecate both of these functions. For now, I'm focused on performance.
llvm-svn: 63256
initializers.
- We now initialize unions properly when a member other than the
first is named by a designated initializer.
- We now provide proper semantic analysis and code generation for
GNU array-range designators *except* that side effects will occur
more than once. We warn about this.
llvm-svn: 63253
The approach I've taken in this patch is relatively straightforward,
although the code itself is non-trivial. Essentially, as we process
an initializer list we build up a fully-explicit representation of the
initializer list, where each of the subobject initializations occurs
in order. Designators serve to "fill in" subobject initializations in
a non-linear way. The fully-explicit representation makes initializer
lists (both with and without designators) easy to grok for codegen and
later semantic analyses. We keep the syntactic form of the initializer
list linked into the AST for those clients interested in exactly what
the user wrote.
Known limitations:
- Designating a member of a union that isn't the first member may
result in bogus initialization (we warn about this)
- GNU array-range designators are not supported (we warn about this)
llvm-svn: 63242
Even though Sema::LookupDecl() is deprecated, it's still used all over the place. Simplifying the interface will make it easier to understand/optimize/convert.
llvm-svn: 63210
Even though Sema::LookupDecl() is deprecated, it's still used all over the place. Simplifying the interface will make it easier to understand/optimize/convert.
llvm-svn: 63208
.def file for each library. This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.
Patch by Anders Johnsen!
llvm-svn: 63111
- When it's safe, ActionResult uses the low bit of the pointer for
the "invalid" flag rather than a separate "bool" value. This keeps
GCC from generating some truly awful code, for a > 3x speedup in the
result-passing microbenchmark.
- When DISABLE_SMART_POINTERS is defined, store an ActionResult
within ASTOwningResult rather than an ASTOwningPtr. Brings the
performance benefits of the above to smart pointers with
DISABLE_SMART_POINTERS defined.
Sadly, these micro-benchmark performance improvements don't seem to
make much of a difference on Cocoa.h right now. However, they're
harmless and might help with future optimizations.
llvm-svn: 63061
special action, inside function prototype scope. This avoids confusion
when we try to inject these parameters into the scope of the function
body before the function itself has been added to the surrounding
scope. Fixes <rdar://problem/6097326>.
llvm-svn: 62849
initializers, so that we are within the appropriate subobject after
we've processed a multi-designator designation. We're matching GCC and
EDG's behavior on all examples I've found thus far.
*Huge* thanks to Eli Friedman for pointing out my fundamental
misunderstanding of "current object" in the C99 spec.
llvm-svn: 62812
designated initializers. This implementation should cover all of the
constraints in C99 6.7.8, including long, complex designations and
computing the size of incomplete array types initialized with a
designated initializer. Please see the new test-case and holler if you
find cases where this doesn't work.
There are still some wrinkles with GNU's anonymous structs and
anonymous unions (it isn't clear how these should work; we'll just
follow GCC's lead) and with designated initializers for the members of a
union. I'll tackle those very soon.
CodeGen is still nonexistent, and there's some leftover code in the
parser's representation of designators that I'll also need to clean up.
llvm-svn: 62737
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
new DiagnoseIncompleteType. It provides additional information about
struct/class/union/enum types when possible, either by pointing to the
forward declaration of that type or by pointing to the definition (if
we're in the process of defining that type).
Fixes <rdar://problem/6500531>.
llvm-svn: 62521
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
Small cleanup in the handling of user-defined conversions.
Also, implement an optimization when constructing a call. We avoid
recomputing implicit conversion sequences and instead use those
conversion sequences that we computed as part of overload resolution.
llvm-svn: 62231
Extend string-literal checking for printf() format string to handle conditional
ternary operators where both sides are literals.
This fixes PR 3319: http://llvm.org/bugs/show_bug.cgi?id=3319
llvm-svn: 62117
or enum to be outside that struct, union, or enum. Fixes several
regressions:
<rdar://problem/6487662>
<rdar://problem/6487669>
<rdar://problem/6487684>
<rdar://problem/6487702>
PR clang/3305
PR clang/3312
There is still some work to do in Objective-C++, but this requires
that each of the Objective-C entities (interfaces, implementations,
etc.) to be introduced into the context stack with
PushDeclContext/PopDeclContext. This will be a separate fix, later.
llvm-svn: 62091
introduce a Scope for the body of a tag. This reduces the number of
semantic differences between C and C++ structs and unions, and will
help with other features (e.g., anonymous unions) in C. Some important
points:
- Fields are now in the "member" namespace (IDNS_Member), to keep
them separate from tags and ordinary names in C. See the new test
in Sema/member-reference.c for an example of why this matters. In
C++, ordinary and member name lookup will find members in both the
ordinary and member namespace, so the difference between
IDNS_Member and IDNS_Ordinary is erased by Sema::LookupDecl (but
only in C++!).
- We always introduce a Scope and push a DeclContext when we're
defining a tag, in both C and C++. Previously, we had different
actions and different Scope/CurContext behavior for enums, C
structs/unions, and C++ structs/unions/classes. Now, it's one pair
of actions. (Yay!)
There's still some fuzziness in the handling of struct/union/enum
definitions within other struct/union/enum definitions in C. We'll
need to do some more cleanup to eliminate some reliance on CurContext
before we can solve this issue for real. What we want is for something
like this:
struct X {
struct T { int x; } t;
};
to introduce T into translation unit scope (placing it at the
appropriate point in the IdentifierResolver chain, too), but it should
still have struct X as its lexical declaration
context. PushOnScopeChains isn't smart enough to do that yet, though,
so there's a FIXME test in nested-redef.c
llvm-svn: 61940
- ObjCContainerDecl's (ObjCInterfaceDecl/ObjCCategoryDecl/ObjCProtocolDecl), ObjCCategoryImpl, & ObjCImplementation are all DeclContexts.
- ObjCMethodDecl is now a ScopedDecl (so it can play nicely with DeclContext).
- ObjCContainerDecl now does iteration/lookup using DeclContext infrastructure (no more linear search:-)
- Removed ASTContext argument to DeclContext::lookup(). It wasn't being used and complicated it's use from an ObjC AST perspective.
- Added Sema::ProcessPropertyDecl() and removed Sema::diagnosePropertySetterGetterMismatch().
- Simplified Sema::ActOnAtEnd() considerably. Still more work to do.
- Fixed an incorrect casting assumption in Sema::getCurFunctionOrMethodDecl(), now that ObjCMethodDecl is a ScopedDecl.
- Removed addPropertyMethods from ObjCInterfaceDecl/ObjCCategoryDecl/ObjCProtocolDecl.
This passes all the tests on my machine. Since many of the changes are central to the way ObjC finds it's methods, I expect some fallout (and there are still a handful of FIXME's). Nevertheless, this should be a step in the right direction.
llvm-svn: 61929
structures and classes) in C++. Covers name lookup and the synthesis
and member access for the unnamed objects/fields associated with
anonymous unions.
Some C++ semantic checks are still missing (anonymous unions can't
have function members, static data members, etc.), and there is no
support for anonymous structs or unions in C.
llvm-svn: 61840
- Simplify ParseDeclCXX to use early exit on error instead of nesting.
- Change ParseDeclCXX to using the 'skip on error' form of ExpectAndConsume.
- If we don't see the ; in a using directive, still call the action, for
hopefully better error recovery.
llvm-svn: 61801
information for declarations that were referenced via a qualified-id,
e.g., N::C::value. We keep track of the location of the start of the
nested-name-specifier. Note that the difference between
QualifiedDeclRefExpr and DeclRefExpr does have an effect on the
semantics of function calls in two ways:
1) The use of a qualified-id instead of an unqualified-id suppresses
argument-dependent lookup
2) If the name refers to a virtual function, the qualified-id
version will call the function determined statically while the
unqualified-id version will call the function determined dynamically
(by looking up the appropriate function in the vtable).
Neither of these features is implemented yet, but we do print out
qualified names for QualifiedDeclRefExprs as part of the AST printing.
llvm-svn: 61789
Make C++ classes track the POD property (C++ [class]p4)
Track the existence of a copy assignment operator.
Implicitly declare the copy assignment operator if none is provided.
Implement most of the parsing job for the G++ type traits extension.
Fully implement the low-hanging fruit of the type traits:
__is_pod: Whether a type is a POD.
__is_class: Whether a type is a (non-union) class.
__is_union: Whether a type is a union.
__is_enum: Whether a type is an enum.
__is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1).
llvm-svn: 61746
DeclContexts whose members are visible from enclosing DeclContexts up
to (and including) the innermost enclosing non-transparent
DeclContexts. Transparent DeclContexts unify the mechanism to be used
for various language features, including C enumerations, anonymous
unions, C++0x inline namespaces, and C++ linkage
specifications. Please refer to the documentation in the Clang
internals manual for more information.
Only enumerations and linkage specifications currently use transparent
DeclContexts.
Still to do: use transparent DeclContexts to implement anonymous
unions and GCC's anonymous structs extension, and, later, the C++0x
features. We also need to tighten up the DeclContext/ScopedDecl link
to ensure that every ScopedDecl is in a single DeclContext, which
will ensure that we can then enforce ownership and reduce the memory
footprint of DeclContext.
llvm-svn: 61735
semantics and improve our handling of default arguments. Specifically,
we follow this order:
- As soon as the see the '}' in the class definition, the class is
complete and we add any implicit declarations (default constructor,
copy constructor, etc.) to the class.
- If there are any default function arguments, parse them
- If there were any inline member function definitions, parse them
As part of this change, we now keep track of the the fact that we've
seen unparsed default function arguments within the AST. See the new
ParmVarDecl::hasUnparsedDefaultArg member. This allows us to properly
cope with calls inside default function arguments to other functions
where we're making use of the default arguments.
Made some C++ error messages regarding failed initializations more
specific.
llvm-svn: 61406
DeclContext. Instead, just keep the list of currently-active
declarations and only build the OverloadedFunctionDecl when we
absolutely need it.
This is a half-step toward eliminating the need to explicitly build
OverloadedFunctionDecls that store sets of overloaded
functions. This was suggested by Argiris a while back, and it's a good
thing for several reasons: first, it eliminates the messy logic that
currently tries to keep the OverloadedFunctionDecl in sync with the
declarations that are being added. Second, it will (eventually)
eliminate the need to allocate memory for overload sets, which could
help performance. Finally, it helps set us up for when name lookup can
return multiple (possibly ambiguous) results, as can happen with
lookup of class members in C++.
Next steps: make the IdentifierResolver store overloads as separate
entries in its list rather than replacing them with an
OverloadedFunctionDecl now, then see how far we can go toward
eliminating OverloadedFunctionDecl entirely.
llvm-svn: 61357
- Overloading has to cope with having both static and non-static
member functions in the overload set.
- The call may or may not have an implicit object argument,
depending on the syntax (x.f() vs. f()) and the context (static
vs. non-static member function).
- We now generate MemberExprs for implicit member access expression.
- We now cope with mutable whenever we're building MemberExprs.
llvm-svn: 61329
become useful or correct until we (1) parse template arguments
correctly, (2) have some way to turn template-ids into types,
declarators, etc., and (3) have a real representation of templates.
llvm-svn: 61208
is completely defined (C++ [class.mem]p2).
Reverse the order in which we process the definitions of member
functions specified inline. This way, we'll get diagnostics in the
order in which the member functions were declared in the class.
llvm-svn: 61103
Fariborz Jahanian