summaryrefslogtreecommitdiffstats
path: root/include/clang/Basic/DiagnosticASTKinds.td
Commit message (Collapse)AuthorAgeFilesLines
* [Modules] Implement ODR-like semantics for tag types in C/ObjCBruno Cardoso Lopes2017-07-011-3/+8
| | | | | | | | | | | | | | | | | | | | | | Allow ODR for ObjC/C in the sense that we won't keep more that one definition around (merge them). However, ensure the decl pass the structural compatibility check in C11 6.2.7/1, for that, reuse the structural equivalence checks used by the ASTImporter. Few other considerations: - Create error diagnostics for tag types mismatches and thread them into the structural equivalence checks. - Note that by doing this we only support redefinition between types that are considered "compatible types" by C. This is mixed approach of the suggestions discussed in http://lists.llvm.org/pipermail/cfe-dev/2017-March/053257.html Differential Revision: https://reviews.llvm.org/D31778 rdar://problem/31909368 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306918 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r301822 (and dependent r301825), which tried to improve theDaniel Jasper2017-05-021-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | handling of constexprs with unknown bounds. This triggers a corner case of the language where it's not yet clear whether this should be an error: struct A { static void *const a[]; static void *const b[]; }; constexpr void *A::a[] = {&b[0]}; constexpr void *A::b[] = {&a[0]}; When discovering the initializer for A::a, the bounds of A::b aren't known yet. It is unclear whether warning about errors should be deferred until the end of the translation unit, possibly resolving errors that can be resolved. In practice, the compiler can know the bounds of all arrays in this example. Credits for reproducers and explanation go to Richard Smith. Richard, please add more info in case my explanation is wrong. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301963 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve handling of arrays of unknown bound in constant expressions.Richard Smith2017-05-011-1/+3
| | | | | | | | | | | | | | | Do not spuriously reject constexpr functions that access elements of an array of unknown bound; this may later become valid once the bound is known. Permit array-to-pointer decay on such arrays, but disallow pointer arithmetic (since we do not know whether it will have defined behavior). The standard is not clear on how this should work, but this seems to be a decent answer. Patch by Robert Haberlach! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301822 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve fix for PR28739Richard Smith2017-01-311-1/+2
| | | | | | | | | | | | | | | | Don't try to map an APSInt addend to an int64_t in pointer arithmetic before bounds-checking it. This gives more consistent behavior (outside C++11, we consistently use 2s complement semantics for both pointer and integer overflow in constant expressions) and fixes some cases where in C++11 we would fail to properly check for out-of-bounds pointer arithmetic (if the 2s complement 64-bit overflow landed us back in-bounds). In passing, also fix some cases where we'd perform possibly-overflowing arithmetic on CharUnits (which have a signed underlying type) during constant expression evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293595 91177308-0d34-0410-b5e6-96231b3b80d8
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274049 91177308-0d34-0410-b5e6-96231b3b80d8
* [Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier ↵Faisal Vali2016-03-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264513 91177308-0d34-0410-b5e6-96231b3b80d8
* [MS ABI] Detect and diagnose vftables which cannot be createdDavid Majnemer2015-05-011-0/+8
| | | | | | | | | | | | | | | | The MSVC ABI has a bug introduced by appending to the end of vftables which come from virtual bases: covariant thunks introduces via non-overlapping regions of the inheritance lattice both append to the same slot in the vftable. It is possible to generate correct vftables in cases where one node in the lattice completely dominates the other on the way to the base with the vfptr; in all other cases, we must raise a diagnostic in order to prevent the illusion that we succeeded in laying out the vftable. This fixes PR16759. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236354 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr evaluation for __builtin_assume_alignedHal Finkel2014-10-031-0/+7
| | | | | | | | | | | | | | | | | Richard noted in the review of r217349 that extra handling of __builtin_assume_aligned inside of the expression evaluator was needed. He was right, and this should address the concerns raised, namely: 1. The offset argument to __builtin_assume_aligned can have side effects, and we need to make sure that all arguments are properly evaluated. 2. If the alignment assumption does not hold, that introduces undefined behavior, and undefined behavior cannot appear inside a constexpr. and hopefully the diagnostics produced are detailed enough to explain what is going on. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218992 91177308-0d34-0410-b5e6-96231b3b80d8
* Add an explicit diagnostic for the case where an expression is not a constantRichard Smith2014-07-071-0/+4
| | | | | | | expression because it uses 'this'. Inspired by PR20219 comment#2. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212433 91177308-0d34-0410-b5e6-96231b3b80d8
* PR5683: Issue a warning when subtracting pointers to types of zero size, andRichard Smith2013-09-101-0/+2
| | | | | | | | treat such subtractions as being non-constant. Patch by Serge Pavlov! With a few tweaks by me. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190439 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y: track object lifetime during constexpr evaluation, and don't allowRichard Smith2013-07-241-0/+3
| | | | | | | | objects to be used once their lifetimes end. This completes the C++1y constexpr extensions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187025 91177308-0d34-0410-b5e6-96231b3b80d8
* PR16377: Allow evaluation of statement expressions in constant evaluation,Richard Smith2013-06-201-1/+4
| | | | | | | why not. Apparently GCC supports this. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184396 91177308-0d34-0410-b5e6-96231b3b80d8
* PR14503: Don't assert if a constexpr constructor temploid instantiates to aRichard Smith2013-06-181-0/+2
| | | | | | | | constructor that does not initialize all members, and that constructor is used to initialize a global. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184211 91177308-0d34-0410-b5e6-96231b3b80d8
* Model temporary lifetime-extension explicitly in the AST. Use this model toRichard Smith2013-06-051-0/+4
| | | | | | | | | | handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183283 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y: Add a step limit to constexpr evaluation, to catch runaway loops.Richard Smith2013-05-081-0/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181388 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y: support for increment and decrement in constant expression evaluation.Richard Smith2013-05-051-13/+13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181173 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y: support simple variable assignments in constexpr functions.Richard Smith2013-04-261-13/+27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180603 91177308-0d34-0410-b5e6-96231b3b80d8
* C++1y constexpr extensions, round 1: Allow most forms of declaration andRichard Smith2013-04-221-0/+2
| | | | | | | | | statement in constexpr functions. Everything which doesn't require variable mutation is also allowed as an extension in C++11. 'void' becomes a literal type to support constexpr functions which return 'void'. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180022 91177308-0d34-0410-b5e6-96231b3b80d8
* Add space after ';'.Fariborz Jahanian2013-01-251-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173462 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve diagnsotic further on integer overflow.Fariborz Jahanian2013-01-251-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173461 91177308-0d34-0410-b5e6-96231b3b80d8
* Fixes text of diagnostics in integer overflow patch.Fariborz Jahanian2013-01-241-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173388 91177308-0d34-0410-b5e6-96231b3b80d8
* Patch to check for integer overflow. It has beenFariborz Jahanian2013-01-241-0/+3
| | | | | | | commented on and approved by Richard Smith. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173377 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix code that attempted to produce a diagnostic with one DiagnosticEngine, thenRichard Smith2012-12-201-1/+2
| | | | | | | | | produce a note for that diagnostic either with a different DiagnosticEngine or after calling DiagnosticEngine::Reset(). That didn't make any sense, and did the wrong thing if the original diagnostic was suppressed. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170636 91177308-0d34-0410-b5e6-96231b3b80d8
* Normalize line endings of r163013 (part 2).Joao Matos2012-08-311-7/+7
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163032 91177308-0d34-0410-b5e6-96231b3b80d8
* Improved MSVC __interface support by adding first class support for it, ↵Joao Matos2012-08-311-7/+7
| | | | | | instead of aliasing to "struct" which had some incorrect behaviour. Patch by David Robins. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163013 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove hacky temporary fix of r151585.Argyrios Kyrtzidis2012-03-151-5/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152818 91177308-0d34-0410-b5e6-96231b3b80d8
* When evaluating integer expressions include a check for sub-expressionsArgyrios Kyrtzidis2012-02-271-0/+5
| | | | | | | | depth and error if we exceed a max value, to make sure we avoid a stack overflow. This is a hacky temporary fix. rdar://10913206. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151585 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement constant expression support for __real__ and __imag__ on lvalueRichard Smith2012-02-181-2/+4
| | | | | | | | | | | | | | | | complex numbers. Treat complex numbers as arrays of the corresponding component type, in order to make std::complex behave properly if implemented in terms of _Complex T. Apparently libstdc++'s std::complex is implemented this way, and we were rejecting a member like this: constexpr double real() { return __real__ val; } because it was marked constexpr but unable to produce a constant expression. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150895 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr tidyups:Richard Smith2012-02-161-0/+3
| | | | | | | | | * Fix bug when determining whether && / || are potential constant expressions * Try harder when determining whether ?: is a potential constant expression * Produce a diagnostic on sizeof(VLA) to provide a better source location git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150657 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement DR1454. This allows all intermediate results in constant expressionsRichard Smith2012-02-151-3/+5
| | | | | | | | | | | | | to be core constant expressions (including pointers and references to temporaries), and makes constexpr calculations Turing-complete. A Turing machine simulator is included as a testcase. This opens up the possibilty of removing CCValue entirely, and removing some copies from the constant evaluator in the process, but that cleanup is not part of this change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150557 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unused diagnostics from include/clang/Basic/Diagnostic*.td files.Dmitri Gribenko2012-02-131-6/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150409 91177308-0d34-0410-b5e6-96231b3b80d8
* Update constexpr implementation to match CWG's chosen approach for core issuesRichard Smith2012-02-131-0/+5
| | | | | | | | | | | | | | | | | | | | | 1358, 1360, 1452 and 1453. - Instantiations of constexpr functions are always constexpr. This removes the need for separate declaration/definition checking, which is now gone. - This makes it possible for a constexpr function to be virtual, if they are only dependently virtual. Virtual calls to such functions are not constant expressions. - Likewise, it's now possible for a literal type to have virtual base classes. A constexpr constructor for such a type cannot actually produce a constant expression, though, so add a special-case diagnostic for a constructor call to such a type rather than trying to evaluate it. - Classes with trivial default constructors (for which value initialization can produce a fully-initialized value) are considered literal types. - Classes with volatile members are not literal types. - constexpr constructors can be members of non-literal types. We do not yet use static initialization for global objects constructed in this way. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150359 91177308-0d34-0410-b5e6-96231b3b80d8
* Update to new resolution for DR1458. When taking the address of an object ofRichard Smith2012-02-101-3/+0
| | | | | | | | incomplete class type which has an overloaded operator&, it's now just unspecified whether the overloaded operator or the builtin is used. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150234 91177308-0d34-0410-b5e6-96231b3b80d8
* CWG issue 1405: mutable members are allowed in literal types, but can't undergoRichard Smith2012-02-091-0/+2
| | | | | | | lvalue-to-rvalue conversions in constant expressions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150145 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement DR1458: Taking the address of an object of incomplete class type isRichard Smith2012-02-081-0/+3
| | | | | | | | not a constant expression, because we can't tell whether the complete class type will have an overloaded operator&. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150066 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement the agreed resolution to DR1457: a signed left shift of a 1 bit intoRichard Smith2012-02-081-0/+1
| | | | | | | | | | | the sign bit doesn't have undefined behavior, but a signed left shift of a 1 bit out of the sign bit still does. As promised to Howard :) The suppression of the potential constant expression checking in system headers is also removed, since the problem it was working around is gone. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150059 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr:Richard Smith2012-02-021-0/+11
| | | | | | | | * support the gcc __builtin_constant_p() ? ... : ... folding hack in C++11 * check for unspecified values in pointer comparisons and pointer subtractions git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149578 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr: overflow checking for integral and floating-point arithmetic.Richard Smith2012-02-011-0/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149473 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr: require 'this' to point to an object in a constexpr method call.Richard Smith2012-02-011-2/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149467 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr: add support for comparisons of pointer-to-members.Richard Smith2012-02-011-0/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149463 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr: the result of a relational operator between pointers to void isRichard Smith2012-01-311-0/+2
| | | | | | | | unspecified unless the pointers are equal; therefore, such a comparison is not a constant expression unless the pointers are equal. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149366 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr: catch a collection of integral undefined behaviors:Richard Smith2012-01-311-0/+4
| | | | | | | | | | | -INT_MIN and INT_MIN / -1 Shift by a negative or too large quantity Left shift of negative value Overflow in left shift git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149344 91177308-0d34-0410-b5e6-96231b3b80d8
* C++11 generalized constant expressions: implement checking and diagnostics forRichard Smith2012-01-061-1/+14
| | | | | | | | pointer-arithmetic-related undefined behavior and unspecified results. We continue to fold such values, but now notice they aren't constant expressions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147659 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr: support for evaluation and codegen of typeid constants.Richard Smith2011-12-271-0/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147290 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr: diagnostic improvements for invalid lvalue-to-rvalue conversions inRichard Smith2011-12-211-0/+19
| | | | | | | constant expressions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147035 91177308-0d34-0410-b5e6-96231b3b80d8
* constexpr handling improvements. Produce detailed diagnostics when a 'constexpr'Richard Smith2011-12-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | variable is initialized by a non-constant expression, and pass in the variable being declared so that earlier-initialized fields' values can be used. Rearrange VarDecl init evaluation to make this possible, and in so doing fix a long-standing issue in our C++ constant expression handling, where we would mishandle cases like: extern const int a; const int n = a; const int a = 5; int arr[n]; Here, n is not initialized by a constant expression, so can't be used in an ICE, even though the initialization expression would be an ICE if it appeared later in the TU. This requires computing whether the initializer is an ICE eagerly, and saving that information in PCH files. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146856 91177308-0d34-0410-b5e6-96231b3b80d8
* C++11 constexpr: Add note stacks containing backtraces if constant evaluationRichard Smith2011-12-161-0/+4
| | | | | | | | | | | fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit argument to driver and frontend, to control the maximum number of notes so produced (default 10). Fix APValue printing to be able to pretty-print all APValue types, and move the testing for this functionality from a unittest to a -verify test now that it's visible in clang's output. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146749 91177308-0d34-0410-b5e6-96231b3b80d8
* Add checks and diagnostics for many of the cases which C++11 considers to notRichard Smith2011-12-131-0/+18
| | | | | | | be constant expressions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146479 91177308-0d34-0410-b5e6-96231b3b80d8
* Further tweaking of diagnostic text for casts performing reinterpret_castRichard Smith2011-12-121-2/+2
| | | | | | | conversions in constant expressions. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146406 91177308-0d34-0410-b5e6-96231b3b80d8
* Clean up diagnostic wording for disallowed casts in C++11 constant expressions.Richard Smith2011-12-121-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146395 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-11 15:13:34 +0000