| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
types don't get generated when blocks aren't used.
llvm-svn: 67898
|
|
|
|
| |
llvm-svn: 67897
|
|
|
|
| |
llvm-svn: 67895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LHS type and the computation result type; this encodes information into
the AST which is otherwise non-obvious. Fix Sema to always come up with the
right answer for both of these types. Fix IRGen and the analyzer to
account for these changes. This fixes PR2601. The approach is inspired
by PR2601 comment 2.
Note that this changes real *= complex in CodeGen from a silent
miscompilation to an explicit error.
I'm not really sure that the analyzer changes are correct, or how to
test them... someone more familiar with the analyzer should check those
changes.
llvm-svn: 67889
|
|
|
|
| |
llvm-svn: 67887
|
|
|
|
|
|
|
| |
syntax into extension warnings, and provide code-modification hints
showing how to fix the problem.
llvm-svn: 67885
|
|
|
|
|
|
| |
GNU-style array designators, causing us to emit broken initializers.
llvm-svn: 67878
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instantiation for C++ typename-specifiers such as
typename T::type
The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,
typename T::template apply<U, V>
Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.
Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples.
llvm-svn: 67875
|
|
|
|
| |
llvm-svn: 67870
|
|
|
|
|
|
| |
remove a redundant error in CodeGen.
llvm-svn: 67868
|
|
|
|
|
|
|
|
|
|
|
| |
the class that the private base class is a base of:
class A {};
class B : private A {
void f(B *b) { A* a = b; }
};
llvm-svn: 67860
|
|
|
|
|
|
| |
but that will change. (Also, protected isn't implemented right now).
llvm-svn: 67827
|
|
|
|
|
|
|
| |
to a function or function pointer, it's probably because the user
forgot to put in parentheses () to call the function.
llvm-svn: 67826
|
|
|
|
| |
llvm-svn: 67818
|
|
|
|
|
|
| |
classes. Test case from Anders Carlsson, fix from Piotr Rak!
llvm-svn: 67817
|
|
|
|
|
|
|
|
|
| |
disabled but are used anyway
by changing blocks from being disabled in the parser to being disabled
in Sema.
llvm-svn: 67816
|
|
|
|
|
|
| |
- <rdar://problem/6710978> ccc/clang-driver ignore -fno-common
llvm-svn: 67762
|
|
|
|
| |
llvm-svn: 67761
|
|
|
|
|
|
|
| |
- <rdar://problem/6717381> [driver] implement ld argument translation
in new driver
llvm-svn: 67760
|
|
|
|
|
|
| |
Treat @package the same as @public. The documentation for @package says it is analogous to private_extern for variables/functions. Fully implementing this requires some kind of linker support (so access is denied to code outside the classes executable image). I don't believe GCC fully implements this semantic. Will discuss with Fariborz offline.
llvm-svn: 67755
|
|
|
|
| |
llvm-svn: 67746
|
|
|
|
| |
llvm-svn: 67726
|
|
|
|
|
|
| |
original declaration.
llvm-svn: 67722
|
|
|
|
|
|
| |
is of type void*. I'll try to add the appropriate checking later.
llvm-svn: 67721
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specializations can be treated as a template. Finally, we can parse
and process the first implementation of Fibonacci I wrote!
Note that this code does not handle all of the cases where
injected-class-names can be treated as templates. In particular,
there's an ambiguity case that we should be able to handle (but
can't), e.g.,
template <class T> struct Base { };
template <class T> struct Derived : Base<int>, Base<char> {
typename Derived::Base b; // error: ambiguous
typename Derived::Base<double> d; // OK
};
llvm-svn: 67720
|
|
|
|
|
|
|
|
| |
a C++ record decl.
Also, fix fallout from the change.
llvm-svn: 67717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates, including in-class initializers. For example:
template<typename T, T Divisor>
class X {
public:
static const T value = 10 / Divisor;
};
instantiated with, e.g.,
X<int, 5>::value
to get the value '2'.
llvm-svn: 67715
|
|
|
|
| |
llvm-svn: 67708
|
|
|
|
|
|
|
|
|
|
|
| |
the declarations of member classes are instantiated when the owning
class template is instantiated. The definitions of such member classes
are instantiated when a complete type is required.
This change also introduces the injected-class-name into a class
template specialization.
llvm-svn: 67707
|
|
|
|
|
|
| |
... arguments.
llvm-svn: 67706
|
|
|
|
| |
llvm-svn: 67697
|
|
|
|
|
|
| |
from previous block literals.
llvm-svn: 67696
|
|
|
|
| |
llvm-svn: 67695
|
|
|
|
| |
llvm-svn: 67685
|
|
|
|
|
|
|
| |
we aren't going to support. For example:
clang -Xarch_i386 -S -Xarch_i386 -o -Xarch_i386 myi386asm.s ...
llvm-svn: 67680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
line decls, such as:
class C {
C() { }
int a;
};
C::C() : a(10) { }
We also diagnose when initializers are used on declarations that aren't constructors:
t.cpp:1:10: error: only constructors take base initializers
void f() : a(10) { }
^
Doug and/or Sebastian: I'd appreciate a review, especially the nested-name-spec test results (from the looks of it we now match gcc in that test.)
llvm-svn: 67672
|
|
|
|
| |
llvm-svn: 67664
|
|
|
|
| |
llvm-svn: 67653
|
|
|
|
|
|
|
|
|
|
|
|
| |
- -emit-llvm no longer changes what compilation steps are done.
- -emit-llvm and -emit-llvm -S write output files with .o and .s
suffixes, respectively.
- <rdar://problem/6714125> clang-driver should support -O4 and -flto,
like llvm-gcc
llvm-svn: 67645
|
|
|
|
|
|
|
| |
incomplete types. RequireCompleteType is needed when the type may be
completed by instantiating a template.
llvm-svn: 67643
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Don't default to using clang for C++ (use -ccc-clang-cxx to
override).
- Default to only using clang on i386 and x86_64 (use
-ccc-clang-archs "" to override).
- <rdar://problem/6712350> [driver] clang should not be used on
powerpc by default
- <rdar://problem/6705767> driver should default to -ccc-no-clang-cxx
I plan to add a warning that we are not using the clang compiler for
the given compilation so that users do not think clang is being used
in situations it isn't.
This change is motivated by the desire to be able to drop clang into a
build and have things "just work", even if it happens to get used to
compile C++ code or code for an architecture we don't support yet.
llvm-svn: 67640
|
|
|
|
|
|
|
| |
- <rdar://problem/6715707> driver should translate -fverbose-asm into
-asm-verbose
llvm-svn: 67634
|
|
|
|
|
|
|
| |
- <rdar://problem/6715818> clang doesn't honor gcc semantic that last
-O optimization option wins.
llvm-svn: 67628
|
|
|
|
|
|
| |
outside the class declaration.
llvm-svn: 67627
|
|
|
|
| |
llvm-svn: 67625
|
|
|
|
| |
llvm-svn: 67623
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Substitutes both clang and clang-cc.
- Incorporates patch from Jon Simons to diagnose if clang or clang-cc
isn't found.
- Uses full path when running scripts, for more precision in the
output.
llvm-svn: 67610
|
|
|
|
|
|
| |
Again, I tried to update cmake but it is untested.
llvm-svn: 67606
|
|
|
|
| |
llvm-svn: 67603
|
|
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|