the type of the enumeration once the enumeration has been defined.
Fix the overloading test-case to properly create enums that promote
the way we want them to.
Implement C++0x promotions from enumeration types to long
long/unsigned long long. We're using these promotions in Carbon.h
(since long long is a common extension).
Fixes PR clang/2954: http://llvm.org/bugs/show_bug.cgi?id=2954
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60917 91177308-0d34-0410-b5e6-96231b3b80d8
and separates lexical name lookup from qualified name lookup. In
particular:
* Make DeclContext the central data structure for storing and
looking up declarations within existing declarations, e.g., members
of structs/unions/classes, enumerators in C++0x enums, members of
C++ namespaces, and (later) members of Objective-C
interfaces/implementations. DeclContext uses a lazily-constructed
data structure optimized for fast lookup (array for small contexts,
hash table for larger contexts).
* Implement C++ qualified name lookup in terms of lookup into
DeclContext.
* Implement C++ unqualified name lookup in terms of
qualified+unqualified name lookup (since unqualified lookup is not
purely lexical in C++!)
* Limit the use of the chains of declarations stored in
IdentifierInfo to those names declared lexically.
* Eliminate CXXFieldDecl, collapsing its behavior into
FieldDecl. (FieldDecl is now a ScopedDecl).
* Make RecordDecl into a DeclContext and eliminates its
Members/NumMembers fields (since one can just iterate through the
DeclContext to get the fields).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60878 91177308-0d34-0410-b5e6-96231b3b80d8
expressions, and value-dependent expressions. This permits us to parse
some template definitions.
This is not a complete solution; we're missing type- and
value-dependent computations for most of the expression types, and
we're missing checks for dependent types and type-dependent
expressions throughout Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60615 91177308-0d34-0410-b5e6-96231b3b80d8
parameters, with some semantic analysis:
- Template parameters are introduced into template parameter scope
- Complain about template parameter shadowing (except in Microsoft mode)
Note that we leak template parameter declarations like crazy, a
problem we'll remedy once we actually create proper declarations for
templates.
Next up: dependent types and value-dependent/type-dependent
expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60597 91177308-0d34-0410-b5e6-96231b3b80d8
instead of converting them to strings first. This also fixes a
bunch of minor inconsistencies in the diagnostics emitted by clang
and adds a bunch of FIXME's to DiagnosticKinds.def.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59948 91177308-0d34-0410-b5e6-96231b3b80d8
uses of getName() with uses of getDeclName(). This upgrades a bunch of
diags to take DeclNames instead of std::strings.
This also tweaks a couple of diagnostics to be cleaner and changes
CheckInitializerTypes/PerformInitializationByConstructor to pass
around DeclarationNames instead of std::strings.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59947 91177308-0d34-0410-b5e6-96231b3b80d8
with implicit quotes around them. This has a bunch of follow-on
effects and requires tweaking to a whole lot of code. This causes
a regression in two tests (xfailed) by causing it to emit things like:
Line 10: duplicate interface declaration for category 'MyClass1' ('Category1')
instead of:
Line 10: duplicate interface declaration for category 'MyClass1(Category1)'
I will fix this in a follow-up commit.
As part of this, I had to start switching stuff to use ->getDeclName() instead
of Decl::getName() for consistency. This is good, but I was planning to do this
as an independent patch. There will be several follow-on patches
to clean up some of the mess, but this patch is already too big.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59917 91177308-0d34-0410-b5e6-96231b3b80d8
without calling getAsString(). This implicitly puts quotes around the
name, so diagnostics need to be tweaked to accommodate this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59916 91177308-0d34-0410-b5e6-96231b3b80d8
looking up the "std" identifier is trivial. Just do it, particularly
since this is only done if the namespace hasn't already been looked up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59710 91177308-0d34-0410-b5e6-96231b3b80d8
struct A {
struct B;
};
struct A::B {
void m() {} // Assertion failed: getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one."
};
Introduce DeclContext::getLexicalParent which may be different from DeclContext::getParent when nested-names are involved, e.g:
namespace A {
struct S;
}
struct A::S {}; // getParent() == namespace 'A'
// getLexicalParent() == translation unit
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59650 91177308-0d34-0410-b5e6-96231b3b80d8
__builtin_prefetch code to only emit one diagnostic per builtin_prefetch.
While this has nothing to do with the rest of the patch, the code seemed
like overkill when I was updating it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59588 91177308-0d34-0410-b5e6-96231b3b80d8
operator+, directly, using the same mechanism as all other special
names.
Removed the "special" identifiers for the overloaded operators from
the identifier table and IdentifierInfo data structure. IdentifierInfo
is back to representing only real identifiers.
Added a new Action, ActOnOperatorFunctionIdExpr, that builds an
expression from an parsed operator-function-id (e.g., "operator
+"). ActOnIdentifierExpr used to do this job, but
operator-function-ids are no longer represented by IdentifierInfo's.
Extended Declarator to store overloaded operator names.
Sema::GetNameForDeclarator now knows how to turn the operator
name into a DeclarationName for the overloaded operator.
Except for (perhaps) consolidating the functionality of
ActOnIdentifier, ActOnOperatorFunctionIdExpr, and
ActOnConversionFunctionExpr into a common routine that builds an
appropriate DeclRefExpr by looking up a DeclarationName, all of the
work on normalizing declaration names should be complete with this
commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59526 91177308-0d34-0410-b5e6-96231b3b80d8
destructors, and conversion functions. The placeholders were used to
work around the fact that the parser and some of Sema really wanted
declarators to have simple identifiers; now, the code that deals with
declarators will use DeclarationNames.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59469 91177308-0d34-0410-b5e6-96231b3b80d8
C++ constructors, destructors, and conversion functions now have a
FETokenInfo field that IdentifierResolver can access, so that these
special names are handled just like ordinary identifiers. A few other
Sema routines now use DeclarationNames instead of IdentifierInfo*'s.
To validate this design, this code also implements parsing and
semantic analysis for id-expressions that name conversion functions,
e.g.,
return operator bool();
The new parser action ActOnConversionFunctionExpr takes the result of
parsing "operator type-id" and turning it into an expression, using
the IdentifierResolver with the DeclarationName of the conversion
function. ActOnDeclarator pushes those conversion function names into
scope so that the IdentifierResolver can find them, of course.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59462 91177308-0d34-0410-b5e6-96231b3b80d8
representing the names of declarations in the C family of
languages. DeclarationName is used in NamedDecl to store the name of
the declaration (naturally), and ObjCMethodDecl is now a NamedDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59441 91177308-0d34-0410-b5e6-96231b3b80d8
function call created in response to the use of operator syntax that
resolves to an overloaded operator in C++, e.g., "str1 +
str2" that resolves to std::operator+(str1, str2)". We now build a
CXXOperatorCallExpr in C++ when we pick an overloaded operator. (But
only for binary operators, where we actually implement overloading)
I decided *not* to refactor the current CallExpr to make it abstract
(with FunctionCallExpr and CXXOperatorCallExpr as derived
classes). Doing so would allow us to make CXXOperatorCallExpr a little
bit smaller, at the cost of making the argument and callee accessors
virtual. We won't know if this is going to be a win until we can parse
lots of C++ code to determine how much memory we'll save by making
this change vs. the performance penalty due to the extra virtual
calls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59306 91177308-0d34-0410-b5e6-96231b3b80d8
conversion functions. Instead, we just use a placeholder identifier
for these (e.g., "<constructor>") and override NamedDecl::getName() to
provide a human-readable name.
This is one potential solution to the problem; another solution would
be to replace the use of IdentifierInfo* in NamedDecl with a different
class that deals with identifiers better. I'm also prototyping that to
see how it compares, but this commit is better than what we had
previously.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59193 91177308-0d34-0410-b5e6-96231b3b80d8
functions for built-in operators, e.g., the builtin
bool operator==(int const*, int const*)
can be used for the expression "x1 == x2" given:
struct X {
operator int const*();
} x1, x2;
The scheme for handling these built-in operators is relatively simple:
for each candidate required by the standard, create a special kind of
candidate function for the built-in. If overload resolution picks the
built-in operator, we perform the appropriate conversions on the
arguments and then let the normal built-in operator take care of it.
There may be some optimization opportunity left: if we can reduce the
number of built-in operator overloads we generate, overload resolution
for these cases will go faster. However, one must be careful when
doing this: GCC generates too few operator overloads in our little
test program, and fails to compile it because none of the overloads it
generates match.
Note that we only support operator overload for non-member binary
operators at the moment. The other operators will follow.
As part of this change, ImplicitCastExpr can now be an lvalue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59148 91177308-0d34-0410-b5e6-96231b3b80d8
-When parsing declarators, don't depend on "CurScope->isCXXClassScope() == true" for constructors/destructors
-For C++ member declarations, don't depend on "Declarator.getContext() == Declarator::MemberContext"
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58866 91177308-0d34-0410-b5e6-96231b3b80d8
functions in C++, e.g.,
struct X {
operator bool() const;
};
Note that these conversions don't actually do anything, since we don't
yet have the ability to use them for implicit or explicit conversions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58860 91177308-0d34-0410-b5e6-96231b3b80d8
operators in C++. Overloaded operators can be called directly via
their operator-function-ids, e.g., "operator+(foo, bar)", but we don't
yet implement the semantics of operator overloading to handle, e.g.,
"foo + bar".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58817 91177308-0d34-0410-b5e6-96231b3b80d8
Implicit declaration of destructors (when necessary).
Extended Declarator to store information about parsed constructors
and destructors; this will be extended to deal with declarators that
name overloaded operators (e.g., "operator +") and user-defined
conversion operators (e.g., "operator int").
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58767 91177308-0d34-0410-b5e6-96231b3b80d8
duplication in the handling of copy-initialization by constructor,
which occurs both for initialization of a declaration and for
overloading. The initialization code is due for some refactoring.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58756 91177308-0d34-0410-b5e6-96231b3b80d8
Notes:
- Constructors are never found by name lookup, so they'll never get
pushed into any scope. Instead, they are stored as an
OverloadedFunctionDecl in CXXRecordDecl for easy overloading.
- There's a new action isCurrentClassName that determines whether an
identifier is the name of the innermost class currently being defined;
we use this to identify the declarator-id grammar rule that refers to
a type-name.
- MinimalAction does *not* support parsing constructors.
- We now handle virtual and explicit function specifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58499 91177308-0d34-0410-b5e6-96231b3b80d8
- Allows definitions of overloaded functions :)
- Eliminates extraneous error messages when we have a definition of a
function that isn't an overload but doesn't have exactly the same type
as the original.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58382 91177308-0d34-0410-b5e6-96231b3b80d8
of copy initialization. Other pieces of the puzzle:
- Try/Perform-ImplicitConversion now handles implicit conversions
that don't involve references.
- Try/Perform-CopyInitialization uses
CheckSingleAssignmentConstraints for C. PerformCopyInitialization
is now used for all argument passing and returning values from a
function.
- Diagnose errors with declaring references and const values without
an initializer. (Uses a new Action callback, ActOnUninitializedDecl).
We do not yet have implicit conversion sequences for reference
binding, which means that we don't have any overloading support for
reference parameters yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58353 91177308-0d34-0410-b5e6-96231b3b80d8
- Do not allow expressions to ever have reference type
- Extend Expr::isLvalue to handle more cases where having written a
reference into the source implies that the expression is an lvalue
(e.g., function calls, C++ casts).
- Make GRExprEngine::VisitCall treat the call arguments as lvalues when
they are being bound to a reference parameter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58306 91177308-0d34-0410-b5e6-96231b3b80d8
- CastExpr is the root of all casts
- ImplicitCastExpr is (still) used for all explicit casts
- ExplicitCastExpr is now the root of all *explicit* casts
- ExplicitCCastExpr (new name needed!?) is a C-style cast in C or C++
- CXXFunctionalCastExpr inherits from ExplicitCastExpr
- CXXNamedCastExpr inherits from ExplicitCastExpr and is the root of all
of the C++ named cast expression types (static_cast, dynamic_cast, etc.)
- Added classes CXXStaticCastExpr, CXXDynamicCastExpr,
CXXReinterpretCastExpr, and CXXConstCastExpr to
Also, fixed returned-stack-addr.cpp, which broke once when we fixed
reinterpret_cast to diagnose double->int* conversions and again when
we eliminated implicit conversions to reference types. The fix is in
both testcase and SemaChecking.cpp.
Most of this patch is simply support for the renaming. There's very
little actual change in semantics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58264 91177308-0d34-0410-b5e6-96231b3b80d8
-Add withConst/withVolatile/withRestrict methods to QualType class, that return the QualType plus the respective qualifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58120 91177308-0d34-0410-b5e6-96231b3b80d8
is to encode the state of the #pragma pack stack as an attribute when
the structure is declared.
- Extend PackedAttr to take an alignment (in bits), and reuse for
both __attribute__((packed)) (which takes no argument, instead
packing tightly (to "minimize the memory required") and for #pragma
pack (which allows specification of the maximum alignment in
bytes). __attribute__((packed)) is just encoded as Alignment=1.
This conflates two related but different mechanisms, but it didn't
seem worth another attribute.
- I have attempted to follow the MSVC semantics as opposed to the gcc
ones, since if I understand correctly #pragma pack originated with
MSVC. The semantics are generally equivalent except when the stack
is altered during the definition of a structure; its not clear if
anyone does this in practice. See testcase if curious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57623 91177308-0d34-0410-b5e6-96231b3b80d8
- Follows the MSVC (original) implementation, including support of
pack(show) (useful for testing).
- Implements support for named pack records which gcc seems to
ignore (or implements incorrectly).
- Not currently wired to anything, only functionality change is the
type checking of the pragma.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57476 91177308-0d34-0410-b5e6-96231b3b80d8
constant lvalue. Implement this in codegen by moving the code out of CGBuiltin
into EmitConstantExpr.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57163 91177308-0d34-0410-b5e6-96231b3b80d8
condition as a constant even if the unevaluated side is a not a constant.
We don't do this when extensions are off, and we emit a warning when this
happens:
t.c:22:11: warning: expression is not a constant, but is accepted as one by GNU extensions
short t = __builtin_constant_p(5353) ? 42 : somefunc();
^ ~~~~~~~~~~
suggestions for improvement are welcome. This is obviously horrible, but
is required for real-world code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57153 91177308-0d34-0410-b5e6-96231b3b80d8
This is a temporary solution to help with the block rewriter (though it certainly has general utility).
Once DeclGroup's are implemented, this SourceLocation should be stored with it (since it applies to all the decls).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56985 91177308-0d34-0410-b5e6-96231b3b80d8
- Enabled for builtins which are always constant expressions
(__builtin_huge_val*, __builtin_inf*, __builtin_constant_p,
__builtin_classify_type, __builtin___CFStringMakeConstantString).
Added Builtin::Context::isConstantExpr.
- Currently overly simply interface which only works for builtins
whose constantexprness does not depend on their arguments.
CallExpr::isBuiltinConstantExpr now takes an ASTContext argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56983 91177308-0d34-0410-b5e6-96231b3b80d8
wasn't covering checking builtins like __builtin___vsnprintf_chk) with
a check that won't get out of date.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56767 91177308-0d34-0410-b5e6-96231b3b80d8
- For investigating warnings in system headers / builtins.
- Currently also enables the behavior that allows silent redefinition
of types in system headers. Conceptually these are separate but I
didn't feel it was worth two options (or changing LangOptions).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56163 91177308-0d34-0410-b5e6-96231b3b80d8
- Replace string comparisons with pre-defined idents.
- Avoid calling isBuiltinObjCType() to avoid two checks.
- Remove isBuiltinObjCType(), since it was only used in Sema::MergeTypeDefDecl().
- Have Sema::MergeTypeDefDecl() set the new type.
This is a moidified version of an patch by David Chisnall.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55990 91177308-0d34-0410-b5e6-96231b3b80d8
This change effects both RecordDecls and CXXRecordDecls, but does not effect EnumDecls (yet).
The motivation of this patch is as follows:
- Capture more source information, necessary for refactoring/rewriting clients.
- Pave the way to resolve ownership issues with RecordDecls with the forthcoming
addition of DeclGroups.
Current caveats:
- Until DeclGroups are in place, we will leak RecordDecls not explicitly
referenced by the AST. For example:
typedef struct { ... } x;
The RecordDecl for the struct will be leaked because the TypedefDecl doesn't
refer to it. This will be solved with DeclGroups.
- This patch also (temporarily) breaks CodeGen. More below.
High-level changes:
- As before, TagType still refers to a TagDecl, but it doesn't own it. When
a struct/union/class is first referenced, a RecordType and RecordDecl are
created for it, and the RecordType refers to that RecordDecl. Later, if
a new RecordDecl is created, the pointer to a RecordDecl in RecordType is
updated to point to the RecordDecl that defines the struct/union/class.
- TagDecl and RecordDecl now how a method 'getDefinition()' to return the
TagDecl*/RecordDecl* that refers to the TagDecl* that defines a particular
enum/struct/class/union. This is useful from going from a RecordDecl* that
defines a forward declaration to the RecordDecl* that provides the actual
definition. Note that this also works for EnumDecls, except that in this case
there is no distinction between forward declarations and definitions (yet).
- Clients should no longer assume that 'isDefinition()' returns true from a
RecordDecl if the corresponding struct/union/class has been defined.
isDefinition() only returns true if a particular RecordDecl is the defining
Decl. Use 'getDefinition()' instead to determine if a struct has been defined.
- The main changes to Sema happen in ActOnTag. To make the changes more
incremental, I split off the processing of enums and structs et al into two
code paths. Enums use the original code path (which is in ActOnTag) and
structs use the ActOnTagStruct. Eventually the two code paths will be merged,
but the idea was to preserve the original logic both for comparison and not to
change the logic for both enums and structs all at once.
- There is NO CHAINING of RecordDecls for the same RecordType. All RecordDecls
that correspond to the same type simply have a pointer to that type. If we
need to figure out what are all the RecordDecls for a given type we can build
a backmap.
- The diff in CXXRecordDecl.[cpp,h] is actually very small; it just mimics the
changes to RecordDecl. For some reason 'svn' marks the entire file as changed.
Why is CodeGen broken:
- Codegen assumes that there is an equivalence between RecordDecl* and
RecordType*. This was true before because we only created one RecordDecl* for
a given RecordType*, but it is no longer true. I believe this shouldn't be too
hard to change, but the patch was big enough as it is.
I have tested this patch on both the clang test suite, and by running the static analyzer over Postgresql and a large Apple-internal project (mix of Objective-C and C).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55839 91177308-0d34-0410-b5e6-96231b3b80d8
The motivation behind this change is that chaining the RecordDecls is simply unnecessary. Once we create multiple RecordDecls for the same struct/union/class, clients that care about all the declarations of the same struct can build a back map by seeing which Decls refer to the same RecordType.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55821 91177308-0d34-0410-b5e6-96231b3b80d8
correctly. Not a regression, but made more obvious by my recent fix
which made function type compatibility checking a bit more strict.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55339 91177308-0d34-0410-b5e6-96231b3b80d8
casting pointers to integers.
Eventually, we should check whether we can evaluate an expression
using Expr::tryEvaluate, and this codepath should be tightened to only
handle standard-compliant cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55331 91177308-0d34-0410-b5e6-96231b3b80d8
testing compatibility. This is necessary for some constructs, like merging
redeclarations.
Also, there are some ObjC changes to make sure that
typesAreCompatible(a,b) == typesAreCompatible(b,a). I don't have any
ObjC code beyond the testsuite, so please tell me if there are any cases
where this doesn't behave as expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55158 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes an ownership issue where FieldDecls could be owned both by an ObjCInterfaceDecl and a RecordDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@55037 91177308-0d34-0410-b5e6-96231b3b80d8
- Kill unnecessary #includes in .cpp files. This is an automatic
sweep so some things removed are actually used, but happen to be
included by a previous header. I tried to get rid of the obvious
examples and this was the easiest way to trim the #includes in one
fell swoop.
- We now return to regularly scheduled development.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@54632 91177308-0d34-0410-b5e6-96231b3b80d8
- Drop {Decl.h,DeclObjC.h,IdentifierTable.h} from Expr.h
- Moved Sema::getCurMethodDecl() out of line (dependent on
ObjCMethodDecl via dyn_cast).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@54629 91177308-0d34-0410-b5e6-96231b3b80d8
Even though the test case this fixes is in "tentative-decls.c", this bug didn't have anything to do with our handling of tentative definitions (which is what I first expected). In any event, this is a tricky area of the spec.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@54583 91177308-0d34-0410-b5e6-96231b3b80d8
- Move checking from MergeVarDecl->FinializeDeclaratorGroup. Since MergeVarDecl is called before the initializer is attacted, it can't be done there (this removes a long standing FIXME).
- Add Sema::isTentativeDefinition() and Sema::CheckForFileScopedRedefinitions().
- Remove FIXME's and touch-up test case.
Still some more work to do (forthcoming)...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@54533 91177308-0d34-0410-b5e6-96231b3b80d8
scimark2 on Darwin.
- Added Sema support for asm-label on variables, which I forgot before.
- Update CodeGen to use GlobalDeclMap to determine if static Decls
require emission (instead of LLVM module name lookup). Important
since the Decl name and the LLVM module name can differ.
- <rdar://problem/6116729>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@54388 91177308-0d34-0410-b5e6-96231b3b80d8
- ActOnDeclarator now takes an additional parameter which is the
AsmLabel if used. Its unfortunate that this bubbles up this high,
but we cannot just lump it in as an attribute without mistakenly
*accepting* it as an attribute.
- The actual asm-label itself is, however, encoded as an AsmLabelAttr
on the FunctionDecl.
- Slightly improved parser error recovery on malformed asm-labels.
- CodeGen support still missing...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@54339 91177308-0d34-0410-b5e6-96231b3b80d8
move getAsArrayType into ASTContext instead of being a method on type.
This is required because getAsArrayType(const AT), where AT is a typedef
for "int[10]" needs to return ArrayType(const int, 10).
Fixing this greatly simplifies getArrayDecayedType, which is a good sign.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@54317 91177308-0d34-0410-b5e6-96231b3b80d8
This change also fixes a subtle bug where the access control of an ivar would be initialized to garbage if we didn't have an explicit visibility specifier (e.g., @private).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@53955 91177308-0d34-0410-b5e6-96231b3b80d8
of a specific smallvector size.
Fix protocol lists to pass down proper location info, so we get diagnostics
like this:
t.m:3:35: error: cannot find protocol definition for 'NSCopying', referenced by 'NSWhatever'
@interface NSWhatever : NSObject <NSCopying>
^
instead of this:
t.m:3:44: error: cannot find protocol definition for 'NSCopying', referenced by 'NSWhatever'
@interface NSWhatever : NSObject <NSCopying>
^
Add a new IdentifierLocPair typedef which is just a pair<IdentifierInfo*, SourceLocation>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@53883 91177308-0d34-0410-b5e6-96231b3b80d8
- Make sure ObjCIvarDecl propagates the bitfield width.
- RewriteObjC::SynthesizeIvarOffsetComputation(): Avoid using the __OFFSETOF__ mumbo jumbo for bitfields (since it isn't legal C). This fixes <rdar://problem/5986079> clang ObjC rewriter: bitfields and ivar access don't mix.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@53694 91177308-0d34-0410-b5e6-96231b3b80d8
also fix the correspondent test (it was expecting more errors than it should. please confirm my fix is correct (at least gcc agrees with me)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@53174 91177308-0d34-0410-b5e6-96231b3b80d8
used to mutate the attribute list for declspecs when the type was
converted, breaking the case where one declspec was shared by multiple
declarators.
This fixes rdar://6032532.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@52769 91177308-0d34-0410-b5e6-96231b3b80d8
isn't guaranteed to exist. This fixes a crash with conflicting typedefs
coming from stdin.
This also fixes the crash in PR2406, but doesn't completely fix the
issue; it appears there's something strange about the physical location
for the definition of int64_t in stdlib.h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@52209 91177308-0d34-0410-b5e6-96231b3b80d8
-ScopedDecls get chained to their DeclContext.
-DeclContext's DeclChain replaces FunctionDecl's DeclChain and EnumDecl's ElementList.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@52164 91177308-0d34-0410-b5e6-96231b3b80d8
pointer cast hack currently in isIntegerConstantExpr
(in lib/AST/Expr.cpp). Also removes an odd test that even gcc doesn't accept.
The reason the pointer cast hack is relevant here is that it makes Sema
end up misinterpreting the relevant expression as a null pointer constant.
The reason for this patch is that I plan to remove the pointer cast hack
sometime soon because it causes strange issues, especially in its
current form; see my recent email to cfe-dev
"[PATCH] add constant expression evaluation to the AST and fix PR2413".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@52120 91177308-0d34-0410-b5e6-96231b3b80d8
moves the check for the invalid construct to a point where it doesn't
affect other uses of isIntegerConstantExpr, and we can warn properly
when the extension is used. This makes it a bit more complicated, but
it's a lot cleaner.
Steve, please tell me if this check is sufficient to handle the
relevant system header. I know it's enough to handle the testcase, but
I don't know what exactly the original looks like.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@51918 91177308-0d34-0410-b5e6-96231b3b80d8
required by the standard (the standard doesn't know anything about
implicit casts).
Disallow pointers cast to non-integral arithmetic types as constant
expressions. This was previously allowed by accident.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@51779 91177308-0d34-0410-b5e6-96231b3b80d8
encountered. Mixing up the decls is unintuitive, and confuses the AST
destruction code. Fixes PR2360.
Note that there is a need to look up the characteristics and
declarations of a function associated with a particular name or decl,
but the original swapping code doesn't solve it properly.
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-May/001644.html is one
suggestion for how to fix that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@51584 91177308-0d34-0410-b5e6-96231b3b80d8
it fixes PR2204. Not too much to say about the implementation; it works
in a similar way to the vector size attribute.
At some point, we need to modify the targets to provide information
about the appropriate types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@51577 91177308-0d34-0410-b5e6-96231b3b80d8
Turns out that there are multiple places where a redefinition diagnostic can be emitted. A cleaner solution (without touching Sema) is to have
the Driver turn off these diagnostics. (will submit this patch soon)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@51502 91177308-0d34-0410-b5e6-96231b3b80d8
lib/CodeGen/CGExpr.cpp and to change include/clang/AST/Attr.h to
use its own enum for visibility types instead of using
llvm::GlobalValue::VisibilityTypes. These changes eliminate
dependencies in the AST library on LLVM's VMCore library.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@51398 91177308-0d34-0410-b5e6-96231b3b80d8
in Sema, per discussion on mailing list. This doesn't cause any changes
in the test results. I'll probably add some more tests at some point,
but it's an open question what we need to accept to be compatible with
real code.
This doesn't touch the existing isConstantExpr method on Expr; that
should be addressed somehow eventually (either removed or refined to
whatever is appropriate).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@51318 91177308-0d34-0410-b5e6-96231b3b80d8
-identifierResolver exposes an iterator interface to get all decls through the scope chain.
-The semantic staff (checking IdentifierNamespace and Doug's checking for shadowed tags were moved out of IdentifierResolver and back into Sema. IdentifierResolver just gives an iterator for all reachable decls of an identifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@50923 91177308-0d34-0410-b5e6-96231b3b80d8
Still need to iron out some of the semantics (fixmes are present).
This addresses <rdar://problem/5916348>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@50866 91177308-0d34-0410-b5e6-96231b3b80d8
NOTE: This work is incomplete and still fails many tests (as a result, it isn't enabled yet). Nevertheless, I wanted to check it in so I can work on it from home.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@50544 91177308-0d34-0410-b5e6-96231b3b80d8
-NamespaceDecl for the AST
-Checks for name clashes between namespaces and tag/normal declarations.
This commit doesn't implement proper name lookup for namespaces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@50321 91177308-0d34-0410-b5e6-96231b3b80d8
DeclContext *CtxDecl -> DeclContext *DeclCtx
DeclContext *CD -> DeclContext *DC
It makes the code more consistent."
Patch by Zhongxing Xu!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@50105 91177308-0d34-0410-b5e6-96231b3b80d8
-Added TranslationUnitDecl class to serve as top declaration context
-ASTContext gets a TUDecl member and a getTranslationUnitDecl() function
-All ScopedDecls get the TUDecl as DeclContext when declared at global scope
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49855 91177308-0d34-0410-b5e6-96231b3b80d8
This is a fairly mechanical/large change. As a result, I avoided making any changes/simplifications that weren't directly related. I did break two Analysis tests. I also have a couple FIXME's in UninitializedValues.cpp. Ted, can you take a look? If the bug isn't obvious, I am happy to dig in and fix it (since I broke it).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49748 91177308-0d34-0410-b5e6-96231b3b80d8
allows the parsing of "class" in addition to "struct" and "union" to
declare a record. So this patch allows:
class C { };
class C c1;
But it does not contain the lookup bits, so this won't work yet:
C c2;
Patch by Doug Gregor!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49613 91177308-0d34-0410-b5e6-96231b3b80d8
1) objc ivar processing is split out of ActOnField into its own ActOnIvar method.
2) the new objc ivar action takes visibility info directly, eliminating
AllVisibilities in ParseObjCClassInstanceVariables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49506 91177308-0d34-0410-b5e6-96231b3b80d8
-Added ContextDecl (no TranslationUnitDecl)
-ScopedDecl class has a ContextDecl member
-FieldDecl class has a ContextDecl member, so that a Field or a ObjCIvar can be traced back to their RecordDecl/ObjCInterfaceDecl easily
-FunctionDecl, ObjCMethodDecl, TagDecl, ObjCInterfaceDecl inherit from ContextDecl. With TagDecl as ContextDecl, enum constants have a EnumDecl as their context.
-Moved Decl class to a "DeclBase.h" along with ContextDecl class
-CurContext is handled by Sema
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49208 91177308-0d34-0410-b5e6-96231b3b80d8
I also finished unifying access to scope decl change by converting Sema::getObjCInterfaceDecl() to use Sema::LookupDecl(). This is much cleaner now:-)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49107 91177308-0d34-0410-b5e6-96231b3b80d8
(1) Remove IdLoc (it's never used).
(2) Add a bool to enable/disable lazy builtin creaation (defaults to true).
This enables us to use LookupDecl() in Sema::isTypeName(), which is also part of this commit.
To make this work, I changed isTypeName() to be a non-const member function. I'm not happy with this, however I fiddled with making LookupDecl() and friends const and it got ugly pretty quickly. We can certainly add it back if/when someone has time to fiddle with it. For now, I thought this simplification was more important than retaining the const-ness.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49087 91177308-0d34-0410-b5e6-96231b3b80d8
First, we got several CVR propagation cases wrong, which Eli pointed
out in PR2039.
Second, we didn't propagate address space qualifiers correctly, leading
to incorrect lowering of code in CodeGen/address-space.c.
Third, we didn't uniformly propagate the specifier in the array to the
pointer ("int[restrict 4]" -> "int *restrict").
This adds an ASTContext::getArrayDecayedType member that handles the
non-trivial logic for this seemingly simple operation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49078 91177308-0d34-0410-b5e6-96231b3b80d8
- Added a DenseMap to associate an IdentifierInfo with the ObjCCompatibleAliasDecl.
- Renamed LookupScopedDecl->LookupDecl and changed it's return type to Decl. Also added lookup for ObjCCompatibleAliasDecl's.
- Removed Sema::LookupInterfaceDecl(). Converted clients to used LookupDecl().
- Some minor indentation changes.
Will deal with ObjCInterfaceDecl and getObjCInterfaceDecl() in a separate commit...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@49058 91177308-0d34-0410-b5e6-96231b3b80d8
lib dir and move all the libraries into it. This follows the main
llvm tree, and allows the libraries to be built in parallel. The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in. This speeds
up parallel builds, particularly incremental ones.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@48402 91177308-0d34-0410-b5e6-96231b3b80d8
Sebastian Redl