summaryrefslogtreecommitdiffstats
path: root/clang/www
Commit message (Collapse)AuthorAgeFilesLines
...
* Retire VS2015 SupportSimon Pilgrim2019-07-091-1/+1
| | | | | | | | | | As proposed here: https://lists.llvm.org/pipermail/llvm-dev/2019-June/133147.html This patch raises the minimum supported version to build LLVM/Clang to Visual Studio 2017. Differential Revision: https://reviews.llvm.org/D64326 llvm-svn: 365454
* [cxx2a] P1236R1: the validity of a left shift does not depend on theRichard Smith2019-06-251-1/+1
| | | | | | value of the LHS operand. llvm-svn: 364265
* P0840R2: support for [[no_unique_address]] attributeRichard Smith2019-06-201-1/+1
| | | | | | | | | | | | | | | | | Summary: Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI. This depends on D63371. Reviewers: rjmccall, aaron.ballman Subscribers: dschuff, aheejin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63451 llvm-svn: 363976
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-141-1/+1
| | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r363337, reverted in r363352. llvm-svn: 363429
* C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue ↵Richard Smith2019-06-141-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | conversion applied to a member access or similar not-quite-trivial lvalue expression. Summary: When a variable is named in a context where we can't directly emit a reference to it (because we don't know for sure that it's going to be defined, or it's from an enclosing function and not captured, or the reference might not "work" for some reason), we emit a copy of the variable as a global and use that for the known-to-be-read-only access. This reinstates r363295, reverted in r363352, with a fix for PR42276: we now produce a proper name for a non-odr-use reference to a static constexpr data member. The name <mangled-name>.const is used in that case; such names are reserved to the implementation for cases such as this and should demangle nicely. Reviewers: rjmccall Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63157 llvm-svn: 363428
* Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.Nico Weber2019-06-141-7/+7
| | | | | | | | Revert 363340 "Remove unused SK_LValueToRValue initialization step." Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type" Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression." llvm-svn: 363352
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-131-1/+1
| | | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r345562, reverted in r346065, now that CodeGen's handling of non-odr-used variables has been fixed. llvm-svn: 363337
* C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue ↵Richard Smith2019-06-131-6/+6
| | | | | | | | | | | | | | | | | | | | | conversion applied to a member access or similar not-quite-trivial lvalue expression. Summary: When a variable is named in a context where we can't directly emit a reference to it (because we don't know for sure that it's going to be defined, or it's from an enclosing function and not captured, or the reference might not "work" for some reason), we emit a copy of the variable as a global and use that for the known-to-be-read-only access. Reviewers: rjmccall Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63157 llvm-svn: 363295
* [Analyzer] Checker for non-determinism caused by iteration of unordered ↵Mandeep Singh Grang2019-05-241-0/+18
| | | | | | | | | | | | | | | | | | container of pointers Summary: Added a checker for non-determinism caused by iterating unordered containers like std::unordered_set containing pointer elements. Reviewers: NoQ, george.karpenkov, whisperity, Szelethus, baloghadamsoftware Reviewed By: Szelethus Subscribers: mgorny, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, jdoerfert, Charusso, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59279 llvm-svn: 361664
* Part of P1091R3: permit structured bindings to be declared 'static' andRichard Smith2019-05-221-1/+1
| | | | | | 'thread_local' in C++20. llvm-svn: 361424
* [c++20] P1330R0: permit simple-assignments that change the active memberRichard Smith2019-05-211-2/+1
| | | | | | of a union within constant expression evaluation. llvm-svn: 361329
* [c++20] P0780R2: Support pack-expansion of init-captures.Richard Smith2019-05-211-1/+1
| | | | | | | | | | | This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-1/+2
| | | | | | | | | class type in constant evaluation. This reinstates r360977, reverted in r360987, now that its rerequisite patch is reinstated and fixed. llvm-svn: 361067
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-1/+1
| | | | | | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) This reinstates r360974, reverted in r360988, with a fix for a static_assert failure on 32-bit builds: force Type base class to have 8-byte alignment like the rest of Clang's AST nodes. llvm-svn: 360995
* Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman2019-05-171-1/+1
| | | | | | | | type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) llvm-svn: 360988
* Revert [c++20] P1327R1: Support for typeid applied to objects of polymorphic ↵Chris Bieneman2019-05-171-2/+1
| | | | | | | | class type in constant evaluation. This reverts r360977 (git commit f51dc8d2f98f4029247552bc45ef53628ab3b6b9) llvm-svn: 360987
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-1/+2
| | | | | | class type in constant evaluation. llvm-svn: 360977
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-1/+1
| | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) llvm-svn: 360974
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-1/+1
| | | | | | | | | | | | | evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
* Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg2019-05-131-1/+1
| | | | | | | | | expression evaluation." This caused Chromium builds to hit the new "can't handle virtual calls with virtual bases" assert. Reduced repro coming up. llvm-svn: 360580
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-1/+1
| | | | | | evaluation. llvm-svn: 360559
* DR1872: don't allow any calls to virtual functions in constantRichard Smith2019-05-091-2/+2
| | | | | | | | evaluation. Not even in cases where we would not actually perform virtual dispatch. llvm-svn: 360370
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-091-1/+1
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [cxx_status] Mark support for std::is_constant_evaluated as done.Richard Smith2019-05-091-1/+1
| | | | | | Eric implemented this in r359067. llvm-svn: 360310
* [cxx_dr_status] Update links to use wg21.link, and list "extension"Richard Smith2019-05-092-2414/+2418
| | | | | | issues as "extension" rather than "not resolved". llvm-svn: 360309
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-063-10/+10
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* [c++20] Implement P1009R2: allow omitting the array bound in an arrayRichard Smith2019-05-061-1/+1
| | | | | | | | | | new expression. This was voted into C++20 as a defect report resolution, so we retroactively apply it to all prior language modes (though it can never actually be used before C++11 mode). llvm-svn: 360006
* [c++20] Implement P0428R2 - Familiar template syntax for generic lambdasHamza Sood2019-05-041-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D36527 llvm-svn: 359967
* [c++20] Implement tweaked __VA_OPT__ rules from P1042R1:Richard Smith2019-05-041-1/+1
| | | | | | | | | | * __VA_OPT__ is expanded if the *expanded* __VA_ARGS__ is non-empty, not if the original argument contained no tokens. * Placemarkers at the start and end of __VA_OPT__ are retained just long enough to paste them with adjacent ## operators. We never paste "across" a discarded placemarker. llvm-svn: 359964
* [cxx_status] Don't list -fmodules / -fmodules-ts against C++ modulesRichard Smith2019-05-041-1/+1
| | | | | | | support; those turn on different modules modes. The real C++ modules support is behind -std=c++2a like the rest of C++20. llvm-svn: 359953
* [cxx_status] Replace "SVN" entries with Clang 8 as appropriate.Richard Smith2019-05-041-11/+11
| | | | | Also: use the "svn" color for "explicit(bool)" rather than the "full" color. llvm-svn: 359951
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-041-1/+1
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* [www] Rebuild cxx_dr_status.Richard Smith2019-04-261-14172/+14232
| | | | llvm-svn: 359261
* Revert r359048: C++ DR2387: a variable template declared wthiIlya Biryukov2019-04-241-14232/+14172
| | | | | | | | | | | | | The change breaks libc++ with the follwing error: In file included from valarray:4: .../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t)) ^ .../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray()) llvm-svn: 359076
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-231-14172/+14232
| | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. llvm-svn: 359048
* [analyzer][www] Moving MoveChecker out of alpha is no longer an open project.Kristof Umann2019-04-221-10/+0
| | | | llvm-svn: 358877
* [analyzer] Move UninitializedObjectChecker out of alphaKristof Umann2019-04-192-114/+113
| | | | | | | | | Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the 'optin.cplusplus' package. Differential Revision: https://reviews.llvm.org/D58573 llvm-svn: 358797
* [Analyzer] Checker for non-determinism caused by sorting of pointer-like ↵Mandeep Singh Grang2019-03-081-0/+23
| | | | | | | | | | | | | | | | | | | | elements Summary: Added a new category of checkers for non-determinism. Added a checker for non-determinism caused due to sorting containers with pointer-like elements. Reviewers: NoQ, george.karpenkov, whisperity, Szelethus Reviewed By: NoQ, Szelethus Subscribers: Charusso, baloghadamsoftware, jdoerfert, donat.nagy, dkrupp, martong, dblaikie, MTC, Szelethus, mgorny, xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D50488 llvm-svn: 355720
* Enable coroutines under -std=c++2a.Richard Smith2019-02-231-1/+1
| | | | llvm-svn: 354736
* [cxx_status] Update to match Kona motions.Richard Smith2019-02-231-8/+59
| | | | llvm-svn: 354735
* [analyzer] Document RetainCountChecker behavior and annotationsGeorge Karpenkov2019-02-051-1/+187
| | | | | | Differential Revision: https://reviews.llvm.org/D57721 llvm-svn: 353229
* Adjust documentation for git migration.James Y Knight2019-01-294-86/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes most references to the paths: llvm.org/svn/ llvm.org/git/ llvm.org/viewvc/ github.com/llvm-mirror/ github.com/llvm-project/ reviews.llvm.org/diffusion/ to instead point to https://github.com/llvm/llvm-project. This is *not* a trivial substitution, because additionally, all the checkout instructions had to be migrated to instruct users on how to use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of checking out various projects into various subdirectories. I've attempted to not change any scripts here, only documentation. The scripts will have to be addressed separately. Additionally, I've deleted one document which appeared to be outdated and unneeded: lldb/docs/building-with-debug-llvm.txt Differential Revision: https://reviews.llvm.org/D57330 llvm-svn: 352514
* [analyzer] Added a checklist to help checker authors and reviewersGabor Horvath2019-01-291-0/+105
| | | | | | Differential Revision: https://reviews.llvm.org/D52984 llvm-svn: 352470
* Mark the lambda function pointer conversion operator as noexcept.Aaron Ballman2019-01-211-1/+1
| | | | | | This implements CWG DR 1722 and fixes PR40309. Patch by Ignat Loskutov. llvm-svn: 351750
* Regenerating the C++ DR status page from the latest Core issues list.Aaron Ballman2019-01-211-14010/+14172
| | | | llvm-svn: 351749
* Implementation Feature Test Macros for P0722R3Chris Kennelly2019-01-111-3/+8
| | | | | | | | | | | | | | | | | Summary: P1353R0, adopted in San Diego, specified an implementation feature test macro for destroying delete (P0722R3). The implementation of the feature (https://reviews.llvm.org/rL315662) is not guarded behind a flag, so the macro is not conditional on language version. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55741 llvm-svn: 350934
* DR674, PR38883, PR40238: Qualified friend lookup should look for aRichard Smith2019-01-071-1/+1
| | | | | | | | | | | | | | | | | | template specialization if there is no matching non-template function. This exposed a couple of related bugs: - we would sometimes substitute into a friend template instead of a suitable non-friend declaration; this would now crash because we'd decide the specialization of the friend is a redeclaration of itself - ADL failed to properly handle the case where an invisible local extern declaration redeclares an invisible friend Both are fixed herein: in particular, we now never make invisible friends or local extern declarations visible to name lookup unless they are the only declaration of the entity. (We already mostly did this for local extern declarations.) llvm-svn: 350505
* Allow direct navigation to static analysis checker documentation through ↵Aaron Ballman2018-12-202-259/+259
| | | | | | | | SARIF exports. This adds anchors to all of the documented checks so that you can directly link to a check by a stable name. This is useful because the SARIF file format has a field for specifying a URI to documentation for a rule and some viewers, like CodeSonar, make use of this information. These links are then exposed through the SARIF exporter. llvm-svn: 349812
OpenPOWER on IntegriCloud