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
- Although gross, this is needed currently to ensure that we produce
well formed debug information (to match pace with the assertions
being added to DebugInfo in LLVM).
llvm-svn: 62734
Because the RegionStore can reason about values beyond the reasoning power of BasicStore, this patch splits some of the test cases for the retain/release checker to have versions that are handled by RegionStore (more warnings) and BasicStore (less warnings).
llvm-svn: 62667
Changes to IdentifierTable:
- High-level summary: StringMap never owns IdentifierInfos. It just
references them.
- The string map now has StringMapEntry<IdentifierInfo*> instead of
StringMapEntry<IdentifierInfo>. The IdentifierInfo object is
allocated using the same bump pointer allocator as used by the
StringMap.
Changes to IdentifierInfo:
- Added an extra pointer to point to the
StringMapEntry<IdentifierInfo*> in the string map. This pointer
will be null if the IdentifierInfo* is *only* used by the PTHLexer
(that is it isn't in the StringMap).
Algorithmic changes:
- Non-PTH case:
IdentifierInfo::get() will always consult the StringMap first to
see if we have an IdentifierInfo object. If that StringMapEntry
references a null pointer, we allocate a new one from the BumpPtrAllocator
and update the reference in the StringMapEntry.
- PTH case:
We do the same lookup as with the non-PTH case, but if we don't get
a hit in the StringMap we do a secondary lookup in the PTHManager for
the IdentifierInfo. If we don't find an IdentifierInfo we create a
new one as in the non-PTH case. If we do find and IdentifierInfo
in the PTHManager, we update the StringMapEntry to refer to it so
that the IdentifierInfo will be found on the next StringMap lookup.
This way we only do a binary search in the PTH file at most once
for a given IdentifierInfo. This greatly speeds things up for source
files containing a non-trivial amount of code.
Performance impact:
While these changes do add some extra indirection in
IdentifierTable to access an IdentifierInfo*, I saw speedups even
in the non-PTH case as well.
Non-PTH: For -fsyntax-only on Cocoa.h, we see a 6% speedup.
PTH (with Cocoa.h in token cache): 11% speedup.
I also did an experiment where we did -fsyntax-only on a source file
including a large header and Cocoa.h, but the token cache did not
contain the larger header. For this file, we were seeing a performance
*regression* when using PTH of 3% over non-PTH. Now we are seeing
a performance improvement of 9%!
Tests:
The serialization tests are now failing. I looked at this extensively,
and I my belief is that this change is unmasking a bug rather than
introducing a new one. I have disabled the serialization tests for now.
llvm-svn: 62636
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
analysis and AST-building for the cases where we have N != 1
arguments. For N == 1 arguments, we need to finish the C++
implementation of explicit type casts (C++ [expr.cast]).
llvm-svn: 62329
the "physical" location of tokens, refer to the "spelling" location.
This is more concrete and useful, tokens aren't really physical objects!
llvm-svn: 62309
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
C++ handle anonymous structs/unions in the same way. Addresses several
bugs:
<rdar://problem/6259534>
<rdar://problem/6481130>
<rdar://problem/6483159>
The test case in PR clang/1750 now passes with -fsyntax-only, but
CodeGen for inline assembler still fails.
llvm-svn: 62112
- Refactor a bunch of logic in the retain/release checker, making it more
condense and easier to read.
- Add support for "Create" methods in the DiskArbitration framework
retain/release tests:
- Rename CFDate.m to retain-release.m, and move test from CFString.c to
retain-release.m
- Add DiskArbitration framework tests cases.
- Add/refine and few more retain/release GC test cases.
llvm-svn: 62106
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
that is neither a definition nor a forward declaration and where X has
not yet been declared as a tag, introduce a declaration
into the appropriate scope (which is likely *not* to be the current
scope). The rules for the placement of the declaration differ slightly
in C and C++, so we implement both and test the various corner
cases. This implementation isn't 100% correct due to some lingering
issues with the function prototype scope (for a function parameter
list) not being the same scope as the scope of the function
definition. Testcase is FIXME'd; this probably isn't an important issue.
Addresses <rdar://problem/6484805>.
llvm-svn: 62014
of ScopedDecls (using the new ScopedDecl::NextDeclInScope
pointer). Performance-wise:
- It's a net win in memory utilization, since DeclContext is now one
pointer smaller than it used to be (std::vectors are typically 3
pointers; we now use 2 pointers) and
- Parsing Cocoa.h with -fsyntax-only (with a Release-Asserts Clang)
is about 1.9% faster than before, most likely because we no longer
have the memory allocations and copying associated with the
std::vector.
I'll re-enable serialization of DeclContexts once I've sorted out the
NextDeclarator/NextDeclInScope question.
llvm-svn: 62001
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
Duplicate-member checking within classes is still a little messy, and
anonymous unions are still completely broken in C. We'll need to unify
the handling of fields in C and C++ to make this code applicable in
both languages.
llvm-svn: 61878
recent discussions with Thomas Clement and Ken Ferry concerning the "fundamental
rule" for Cocoa memory management
(http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html).
Here is the revised behavior of the checker concerning tracking retain/release
counts for objects returned from message expressions involving instance methods:
1) Track the returned object if the return type of the message expression is
id<..>, id, or a pointer to *any* object that subclasses NSObject. Such objects
are assumed to have a retain count. Previously the checker only tracked objects
when the receiver of the message expression was part of the standard Cocoa API
(i.e., had class names prefixed with 'NS'). This should significantly expand the
amount of checking performed.
2) Consider the object owned if the selector of the message expression contains
"alloc", "new", or "copy". Previously we also considered "create", but this
doesn't follow from the fundamental rule (discussions with the Cocoa folks
confirms this).
llvm-svn: 61837
- 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
When emitting the static variables we need to make sure that the order is preserved.
Fix this by making StaticDecls a std::list which has O(1) random removal.
llvm-svn: 61621
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
- 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
which can refer to static data members, enumerators, and member
functions as well as to non-static data members.
Implement correct lvalue computation for member references in C++.
Compute the result type of non-static data members of reference type properly.
llvm-svn: 61294
simple test that actually does VLA codegen.
Note that despite the fact that the alloca isn't in the entry block, it
should dominate all uses; this is guaranteed by the restrictions on goto
into VLA scope in C99.
llvm-svn: 61291
full encoding of the class which has an ivar of pointer to this
class. Its name is encoded in the type for the ivar in the
ivar-list metadata. This patch conforms to the above rule.
llvm-svn: 61282
Douglas Gregor