| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
attributes are found, propagate them to subsequent declarations.
llvm-svn: 141861
|
| |
|
|
| |
llvm-svn: 141650
|
| |
|
|
| |
llvm-svn: 141645
|
| |
|
|
| |
llvm-svn: 141610
|
| |
|
|
|
|
|
|
|
|
|
| |
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
llvm-svn: 141561
|
| |
|
|
| |
llvm-svn: 141549
|
| |
|
|
|
|
|
|
|
|
| |
constexpr constructor templates. Such checking is optional, and currently hard
to get right since clang doesn't generate implicit member initializers until
instantiation (even for non-dependent members).
This is needed for clang to accept libstdc++ from g++4.6 in c++0x mode.
llvm-svn: 141547
|
| |
|
|
|
|
|
|
| |
initializer to update the type of the declaration. For example, this
allows us to determine the size of an incomplete array from its
initializer. Fixes PR10288.
llvm-svn: 141543
|
| |
|
|
|
|
|
| |
declarator, so that the declarator is in scope for the
initializer. Fixes PR9989.
llvm-svn: 141539
|
| |
|
|
|
|
|
|
|
|
|
| |
Begin with just default constructors. One note is that as a side effect
of this, a conformance test was removed on the basis that this is almost
certainly a defect as with most of union initialization. As it is, clang
does not implement union initialization close to the standard as it's
quite broken as written. I hope to write a paper addressing the issues
eventually.
llvm-svn: 141528
|
| |
|
|
|
|
|
| |
defining a friend function with a qualified name or in a local
class. Fixes PR9853.
llvm-svn: 141524
|
| |
|
|
|
|
| |
non-identifier name. Fixes PR10839.
llvm-svn: 141513
|
| |
|
|
|
|
|
|
| |
committed at the moment to help support C++0x <atomic>, but it should be a solid base for implementing the full specification of C1x _Atomic.
Thanks to Jeffrey Yasskin for the thorough review!
llvm-svn: 141330
|
| |
|
|
| |
llvm-svn: 141171
|
| |
|
|
| |
llvm-svn: 140978
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
part on patches by Peter Collingbourne.
We diverge from the C++11 standard in a few areas, mostly related to checking
constexpr function declarations, and not just definitions. See WG21 paper
N3308=11-0078 for details.
Function invocation substitution is not available in this patch; constexpr
functions cannot yet be used from within constant expressions.
llvm-svn: 140926
|
| |
|
|
|
|
| |
We had an extension which allowed const static class members of floating-point type to have in-class initializers, 'as a C++0x extension'. However, C++0x does not allow this. The extension has been kept, and extended to all literal types in C++0x mode (with a fixit to add the 'constexpr' specifier).
llvm-svn: 140801
|
| |
|
|
| |
llvm-svn: 140478
|
| |
|
|
|
|
|
|
|
|
|
| |
correctly pass
the information on to Sema. There's still an incorrectness in the way template instantiation
works now, but that is due to a far larger underlying representational problem.
Also add a test case for various list initialization cases of scalars, which test this
commit as well as the previous one.
llvm-svn: 140460
|
| |
|
|
| |
llvm-svn: 140407
|
| |
|
|
|
|
|
|
| |
the key function is inline, rather than the original
declaration. Perhaps FunctionDecl::isInlined() is poorly named. Fixes
<rdar://problem/9979458>.
llvm-svn: 140400
|
| |
|
|
| |
llvm-svn: 140367
|
| |
|
|
|
|
| |
constructor template. Fixes PR10457.
llvm-svn: 140350
|
| |
|
|
|
|
|
|
| |
generation when we're dealing with an implicitly-defined copy or move
constructor. And, actually set the implicitly-defined bit for
implicitly-defined constructors and destructors. Should fix self-host.
llvm-svn: 140334
|
| |
|
|
| |
llvm-svn: 140293
|
| |
|
|
| |
llvm-svn: 140268
|
| |
|
|
|
|
| |
Dyatkovskiy! Fixes PR10896.
llvm-svn: 140250
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of false positive warnings that depend on noreturn destructors pruning
the CFGs, but only in C++0x mode!
This was really surprising as the debugger quickly reveals that the
attributes are parsed correctly (and using the same code) in both modes.
The warning fires in the same way in both modes. But between parsing and
building the destructor declaration with the noreturn attribute and the
warning, it magically disappears. The key? The 'noexcept' appears!
When we were rebuilding the destructor type with the computed implicit
noexcept we completely dropped the old type on the floor. This almost
makes sense (as the arguments and return type to a destructor aren't
exactly unpredictable), but lost any function type attributes as well.
The fix is simple, we build the new type off of the old one rather than
starting fresh.
Testing this is a bit awkward. I've done it by running the
noreturn-sensitive tests in both modes, which previous failed and now
passes, but if anyone has ideas about how to more specifically and
thoroughly test that the extended info on a destructor is preserved when
adding noexcept, I'm all ears.
llvm-svn: 140138
|
| |
|
|
| |
llvm-svn: 140017
|
| |
|
|
|
|
| |
anonymous structs contained within anonymous unions.
llvm-svn: 140015
|
| |
|
|
|
|
| |
bringing this to my attention.
llvm-svn: 140013
|
| |
|
|
|
|
|
|
|
| |
Prior to C++11, this
has no effect since any such destructors must be trivial, and in C++11 such destructors must not
be called.
llvm-svn: 139997
|
| |
|
|
|
|
|
|
| |
constructors if no
mem-initializer is specified for them, unless an in-class initializer is specified.
llvm-svn: 139996
|
| |
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
| |
|
|
|
|
| |
must also be present of the first declaration of that entity.
llvm-svn: 139384
|
| |
|
|
|
|
| |
CXXBaseSpecifier, CXXCtorInitializer, NestedNameSpecifier, TemplateParameterList and removed their typedefs.
llvm-svn: 139350
|
| |
|
|
|
|
|
| |
indicates that a declaration is only visible within the module it is
declared in.
llvm-svn: 139348
|
| |
|
|
| |
llvm-svn: 139347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
synthesized move assignment within an implicitly-defined move
assignment operator, be sure to treat the derived-to-base cast as an
xvalue (rather than an lvalue). Otherwise, we'll end up getting the
wrong constructor.
Optimize a direct call to a trivial move assignment operator to an
aggregate copy, as we do for trivial copy assignment operators, and
update the the assertion in CodeGenFunction::EmitAggregateCopy() to
cope with this optimization.
Fixes PR10860.
llvm-svn: 139143
|
| |
|
|
|
|
|
|
| |
Fix bug this uncovered.
Address minor comments from Doug.
Enable cxx_implicit_moves feature.
llvm-svn: 139101
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
well.
Also, clean up the flow of the code a bit, and factor things more
nicely.
Finally, add the test case that was missing from my previous
commit (sorry), with new tests added to cover temporaries and other fun
cases.
llvm-svn: 139077
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference members of classes. We've had several bugs reported because of
this, and there's no reason not to flag it right away in the compiler.
Comments especially welcome on the strategy for implementing this
warning (IE, what should trigger this?) and on the text of the warning
itself.
I'm going to extend this to cover obvious cases with temporaries and
beef up the test cases some in subsequent patches. I'll then run it over
a large codebase and make sure its not misbehaving before I add it to
-Wall or turn it on by default. I think this one might be a good
candidate for on by default.
llvm-svn: 139075
|
| |
|
|
|
|
|
|
| |
semantic analysis when taking the address of an xvalue. Instead, just
build the unary operator directly, since it's safe to do so (from the
IRgen and AST perspectives) for any glvalue. Fixes PR10822.
llvm-svn: 138935
|
| |
|
|
|
|
|
|
|
| |
collision between C99 hexfloats and C++0x user-defined literals by
giving C99 hexfloats precedence. Also, warning about user-defined
literals that conflict with hexfloats and those that have names that
are reserved by the implementation. Fixes <rdar://problem/9940194>.
llvm-svn: 138839
|
| |
|
|
|
|
|
|
|
| |
This makes the code duplication of implicit special member handling even worse,
but the cleanup will have to come later. For now, this works.
Follow-up with tests for explicit defaulting and enabling the __has_feature
flag to come.
llvm-svn: 138821
|
| |
|
|
| |
llvm-svn: 137653
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization.
Example:
template <class T>
class A {
public:
template <class U> void f(U p) { }
template <> void f(int p) { } // <== class scope specialization
};
This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code.
BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error.
llvm-svn: 137573
|
| |
|
|
|
|
|
| |
special member function, make sure to classify an explicitly-defaulted
copy constructor as a "copy" operation. Fixes PR10622.
llvm-svn: 137219
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
constructor. Previously, we did some bogus recursion into the fields
of anonymous structs (recursively), which ended up building invalid
ASTs that would cause CodeGen to crash due to invalid GEPs.
Now, we instead build the default initializations based on the
indirect field declarations at the top level, which properly generates
the sequence of GEPs needed to initialize the proper member. Fixes
PR10512 and <rdar://problem/9924046>.
llvm-svn: 137212
|
| |
|
|
|
|
|
| |
Use the the path that generates a loop. This fixes
bogus error that clang puts out. // rdar://9894548
llvm-svn: 137080
|