| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
a size, check whether the transformed type is itself an array type. If
so, take the major array bound as the size to allocate. Fixes PR5833.
llvm-svn: 91907
|
| |
|
|
|
|
| |
don't have a FunctionDecl) over to InitializationSequence.
llvm-svn: 91906
|
| |
|
|
|
|
| |
use the location information but we did spend a bunch of time building faked-up TypeLocs
llvm-svn: 91905
|
| |
|
|
|
|
| |
avoid #including CharUnits.h in ASTContext.h.
llvm-svn: 91903
|
| |
|
|
|
|
|
|
|
|
|
| |
InitializationSequence (when a FunctionDecl is present). This required
a few small fixes to initialization sequences:
- Make sure to use the adjusted parameter type for initialization of
function parameters.
- Implement transparent union calling semantics in C
llvm-svn: 91902
|
| |
|
|
|
|
|
|
| |
correctly, giving them the correct arity.
With this seemingly insignificant fix, we are now able to build and link clang using clang itself! (LLVM still has to be built with gcc for the time being).
llvm-svn: 91893
|
| |
|
|
| |
llvm-svn: 91891
|
| |
|
|
|
|
| |
who prefers to be stealthy and mysterious.
llvm-svn: 91888
|
| |
|
|
|
|
| |
must also mark the member decl as referenced.
llvm-svn: 91887
|
| |
|
|
| |
llvm-svn: 91884
|
| |
|
|
| |
llvm-svn: 91883
|
| |
|
|
| |
llvm-svn: 91882
|
| |
|
|
| |
llvm-svn: 91881
|
| |
|
|
|
|
|
|
| |
integer.
- This is consistent, but may not be correct. I will revisit x86_64 ABI handling for C++ as a whole at some point.
- PR5831.
llvm-svn: 91874
|
| |
|
|
|
|
| |
before in the new function Sema::DiagRuntimeBehavior, addressing one of Chris' comments.
llvm-svn: 91870
|
| |
|
|
|
|
|
|
|
| |
this was useful, and on review Doug and I decided it was probably on the level
of a bug in the standard and therefore not worth a warning even in -pedantic.
If someone disagrees and urgently wants clang++ to warn about this in strict
c++98 mode, we can talk about it.
llvm-svn: 91868
|
| |
|
|
| |
llvm-svn: 91865
|
| |
|
|
|
|
| |
since the context is available in the Decl
llvm-svn: 91862
|
| |
|
|
|
|
|
|
|
| |
constructor call, the conversion is only a standard conversion
sequence if that constructor is a copy constructor. This fixes PR5834
in a semi-lame way, because the "real" fix will be to move over to
InitializationSequence. That will happen "soonish", but not now.
llvm-svn: 91861
|
| |
|
|
|
|
|
| |
sure to fill in the initialized member of a union when a member was
explicitly designated. Fixes PR5843.
llvm-svn: 91858
|
| |
|
|
|
|
| |
imported block variables. WIP.
llvm-svn: 91856
|
| |
|
|
|
|
|
|
| |
- Correctly is in quotes, because we are following what I interpreted as GCC's
intent (which diverges from practice, naturally).
- Also, fix the arch define for arm1136jf-s.
llvm-svn: 91855
|
| |
|
|
|
|
|
|
|
|
| |
explicitly-specified template arguments are enough to determine the
instantiation, and either template argument deduction fails or is not
performed in that context, we can resolve the template-id down to a
function template specialization (so sayeth C++0x
[temp.arg.explicit]p3). Fixes PR5811.
llvm-svn: 91852
|
| |
|
|
|
|
|
|
|
| |
not deduce an "overload" type. Such a deduction indicates a failure in
semantic analysis (e.g., PR5811) that currently isn't caught until
code-generation time. This assertions makes it clearer that this
particular issue is a semantic-analysis problem, not a code-gen problem.
llvm-svn: 91844
|
| |
|
|
|
|
|
|
|
| |
recursing in CGDebugInfo::CreateTypeNode, teach
CanonicalizeTypeForDebugInfo---now called UnwrapTypeForDebugInfo---to
keep unwrapping the type until we hit something that can be
represented by debug information. Thanks to Anders for pointing this out!
llvm-svn: 91840
|
| |
|
|
|
|
|
|
| |
ElaboratedType, QualifiedNameType, and SubstTemplateTypeParmType type
nodes. Also, produce an "unsupported" diagnostic for C++0x type nodes
and "typeof" nodes, rather than asserting nondescriptly.
llvm-svn: 91837
|
| |
|
|
|
|
| |
object.
llvm-svn: 91830
|
| |
|
|
|
|
| |
as a g++ extension (fixes radar 7481987).
llvm-svn: 91827
|
| |
|
|
|
|
| |
support diagnostics and error recovery.
llvm-svn: 91825
|
| |
|
|
| |
llvm-svn: 91818
|
| |
|
|
|
|
|
|
|
|
| |
Sema::getTypeName.
"LookupNestedNameSpecifierName" isn't quite the right kind of lookup, though;
it doesn't ignore namespaces. Someone more familiar with the lookup code
should fix this properly.
llvm-svn: 91809
|
| |
|
|
| |
llvm-svn: 91808
|
| |
|
|
| |
llvm-svn: 91807
|
| |
|
|
| |
llvm-svn: 91805
|
| |
|
|
|
|
| |
pointee is incomplete.
llvm-svn: 91804
|
| |
|
|
| |
llvm-svn: 91803
|
| |
|
|
| |
llvm-svn: 91802
|
| |
|
|
|
|
| |
pull ':' eating out of ParseAsmOperandsOpt.
llvm-svn: 91801
|
| |
|
|
|
|
| |
right linkage for indirect pointers to incomplete structs.
llvm-svn: 91799
|
| |
|
|
|
|
| |
assignment.
llvm-svn: 91798
|
| |
|
|
| |
llvm-svn: 91797
|
| |
|
|
|
|
| |
over to InitializationSequence. I could swear that this fixes a PR somewhere, but I couldn't figure out which one
llvm-svn: 91796
|
| |
|
|
| |
llvm-svn: 91795
|
| |
|
|
| |
llvm-svn: 91794
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of the rules of base-class lookup* and the restrictions on typedefs, it
was actually impossible for this to cause any problems more serious than the
spurious acceptance of
template <class T> class A : B<A> { ... };
instead of
template <class T> class A : B<A<T> > { ... };
but I'm sure we can all agree that that is a very important restriction which
is well worth making another Parser->Sema call for.
(*) n.b. clang++ does not implement these rules correctly; we are not ignoring
non-type names
llvm-svn: 91792
|
| |
|
|
|
|
| |
quite right; I'll come back to it later. It does fix PR 5741.
llvm-svn: 91789
|
| |
|
|
|
|
|
| |
would have a higher respect for its own code. This is getting old, is this
warning really adding value?
llvm-svn: 91779
|
| |
|
|
| |
llvm-svn: 91772
|
| |
|
|
|
|
|
| |
the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can
live with that; they'll need to be fixed more holistically anyhow.
llvm-svn: 91771
|
| |
|
|
|
|
| |
instantiation, since we're not using a Scope object for that anyway.
llvm-svn: 91770
|