summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/drs
Commit message (Collapse)AuthorAgeFilesLines
...
* DR330: when determining whether a cast casts away constness, considerRichard Smith2018-07-181-0/+22
| | | | | | | | | | | | | | | | qualifiers from all levels matching a multidimensional array. For example, this allows casting from pointer to array of array of const volatile int to pointer to const pointer to volatile pointer to int because the multidimensional array part of the source type corresponds to a part of the destination type that contains both 'const' and 'volatile'. Differential Revision: https://reviews.llvm.org/D49457 llvm-svn: 337422
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-172-0/+105
| | | | | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. This reinstates r337226, reverted in r337255, with a fix for the InitializedEntity alignment problem that was breaking ARM buildbots. llvm-svn: 337329
* Temporarily revert r337226 "Restructure checking for, and warning on, ↵Florian Hahn2018-07-172-105/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | lifetime extension." This change breaks on ARM because pointers to clang::InitializedEntity are only 4 byte aligned and do not have 3 bits to store values. A possible solution would be to change the fields in clang::InitializedEntity to enforce a bigger alignment requirement. The error message is llvm/include/llvm/ADT/PointerIntPair.h:132:3: error: static_assert failed "PointerIntPair with integer size too large for pointer" static_assert(IntBits <= PtrTraits::NumLowBitsAvailable, include/llvm/ADT/PointerIntPair.h:73:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> >' requested here Value = Info::updateInt(Info::updatePointer(0, PtrVal), llvm/include/llvm/ADT/PointerIntPair.h:51:5: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::setPointerAndInt' requested here setPointerAndInt(PtrVal, IntVal); ^ llvm/tools/clang/lib/Sema/SemaInit.cpp:6237:12: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::PointerIntPair' requested here return {Entity, LK_Extended}; Full log here: http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/1330 http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/1394 llvm-svn: 337255
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-172-0/+105
| | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. llvm-svn: 337226
* DR330: look through array types when forming the cv-decomposition of a type.Richard Smith2018-07-111-0/+51
| | | | | | | | | | This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. llvm-svn: 336745
* DR1687: When overload resolution selects a built-in operator, implicitRichard Smith2018-06-272-10/+30
| | | | | | | | | | | conversions are only applied to operands of class type, and the second standard conversion sequence is not applied. When diagnosing an invalid builtin binary operator, talk about the original types rather than the converted types. If these differ by a user-defined conversion, tell the user what happened. llvm-svn: 335781
* DR1213: Ignore implicit conversions when determining if an operand of anRichard Smith2018-06-271-1/+14
| | | | | | | | array subscript expression is an array prvalue. Also apply DR1213 to vector prvalues for consistency. llvm-svn: 335779
* Related to PR37768: improve diagnostics for class name shadowing.Richard Smith2018-06-201-3/+2
| | | | | | | | | | | | Diagnose the name of the class being shadowed by using declarations, and improve the diagnostics for the case where the name of the class is shadowed by a non-static data member in a class with constructors. In the latter case, we now always give the "member with the same name as its class" diagnostic regardless of the relative order of the member and the constructor, rather than giving an inscrutible diagnostic if the constructor appears second. llvm-svn: 335182
* [Sema] Use %sub to cleanup overload diagnosticsEric Fiselier2018-05-301-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds the newly added `%sub` diagnostic modifier to cleanup repetition in the overload candidate diagnostics. I think this should be good to go. @rsmith: Some of the notes now emit `function template` where they only said `function` previously. It seems OK to me, but I would like your sign off on it. Reviewers: rsmith, EricWF Reviewed By: EricWF Subscribers: cfe-commits, rsmith Differential Revision: https://reviews.llvm.org/D47101 llvm-svn: 333485
* Adjust and fix failing CXX tests after r332799Eric Fiselier2018-05-191-1/+1
| | | | llvm-svn: 332800
* Fix regression in r332076.Richard Smith2018-05-141-2/+1
| | | | | | | | | If the name after 'template' is an unresolved using declaration (not containing 'typename'), then we don't yet know if it's a valid template-name, so don't reject it prior to instantiation. Instead, treat it as naming a dependent member of the current instantiation. llvm-svn: 332291
* Improve diagnostics and error recovery for template name lookup.Richard Smith2018-05-112-3/+3
| | | | | | | | | | | | | For 'x::template y', consistently give a "no member named 'y' in 'x'" diagnostic if there is no such member, and give a 'template keyword not followed by a template' name error if there is such a member but it's not a template. In the latter case, add a note pointing at the non-template. Don't suggest inserting a 'template' keyword in 'X::Y<' if X is dependent if the lookup of X::Y was actually not a dependent lookup and found only non-templates. llvm-svn: 332076
* [Sema] Do not match function type with const T in template argument deductionLei Liu2018-05-032-16/+14
| | | | | | | | | | | From http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1584, function type should not match cv-qualified type in template argument deduction. This also matches what GCC and EDG do in template argument deduction. Differential Revision: https://reviews.llvm.org/D45755 llvm-svn: 331424
* Parse A::template B as an identifier rather than as a template-id with noRichard Smith2018-04-272-3/+6
| | | | | | | | | | template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
* DR727: remove wrong assertion for use of class-scope explicitRichard Smith2018-04-231-1/+28
| | | | | | specialization without -fms-extensions. llvm-svn: 330626
* Add a couple more tests for DR372.Richard Smith2018-04-051-0/+19
| | | | llvm-svn: 329352
* DR1672, DR1813, DR1881, DR2120: Implement recent fixes to "standardRichard Smith2018-04-055-2/+85
| | | | | | | | | | | | | | | | | layout" rules. The new rules say that a standard-layout struct has its first non-static data member and all base classes at offset 0, and consider a class to not be standard-layout if that would result in multiple subobjects of a single type having the same address. We track "is C++11 standard-layout class" separately from "is standard-layout class" so that the ABIs that need this information can still use it. Differential Revision: https://reviews.llvm.org/D45176 llvm-svn: 329332
* Implement DR2229, which prohibits unnamed bit-fields from having qualifiers ↵Aaron Ballman2018-03-171-0/+17
| | | | | | in C++. llvm-svn: 327781
* Implement C++ DR727, which permits explicit specializations at class scope.Richard Smith2018-03-163-10/+50
| | | | | | | | | More generally, this permits a template to be specialized in any scope in which it could be defined, so this also supersedes DR44 and DR374 (the latter of which we previously only implemented in C++11 mode onwards due to unclarity as to whether it was a DR). llvm-svn: 327705
* When substituting previously-checked template arguments into a templateRichard Smith2018-03-081-3/+2
| | | | | | | | | | | | | template parameter that is an expanded parameter pack, only substitute into the current slice, not the entire pack. This reduces the checking of N template template arguments for an expanded parameter pack containing N parameters from quadratic time to linear time in the length of the pack. This is important because one (and possibly the only?) general technique for splitting a template parameter pack in linear time depends on doing this. llvm-svn: 326973
* Fix test failure on target where size_t is long long.Richard Smith2018-02-191-3/+6
| | | | llvm-svn: 325540
* [cxx_dr_status] Tests for CWG issues 641-687.Richard Smith2018-02-191-4/+671
| | | | llvm-svn: 325475
* DR126: partially implement the const-correct rules for exception handler ↵Richard Smith2018-01-131-11/+26
| | | | | | | | | matching. While here, fix up the myriad other ways in which Sema's two "can this handler catch that exception?" implementations get things wrong and unify them. llvm-svn: 322431
* Preserve the "last diagnostic was suppressed" flag across SFINAE checks.Richard Smith2017-11-301-0/+3
| | | | | | | | | | | | Sometimes we check the validity of some construct between producing a diagnostic and producing its notes. Ideally, we wouldn't do that, but in practice running code that "cannot possibly produce a diagnostic" in such a situation should be safe, and reasonable factoring of some code requires it with our current diagnostics infrastruture. If this does happen, a diagnostic that's suppressed due to SFINAE should not cause notes connected to the prior diagnostic to be suppressed. llvm-svn: 319408
* The offsetof macro is intended to work with subobjects rather than simple ↵Aaron Ballman2017-11-211-4/+4
| | | | | | identifiers designating a member, making the -Wextended-offsetof diagnostic obsolete as this construct is not an extension. Implements WG14 DR496. llvm-svn: 318796
* DR1113: anonymous namespaces formally give their contents internal linkage.Richard Smith2017-09-221-0/+30
| | | | | | | | | | | | | | | | | | | | This doesn't affect our code generation in any material way -- we already give such declarations internal linkage from a codegen perspective -- but it has some subtle effects on code validity. We suppress the 'L' (internal linkage) marker for mangled names in anonymous namespaces, because it is redundant (the information is already carried by the namespace); this deviates from GCC's behavior if a variable or function in an anonymous namespace is redundantly declared 'static' (where GCC does include the 'L'), but GCC's behavior is incoherent because such a declaration can be validly declared with or without the 'static'. We still deviate from the standard in one regard here: extern "C" declarations in anonymous namespaces are still granted external linkage. Changing those does not appear to have been an intentional consequence of the standard change in DR1113. llvm-svn: 314037
* Replace remaining user-visible mentions of C++1z with C++17.Richard Smith2017-08-136-31/+31
| | | | llvm-svn: 310804
* PR33850: Update cxx_dr_status for Clang 5 branch.Richard Smith2017-08-112-2/+2
| | | | llvm-svn: 310692
* [c++1z] Support deducing B in noexcept(B).Richard Smith2017-06-071-2/+11
| | | | | | | | This is not required by the standard (yet), but there seems to be reasonable support for this being a defect according to CWG discussion, and libstdc++ 7.1 relies on it working. llvm-svn: 304946
* [Sema] Implement Core 2094: Trivial copy/move constructor for class with ↵Eric Fiselier2017-05-092-4/+33
| | | | | | | | | | | | | | | | volatile member Summary: This patch implements http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2094 which reverts Core 496. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D32984 llvm-svn: 302593
* Implement DR 373 "Lookup on namespace qualified name in using-directive"Matthias Gehre2017-03-171-5/+8
| | | | | | | | | | | | | | Summary: 3.4.6 [basic.lookup.udir] paragraph 1: In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered. Reviewers: rsmith, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30848 llvm-svn: 298126
* Print nested name specifiers for typedefs and type aliasesAlex Lorenz2017-03-102-5/+5
| | | | | | | | | | | | Printing typedefs or type aliases using clang_getTypeSpelling() is missing the namespace they are defined in. This is in contrast to other types that always yield the full typename including namespaces. Patch by Michael Reiher! Differential Revision: https://reviews.llvm.org/D29944 llvm-svn: 297465
* C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules ↵Richard Smith2017-02-252-0/+142
| | | | | | | | | | | | | | | | | | | | | | for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
* Fix tracking of whether the previous template instantiation stack matches ↵Richard Smith2017-02-231-3/+1
| | | | | | | | | | | | | | | | | the current one. Rather than attempting to compare whether the previous and current top of context stack are "equal" (which fails for a number of reasons, such as the context stack entries containing pointers to objects on the stack, or reaching the same "top of stack" entry through two different paths), track the depth of context stack at which we last emitted a note and invalidate it when we pop the context stack to less than that depth. This causes us to emit some missing "in instantiation of" notes and to stop emitting redundant "in instantiation of" stacks matching the previous stack in rare cases. llvm-svn: 295921
* Revert r295277 to fix buildbot.Richard Smith2017-02-161-1/+1
| | | | llvm-svn: 295281
* Add missing "deduced A == A" check for function template partial ordering.Richard Smith2017-02-161-1/+1
| | | | | | | | | This appears to be the only template argument deduction context where we were missing this check. Surprisingly, other implementations also appear to miss the check in this case; it may turn out that important code is relying on the widespread non-conformance here, in which case we'll need to reconsider. llvm-svn: 295277
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-261-2/+14
| | | | | | | | | | | | | | | This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
* Finish implementation of C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-202-22/+50
| | | | | | | Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-192-2/+57
| | | | | | | | | | | | | | | | | | | | | | Under this defect resolution, the injected-class-name of a class or class template cannot be used except in very limited circumstances (when declaring a constructor, in a nested-name-specifier, in a base-specifier, or in an elaborated-type-specifier). This is apparently done to make parsing easier, but it's a pain for us since we don't know whether a template-id using the injected-class-name is valid at the point when we annotate it (we don't yet know whether the template-id will become part of an elaborated-type-specifier). As a tentative resolution to a perceived language defect, mem-initializer-ids are added to the list of exceptions here (they generally follow the same rules as base-specifiers). When the reference to the injected-class-name uses the 'typename' or 'template' keywords, we permit it to be used to name a type or template as an extension; other compilers also accept some cases in this area. There are also a couple of corner cases with dependent template names that we do not yet diagnose, but which will also get this treatment. llvm-svn: 292518
* PR9551: Implement DR1004 (http://wg21.link/cwg1004).Richard Smith2017-01-181-0/+23
| | | | | | | | This rule permits the injected-class-name of a class template to be used as both a template type argument and a template template argument, with no extra syntax required to disambiguate. llvm-svn: 292426
* PR31606: Generalize our tentative DR resolution for inheriting copy/moveRichard Smith2017-01-132-9/+12
| | | | | | constructors to better match the pre-P0136R1 behavior. llvm-svn: 291955
* Implement DR1265 (wg21.link/cwg1265).Richard Smith2017-01-132-3/+36
| | | | | | | | | | | | Diasllow a declaration using the 'auto' type specifier from using two different meanings of it at once, or from declaring multiple functions with deduced return types or introducing multiple trailing return types. The standard does not technically disallow the multiple trailing return types case if all the declarators declare variables (such as function pointers with trailing return types), but we disallow that too, following the clear intent. llvm-svn: 291880
* Update C++ status pages for Clang 4 branch:Richard Smith2017-01-1310-13/+13
| | | | | | | | | | | | * Update version number in DR tests from 4.0 to 4 * Teach make_cxx_dr_status script about version numbers that don't contain a period. * Update cxx_status.html and cxx_dr_status.html to list Clang 4 features as "Clang 4" rather than "SVN" Clang 4 features are still listed in yellow rather than green until release. llvm-svn: 291871
* Implement C++ DR1391 (wg21.link/cwg1391)Richard Smith2017-01-091-0/+78
| | | | | | | | | | | | | | Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This re-commits r290808, reverted in r290811 and r291412, with a couple of fixes for handling of explicitly-specified non-trailing template argument packs. llvm-svn: 291427
* Implement DR1388 (wg21.link/cwg1388).Richard Smith2017-01-091-0/+52
| | | | | | | | | | | | This issue clarifies how deduction proceeds past a non-trailing function parameter pack. Essentially, the pack itself is skipped and consumes no arguments (except for those implied by an explicitly-specified template arguments), and nothing is deduced from it. As a small fix to the standard's rule, we do not allow subsequent deduction to change the length of the function parameter pack (by preventing extension of the explicitly-specified pack if present, and otherwise deducing all contained packs to empty packs). llvm-svn: 291425
* Revert r291410 and r291411.Richard Smith2017-01-091-78/+0
| | | | | | The test-suite bots are still failing even after r291410's fix. llvm-svn: 291412
* Implement C++ DR1391 (wg21.link/cwg1391)Richard Smith2017-01-091-0/+78
| | | | | | | | | | | | | Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This re-commits r290808, reverted in r290811, with a fix for handling of explicitly-specified template argument packs. llvm-svn: 291410
* PR30305: Implement proposed DR resolution to prevent slicing via inherited ↵Richard Smith2017-01-081-4/+5
| | | | | | | | | | | | constructor. The rule we use is that a construction of a class type T from an argument of type U cannot use an inherited constructor if U is the same as T or is derived from T (or if the initialization would first convert it to such a type). This (approximately) matches the rule in use by GCC, and matches the current proposed DR resolution. llvm-svn: 291403
* Revert "DR1391: Check for implicit conversion sequences for non-dependent ↵Renato Golin2017-01-021-78/+0
| | | | | | | | | | | | | | function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation." This reverts commit r290808, as it broken all ARM and AArch64 test-suite test: MultiSource/UnitTests/C++11/frame_layout Also, please, next time, try to write a commit message in according to our guidelines: http://llvm.org/docs/DeveloperPolicy.html#commit-messages llvm-svn: 290811
* DR1391: Check for implicit conversion sequences for non-dependent functionRichard Smith2017-01-021-0/+78
| | | | | | | | | | | | template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This does not implement the partial ordering portion of DR1391, which so far appears to be misguided. llvm-svn: 290808
OpenPOWER on IntegriCloud