summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/dcl.decl/dcl.init/p6.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Implement the likely resolution of core issue 253.Nico Weber2016-02-191-3/+3
| | | | | | | | | | | | | | | | | | C++11 requires const objects to have a user-provided constructor, even for classes without any fields. DR 253 relaxes this to say "If the implicit default constructor initializes all subobjects, no initializer should be required." clang is currently the only compiler that implements this C++11 rule, and e.g. libstdc++ relies on something like DR 253 to compile in newer versions. This change makes it possible to build code that says `const vector<int> v;' again when using libstdc++5.2 and _GLIBCXX_DEBUG (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284). Fixes PR23381. http://reviews.llvm.org/D16552 llvm-svn: 261297
* Move fixit for const init from note to diag, weaken to warning in MS mode.Nico Weber2015-04-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | r235046 turned "extern __declspec(selectany) int a;" from a declaration into a definition to fix PR23242 (required for compatibility with mc.exe output). However, this broke parsing Windows headers: A d3d11 headers contain something like struct SomeStruct {}; extern const __declspec(selectany) SomeStruct some_struct; This is now a definition, and const objects either need an explicit default ctor or an initializer so this errors out with d3d11.h(1065,48) : error: default initialization of an object of const type 'const CD3D11_DEFAULT' without a user-provided default constructor (cl.exe just doesn't implement this rule, independent of selectany.) To work around this, weaken this error into a warning for selectany decls in microsoft mode, and recover with zero-initialization. Doing this is a bit hairy since it adds a fixit on an error emitted by InitializationSequence – this means it needs to build a correct AST, which in turn means InitializationSequence::Failed() cannot return true when this fixit is applied. As a workaround, the patch adds a fixit member to InitializationSequence, and InitializationSequence::Perform() prints the diagnostic if the fixit member is set right after its call to Diagnose. That function is usually called when InitializationSequences are used – InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker case never performs default-initialization, so this is technically OK. This is the alternative, original fix for PR20208 that got reviewed in the thread "[patch] Improve diagnostic on default-initializing const variables (PR20208)". This change basically reverts r213725, adds the original fix for PR20208, and makes the error a warning in Microsoft mode. llvm-svn: 235166
* Improve diagnostic on default-initializing const variables (PR20208).Nico Weber2014-07-231-3/+3
| | | | | | | | This tweaks the diagnostic wording slighly, and adds a fixit on a note. An alternative would be to add the fixit directly on the diagnostic, see the review thread linked to from the bug for a few notes on that approach. llvm-svn: 213725
* Teach Sema::ActOnUninitializedDecl() not to try to interpret when oneDouglas Gregor2011-05-211-0/+12
| | | | | | | | should use a constructor to default-initialize a variable. InitializationSequence knows the rules for default initialization, better. Fixes <rdar://problem/8501008>. llvm-svn: 131796
* 'const std::type_info*' instead of 'std::type_info const*'Chris Lattner2010-09-051-1/+1
| | | | llvm-svn: 113092
* make clang print types as "const int *" instead of "int const*",Chris Lattner2010-09-051-1/+1
| | | | | | | which is should have done from the beginning. As usual, the most fun with this sort of change is updating all the testcases. llvm-svn: 113090
* When pretty-printing tag types, only print the tag if we're in C (andJohn McCall2010-03-101-1/+1
| | | | | | | | | | therefore not creating ElaboratedTypes, which are still pretty-printed with the written tag). Most of these testcase changes were done by script, so don't feel too sorry for my fingers. llvm-svn: 98149
* In C++98/03, an uninitialized variable that has POD class type will beDouglas Gregor2010-03-081-1/+2
| | | | | | | | | uninitialized. This seems not to be the case in C++0x, where we still call the (trivial) default constructor for a POD class (!). Previously, we had implemented only the C++0x rules; now we implement both. Fixes PR6536. llvm-svn: 97928
* Migrate the mish-mash of declaration checks inDouglas Gregor2010-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sema::ActOnUninitializedDecl over to InitializationSequence (with default initialization), eliminating redundancy. More importantly, we now check that a const definition in C++ has an initilizer, which was an #if 0'd code for many, many months. A few other tweaks were needed to get everything working again: - Fix all of the places in the testsuite where we defined const objects without initializers (now that we diagnose this issue) - Teach instantiation of static data members to find the previous declaration, so that we build proper redeclaration chains. Previously, we had the redeclaration chain but built it too late to be useful, because... - Teach instantiation of static data member definitions not to try to check an initializer if a previous declaration already had an initializer. This makes sure that we don't complain about static const data members with in-class initializers and out-of-line definitions. - Move all of the incomplete-type checking logic out of Sema::FinalizeDeclaratorGroup; it makes more sense in ActOnUnitializedDecl. There may still be a few places where we can improve these diagnostics. I'll address that as a separate commit. llvm-svn: 95657
* Rework base and member initialization in constructors, with severalDouglas Gregor2010-01-311-0/+15
(necessarily simultaneous) changes: - CXXBaseOrMemberInitializer now contains only a single initializer rather than a set of initialiation arguments + a constructor. The single initializer covers all aspects of initialization, including constructor calls as necessary but also cleanup of temporaries created by the initializer (which we never handled before!). - Rework + simplify code generation for CXXBaseOrMemberInitializers, since we can now just emit the initializer as an initializer. - Switched base and member initialization over to the new initialization code (InitializationSequence), so that it - Improved diagnostics for the new initialization code when initializing bases and members, to match the diagnostics produced by the previous (special-purpose) code. - Simplify the representation of type-checked constructor initializers in templates; instead of keeping the fully-type-checked AST, which is rather hard to undo at template instantiation time, throw away the type-checked AST and store the raw expressions in the AST. This simplifies instantiation, but loses a little but of information in the AST. - When type-checking implicit base or member initializers within a dependent context, don't add the generated initializers into the AST, because they'll look like they were explicit. - Record in CXXConstructExpr when the constructor call is to initialize a base class, so that CodeGen does not have to infer it from context. This ensures that we call the right kind of constructor. There are also a few "opportunity" fixes here that were needed to not regress, for example: - Diagnose default-initialization of a const-qualified class that does not have a user-declared default constructor. We had this diagnostic specifically for bases and members, but missed it for variables. That's fixed now. - When defining the implicit constructors, destructor, and copy-assignment operator, set the CurContext to that constructor when we're defining the body. llvm-svn: 94952
OpenPOWER on IntegriCloud