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
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).
llvm-svn: 60878
- Returns addr of constant for argument + '\0'.
- I couldn't think of a better name.
- Move appropriate users of GetAddrOfConstantString to this.
Rename getStringForStringLiteral to GetStringForStringLiteral.
Add GetAddrOfConstantStringFromLiteral
- This combines GetAddrOfConstantString and
GetStringForStringLiteral. This method can be, but is not yet, more
efficient.
Change GetAddrOfConstantString to not add terminating '\0'
- <rdar://problem/6140956>
llvm-svn: 54768
ObjCProtocolDecl directly.
Implement CodeGen support for forward protocol decls (no-ops are so
nice to implement).
Also moved CGObjCRuntime.h out of CodeGenModule.h
llvm-svn: 54709
Changed CGObjCRuntime::GenerateConstantString interface to take
std::string instead of char* and size.
Change ObjC functions which call on GenerateConstantString to bitcast
result to appropriate type.
llvm-svn: 54659
temporarily, I assumed GetAddrForConstantString literal was being
used consistently but it doesn't look like it is.
Factored out a CodeGenModule::getStringForStringLiteral which handles
extracting a std::string for the bytes of a StringLiteral, padded to
match the type.
Update EmitLValue to use getStringForStringLiteral, this was
previously not padding strings correctly. Good thing we only emit
strings in 4 different places!
llvm-svn: 54621
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.
llvm-svn: 54317
- No (intended) functionality change.
- Primary purpose is to clearly separate (lazy) construction of
globals that are a forward declaration or tentative definition from
those that are the final definition.
- Lazy construction is now encapsulated in
GetAddrOf{Function,GlobalVar} while final definitions are
constructed in EmitGlobal{Function,Var}Definition.
- External interface for dealing with globals is now limited to
EmitGlobal and GetAddrOf{Function,GlobalVar}.
- Also updated helper functions dealing with statics, annotations,
and ctors to be private.
llvm-svn: 54179
reported on cfe-dev by Cédric Venet.
Note that I seriously doubt that this perticular construct is useful,
though: it's a pointer in an alternate address space pointing into
unqualified address space.
llvm-svn: 52076
this does is reconstruct the type for structs and arrays if the type
wouldn't be compatible otherwise.
The assertion about packing in the struct type reconstruction code
sucks, but I don't see any obvious way to fix it. Maybe we need a general
utility method to take a list of types and alignments and try to construct an
unpacked type if possible?
llvm-svn: 51785
bit-field initialization; ugly code, X86-only, but it works, at least
for basic stuff. Separates/adds union initialization; currently disabled,
though, because the struct/array code needs modifications to support
elements of the wrong type.
Fixes PR2381 and PR2309 with the bit-field initialization. And NetHack
compiles and appears to work with a few tweaks (to work around the lack
of transparent_union support, and clang being a bit strict about
conflicting declarations).
llvm-svn: 51763
implement bitfield codegen (although I don't envy the person who
implements it). This also prevents a crash on code like that from PR2309
(it's still broken, but it fails more gracefully).
llvm-svn: 51285
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).
llvm-svn: 49748
