| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
This is simple enough, but then I thought it would be nice to make PrintingPolicy
get a LangOptions so that various things can key off "bool" and "C++" independently.
This spiraled out of control. There are many fixme's, but I think things are slightly
better than they were before.
One thing that can be improved: CFG should probably have an ASTContext pointer in it,
which would simplify its clients.
llvm-svn: 74493
|
|
|
|
| |
llvm-svn: 74304
|
|
|
|
| |
llvm-svn: 74099
|
|
|
|
|
|
|
|
|
|
|
|
| |
representation.
Add a type (ObjCObjectPointerType) and remove a type (ObjCQualifiedIdType).
This large/tedious patch is just a first step. Next step is to remove ObjCQualifiedInterfaceType. After that, I will remove the magic TypedefType for 'id' (installed by Sema). This work will enable various simplifications throughout clang (when dealing with ObjC types).
No functionality change.
llvm-svn: 73649
|
|
|
|
|
|
|
|
| |
info. To handle this edge case, always create main compile unit first.
This fixes PR 4228.
llvm-svn: 73520
|
|
|
|
|
|
|
|
|
| |
printing logic to help customize the output. For now, we use this
rather than a special flag to suppress the "struct" when printing
"struct X" and to print the Boolean type as "bool" in C++ but "_Bool"
in C.
llvm-svn: 72590
|
|
|
|
|
|
| |
- Just SmallVectors this time.
llvm-svn: 72432
|
|
|
|
| |
llvm-svn: 72210
|
|
|
|
|
|
| |
interface types.
llvm-svn: 72036
|
|
|
|
| |
llvm-svn: 71763
|
|
|
|
|
|
|
| |
emit the correct "display name". I suspect we need more work here, see
FIXME for example.
llvm-svn: 71761
|
|
|
|
|
|
| |
debug info.
llvm-svn: 71736
|
|
|
|
|
|
|
| |
types. In this case, it was objc_selector and objc_class. This fixes
rdar://6852754 - clang sometimes generates incorrect/unknown file/line info for DW_TAG__structure_type dies
llvm-svn: 70969
|
|
|
|
|
|
|
|
| |
DIEs. We were generating a loc with line of 0 and a file.
These tags do not need locations at all, just remove it.
this fixes rdar://6852792 - Clang generates incorrect (and unnecessary) file and line info for DW_TAG_inheritance dies
llvm-svn: 70966
|
|
|
|
|
|
|
|
| |
in ObjC) to not emit file/line location information. Previously
we would output a file with bogus line information. This fixes:
rdar://6852814 - Clang generates incorrect file & line info for automatic/understood formal parameters for objc-programs
llvm-svn: 70965
|
|
|
|
| |
llvm-svn: 70825
|
|
|
|
|
|
|
| |
the runtime version number onto it, so that the debugger knows it's an objc
interface, not a C struct. rdar://6848435
llvm-svn: 70618
|
|
|
|
| |
llvm-svn: 70617
|
|
|
|
|
|
|
|
| |
rdar://6848435,
several other fixes coming.
llvm-svn: 70616
|
|
|
|
| |
llvm-svn: 70266
|
|
|
|
| |
llvm-svn: 70145
|
|
|
|
|
|
|
|
| |
preprocessed source file without -main-file-name. In this case, CDDebugInfo is not able identify correct main source file becase SM.isFromMainFile() returns true for locations from header files as well as locations from main source file.
This patch takes conservative approach by not emitting more then one compile unit with isMain bit set.
llvm-svn: 69902
|
|
|
|
| |
llvm-svn: 69873
|
|
|
|
| |
llvm-svn: 69784
|
|
|
|
| |
llvm-svn: 69783
|
|
|
|
| |
llvm-svn: 69517
|
|
|
|
| |
llvm-svn: 69389
|
|
|
|
| |
llvm-svn: 69387
|
|
|
|
|
|
| |
No functionality change (really).
llvm-svn: 68726
|
|
|
|
| |
llvm-svn: 68630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- This is pretty ugly, but the most obvious solution. Chime in if you
have a nicer one.
- The problem is that with -save-temps, clang-cc has no idea what the
name of the original input file is. However, the user expects to be
able to set breakpoints based on the input file name.
- We support this by providing a new option -main-file-name (similar
to -dumpbase used by gcc) which allows the driver to pass in the
original file name.
- <rdar://problem/6753383> building with clang using --save-temps
gets the compile unit name from the .i file...
llvm-svn: 68595
|
|
|
|
|
|
|
|
| |
types. It is no longer needed now that the code generator
re-lays-out interfaces if they are defines after being laid out
from a forward decl.
llvm-svn: 68194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").
One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as
std::(vector<int>)
we represent it as
(std::vector)<int>
which more closely follows the C++ grammar.
Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.
llvm-svn: 68074
|
|
|
|
|
|
| |
The llvm optimizer and code generator are not yet ready to support optimized code debugging.
llvm-svn: 67876
|
|
|
|
| |
llvm-svn: 67674
|
|
|
|
| |
llvm-svn: 67650
|
|
|
|
| |
llvm-svn: 67389
|
|
|
|
| |
llvm-svn: 67267
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qualified name, e.g.,
foo::x
so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.
The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
::foo::bar::x
The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled).
The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).
Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.
llvm-svn: 67265
|
|
|
|
| |
llvm-svn: 67062
|
|
|
|
|
|
| |
unclear areas. Maybe Doug can shed some light on some of the fixmes.
llvm-svn: 67059
|
|
|
|
| |
llvm-svn: 66580
|
|
|
|
| |
llvm-svn: 66120
|
|
|
|
| |
llvm-svn: 65850
|
|
|
|
| |
llvm-svn: 65671
|
|
|
|
| |
llvm-svn: 65659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
(This is not yet used.)
llvm-svn: 65573
|
|
|
|
| |
llvm-svn: 65423
|
|
|
|
|
|
| |
unit.
llvm-svn: 65403
|