aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Parse/ParseStmt.cpp
AgeCommit message (Collapse)AuthorFilesLines
2024-04-16[clang] Introduce `SemaOpenMP` (#88642)Vlad Serebrennikov1-1/+2
This patch moves OpenMP-related entities out of `Sema` to a newly created `SemaOpenMP` class. This is a part of the effort to split `Sema` up, and follows the recent example of CUDA, OpenACC, SYCL, HLSL. Additional context can be found in https://github.com/llvm/llvm-project/pull/82217, https://github.com/llvm/llvm-project/pull/84184, https://github.com/llvm/llvm-project/pull/87634.
2024-01-30[Clang] Implement P2718R0 "Lifetime extension in range-based for loops" (#76361)yronglin1-4/+4
Implement P2718R0 "Lifetime extension in range-based for loops" (https://wg21.link/P2718R0) Differential Revision: https://reviews.llvm.org/D153701 --------- Signed-off-by: yronglin <yronglin777@gmail.com>
2023-12-11[clang] Add support for -fcx-limited-range, #pragma CX_LIMITED_RANGE and ↵Zahira Ammarguellat1-0/+11
-fcx-fortran-rules. (#70244) This patch adds the #pragma CX_LIMITED_RANGE defined in the C specification. It also adds the options -f[no]cx-limited-range and -f[no]cx-fortran-rules. -fcx-limited-range enables algebraic formulas for complex multiplication and division. This option is enabled with -ffast-math. -fcx-fortran-rules enables algebraic formulas for complex multiplication and enables Smith’s algorithm for complex division (SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962)). --------- Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> Co-authored-by: Joseph Huber <jhuber6@vols.utk.edu> Co-authored-by: Guray Ozen <guray.ozen@gmail.com> Co-authored-by: Nishant Patel <nishant.b.patel@intel.com> Co-authored-by: Jessica Clarke <jrtc27@jrtc27.com> Co-authored-by: Petr Hosek <phosek@google.com> Co-authored-by: Joseph Huber <35342157+jhuber6@users.noreply.github.com> Co-authored-by: Craig Topper <craig.topper@sifive.com> Co-authored-by: Alexander Yermolovich <43973793+ayermolo@users.noreply.github.com> Co-authored-by: Usama Hameed <u_hameed@apple.com> Co-authored-by: Philip Reames <preames@rivosinc.com> Co-authored-by: Evgenii Kudriashov <evgenii.kudriashov@intel.com> Co-authored-by: Fangrui Song <i@maskray.me> Co-authored-by: Aart Bik <39774503+aartbik@users.noreply.github.com> Co-authored-by: Valentin Clement <clementval@gmail.com> Co-authored-by: Youngsuk Kim <youngsuk.kim@hpe.com> Co-authored-by: Arthur Eubanks <aeubanks@google.com> Co-authored-by: Jan Svoboda <jan_svoboda@apple.com> Co-authored-by: Walter Erquinigo <a20012251@gmail.com> Co-authored-by: Eric <eric@efcs.ca> Co-authored-by: Fazlay Rabbi <106703039+mdfazlay@users.noreply.github.com> Co-authored-by: Pete Lawrence <plawrence@apple.com> Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com> Co-authored-by: Adrian Prantl <aprantl@apple.com> Co-authored-by: Owen Pan <owenpiano@gmail.com> Co-authored-by: LLVM GN Syncbot <llvmgnsyncbot@gmail.com> Co-authored-by: Med Ismail Bennani <ismail@bennani.ma> Co-authored-by: Congcong Cai <congcongcai0907@163.com> Co-authored-by: Rik Huijzer <github@huijzer.xyz> Co-authored-by: Wang Pengcheng <wangpengcheng.pp@bytedance.com> Co-authored-by: Yuanfang Chen <tabloid.adroit@gmail.com> Co-authored-by: Kazu Hirata <kazu@google.com> Co-authored-by: Mehdi Amini <joker.eph@gmail.com> Co-authored-by: Aiden Grossman <agrossman154@yahoo.com> Co-authored-by: Rana Pratap Reddy <109514914+ranapratap55@users.noreply.github.com> Co-authored-by: Yingwei Zheng <dtcxzyw2333@gmail.com> Co-authored-by: Piotr Zegar <me@piotrzegar.pl> Co-authored-by: KAWASHIMA Takahiro <t-kawashima@fujitsu.com> Co-authored-by: Tobias Hieta <tobias@hieta.se> Co-authored-by: Luke Lau <luke@igalia.com> Co-authored-by: Shivam Gupta <shivam98.tkg@gmail.com> Co-authored-by: cor3ntin <corentinjabot@gmail.com> Co-authored-by: Yeting Kuo <46629943+yetingk@users.noreply.github.com> Co-authored-by: Stanislav Mekhanoshin <rampitec@users.noreply.github.com> Co-authored-by: David Spickett <david.spickett@linaro.org> Co-authored-by: Matthew Devereau <matthew.devereau@arm.com> Co-authored-by: Martin Storsjö <martin@martin.st> Co-authored-by: Qiu Chaofan <qiucofan@cn.ibm.com> Co-authored-by: Pierre van Houtryve <pierre.vanhoutryve@amd.com> Co-authored-by: Mikael Holmen <mikael.holmen@ericsson.com> Co-authored-by: Uday Bondhugula <uday@polymagelabs.com> Co-authored-by: Nikita Popov <npopov@redhat.com> Co-authored-by: Johannes Reifferscheid <jreiffers@google.com> Co-authored-by: Benjamin Kramer <benny.kra@googlemail.com> Co-authored-by: Oliver Stannard <oliver.stannard@arm.com> Co-authored-by: Dmitry Vyukov <dvyukov@google.com> Co-authored-by: Benjamin Maxwell <benjamin.maxwell@arm.com> Co-authored-by: Piotr Sobczak <piotr.sobczak@amd.com> Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk> Co-authored-by: Timm Bäder <tbaeder@redhat.com> Co-authored-by: Sunil Kuravinakop <koops@hpe.com> Co-authored-by: zhongyunde 00443407 <zhongyunde@huawei.com> Co-authored-by: Christudasan Devadasan <Christudasan.Devadasan@amd.com> Co-authored-by: bjacob <jacob.benoit.1@gmail.com> Co-authored-by: Weining Lu <luweining@loongson.cn> Co-authored-by: Andrzej Warzyński <andrzej.warzynski@arm.com> Co-authored-by: Jay Foad <jay.foad@amd.com> Co-authored-by: Markus Mützel <markus.muetzel@gmx.de> Co-authored-by: Erik Jonsson <erik.j.jonsson@ericsson.com> Co-authored-by: Pete Steinfeld <47540744+psteinfeld@users.noreply.github.com> Co-authored-by: Alexey Bataev <a.bataev@outlook.com> Co-authored-by: Louis Dionne <ldionne.2@gmail.com> Co-authored-by: Qizhi Hu <836744285@qq.com>
2023-11-20[C23] Complete support for WG14 N2508 (#71398)Aaron Ballman1-13/+29
In Clang 16, we implemented the ability to add a label at the end of a compound statement. These changes complete the implementation by allowing a label to be followed by a declaration in C. Note, this seems to have fixed an issue with some OpenMP stand-alone directives not being properly diagnosed as per: https://www.openmp.org/spec-html/5.1/openmpsu19.html#x34-330002.1.3 (The same requirement exists in OpenMP 5.2 as well.)
2023-11-17[OpenACC] Initial commits to support OpenACC (#70234)Erich Keane1-0/+3
Initial commits to support OpenACC. This patchset: adds a clang-command line argument '-fopenacc', and starts to define _OPENACC, albeit to '1' instead of the standardized value (since we don't properly implement OpenACC yet). The OpenACC spec defines `_OPENACC` to be equal to the latest standard implemented. However, since we're not done implementing any standard, we've defined this by default to be `1`. As it is useful to run our compiler against existing OpenACC workloads, we're providing a temporary override flag to change the `_OPENACC` value to be any entirely digit value, permitting testing against any existing OpenACC project. Exactly like the OpenMP parser, the OpenACC pragma parser needs to consume and reprocess the tokens. This patch sets up the infrastructure to do so by refactoring the OpenMP version of this into a more general version that works for OpenACC as well. Additionally, this adds a few diagnostics and token kinds to get us started.
2023-09-27Revert "[clang][SemaCXX] Diagnose tautological uses of consteval if and ↵Sam McCall1-19/+9
is_constant_evaluated" This reverts commit 491b2810fb7fe5f080fa9c4f5945ed0a6909dc92. This change broke valid code and generated incorrect diagnostics, see https://reviews.llvm.org/D155064
2023-09-27[clang][SemaCXX] Diagnose tautological uses of consteval if and ↵Takuya Shimizu1-9/+19
is_constant_evaluated This patch makes clang diagnose extensive cases of consteval if and is_constant_evaluated usage that are tautologically true or false. This introduces a new IsRuntimeEvaluated boolean flag to Sema::ExpressionEvaluationContextRecord that means the immediate appearance of if consteval or is_constant_evaluated are tautologically false(e.g. inside if !consteval {} block or non-constexpr-qualified function definition body) This patch also pushes new expression evaluation context when parsing the condition of if constexpr and initializer of constexpr variables so that Sema can be aware that the use of consteval if and is_consteval are tautologically true in if constexpr condition and constexpr variable initializers. BEFORE this patch, the warning for is_constant_evaluated was emitted from constant evaluator. This patch moves the warning logic to Sema in order to diagnose tautological use of is_constant_evaluated in the same way as consteval if. This patch separates initializer evaluation context from InitializerScopeRAII. This fixes a bug that was happening when user takes address of function address in initializers of non-local variables. Fixes https://github.com/llvm/llvm-project/issues/43760 Fixes https://github.com/llvm/llvm-project/issues/51567 Reviewed By: cor3ntin, ldionne Differential Revision: https://reviews.llvm.org/D155064
2023-09-14[NFC] Minimize header includes (#66339)Bill Wendling1-0/+1
Minimize the headers included in header files to reduce the number of files that need recompiled after a change.
2023-09-09[Clang] Fix the for statement disappearing in AST when an error occurs in ↵yronglin1-2/+17
the conditional expression of the for statement (#65381) Consider: ``` constexpr int f() { int sum = 0; for (int i = 0; undefined_var; ++i) { sum += i; } return sum; } static_assert(f()); ``` The AST before this patch: ``` |-FunctionDecl <line:1:1, line:7:1> line:1:15 used constexpr f 'int ()' implicit-inline | `-CompoundStmt <col:19, line:7:1> | |-DeclStmt <line:2:5, col:16> | | `-VarDecl <col:5, col:15> col:9 used sum 'int' cinit | | `-IntegerLiteral <col:15> 'int' 0 | `-ReturnStmt <line:6:5, col:12> | `-ImplicitCastExpr <col:12> 'int' <LValueToRValue> | `-DeclRefExpr <col:12> 'int' lvalue Var 0xb870518 'sum' 'int' ``` The AST after this patch: ``` |-FunctionDecl 0x11d0f63f8 <./main.cpp:1:1, line:7:1> line:1:15 used constexpr f 'int ()' implicit-inline | `-CompoundStmt 0x11d110880 <col:19, line:7:1> | |-DeclStmt 0x11d0f65c8 <line:2:5, col:16> | | `-VarDecl 0x11d0f6528 <col:5, col:15> col:9 used sum 'int' cinit | | `-IntegerLiteral 0x11d0f6590 <col:15> 'int' 0 | |-ForStmt 0x11d110800 <line:3:5, line:5:5> | | |-DeclStmt 0x11d0f66a0 <line:3:10, col:19> | | | `-VarDecl 0x11d0f6600 <col:10, col:18> col:14 used i 'int' cinit | | | `-IntegerLiteral 0x11d0f6668 <col:18> 'int' 0 | | |-<<<NULL>>> | | |-RecoveryExpr 0x11d0f66e8 <col:21> 'bool' contains-errors | | |-UnaryOperator 0x11d0f6728 <col:36, col:38> 'int' lvalue prefix '++' | | | `-DeclRefExpr 0x11d0f6708 <col:38> 'int' lvalue Var 0x11d0f6600 'i' 'int' | | `-CompoundStmt 0x11d0f67c8 <col:41, line:5:5> | | `-CompoundAssignOperator 0x11d0f6798 <line:4:9, col:16> 'int' lvalue '+=' ComputeLHSTy='int' ComputeResultTy='int' | | |-DeclRefExpr 0x11d0f6740 <col:9> 'int' lvalue Var 0x11d0f6528 'sum' 'int' | | `-ImplicitCastExpr 0x11d0f6780 <col:16> 'int' <LValueToRValue> | | `-DeclRefExpr 0x11d0f6760 <col:16> 'int' lvalue Var 0x11d0f6600 'i' 'int' | `-ReturnStmt 0x11d110870 <line:6:5, col:12> | `-ImplicitCastExpr 0x11d110858 <col:12> 'int' <LValueToRValue> | `-DeclRefExpr 0x11d110838 <col:12> 'int' lvalue Var 0x11d0f6528 'sum' 'int' ``` --------- Co-authored-by: Shafik Yaghmour <shafik@users.noreply.github.com>
2023-08-11[C23] Rename C2x->C23 in diagnosticsAaron Ballman1-1/+1
This renames C2x to C23 in diagnostic identifiers and messages. The changes were made mechanically.
2023-08-11[C23] Rename C2x -> C23; NFCAaron Ballman1-1/+1
This does the rename for most internal uses of C2x, but does not rename or reword diagnostics (those will be done in a follow-up). I also updated standards references and citations to the final wording in the standard.
2023-08-08[Clang] Fix the do while statement disappearing in AST when an error occurs ↵yrong1-1/+2
in the conditional expression of the do while statement ``` constexpr int test() { do {} while (a + 1 < 10); return 0; } ``` Before: ``` `-FunctionDecl 0x56512a172650 <./recovery.cpp:1:1, line:4:1> line:1:15 constexpr test 'int ()' implicit-inline `-CompoundStmt 0x56512a172860 <col:22, line:4:1> `-ReturnStmt 0x56512a172850 <line:3:5, col:12> `-IntegerLiteral 0x56512a172830 <col:12> 'int' 0 ``` Now: ``` `-FunctionDecl 0x5642c4804650 <./recovery.cpp:1:1, line:4:1> line:1:15 constexpr test 'int ()' implicit-inline `-CompoundStmt 0x5642c48048e0 <col:22, line:4:1> |-DoStmt 0x5642c4804890 <line:2:5, col:28> | |-CompoundStmt 0x5642c4804740 <col:8, col:9> | `-BinaryOperator 0x5642c4804870 <col:18, col:26> '<dependent type>' contains-errors '<' | |-BinaryOperator 0x5642c4804850 <col:18, col:22> '<dependent type>' contains-errors '+' | | |-RecoveryExpr 0x5642c4804830 <col:18> '<dependent type>' contains-errors lvalue | | `-IntegerLiteral 0x5642c48047b0 <col:22> 'int' 1 | `-IntegerLiteral 0x5642c48047f0 <col:26> 'int' 10 `-ReturnStmt 0x5642c48048d0 <line:3:5, col:12> `-IntegerLiteral 0x5642c48048b0 <col:12> 'int' 0 ``` Reviewed By: hokein Differential Revision: https://reviews.llvm.org/D157195
2023-07-05[Clang] Fix handling of using declarations in for loop init statements.Corentin Jabot1-2/+2
The type was never saved, and therefore never transformed in dependent contexts. Reviewed By: aaron.ballman, #clang-language-wg Differential Revision: https://reviews.llvm.org/D154492
2023-06-10[clang][parse][NFC] Fix grammar in a commentTimm Bäder1-2/+2
2023-06-07[clang] Fix assertion while parsing an invalid for loopCorentin Jabot1-3/+1
with multiple declarations followed by a colon. Fixes #63010 Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D152009
2023-05-31[clang] Add Parse and Sema support for RegularKeyword attributesRichard Sandiford1-1/+6
This patch adds the Parse and Sema support for RegularKeyword attributes, following on from a previous patch that added Attr.td support. The patch is quite large. However, nothing outside the tests is specific to the first RegularKeyword attribute (__arm_streaming). The patch should therefore be a one-off, up-front cost. Other attributes just need an entry in Attr.td and the usual Sema support. The approach taken in the patch is that the keywords can be used with any language version. If standard attributes were added in language version Y, the keyword rules for version X<Y are the same as they were for version Y (to the extent possible). Any extensions beyond Y are handled in the same way for both keywords and attributes. This ensures that existing C++11 successors like C++17 are not treated differently from versions that have yet to be defined. Some notes on the implementation: * The patch emits errors rather than warnings for diagnostics that relate to keywords. * Where possible, the patch drops “attribute” from diagnostics relating to keywords. * One exception to the previous point is that warnings about C++ extensions do still mention attributes. The use there seemed OK since the diagnostics are noting a change in the production rules. * If a diagnostic string needs to be different for keywords and attributes, the patch standardizes on passing the attribute/ name/token followed by 0 for attributes and 1 for keywords. * Although the patch updates warn_attribute_wrong_decl_type_str, warn_attribute_wrong_decl_type, and warn_attribute_wrong_decl_type, only the error forms of these strings are used for keywords. * I couldn't trigger the warnings in checkUnusedDeclAttributes, even for existing attributes. An assert on the warnings caused no failures in the testsuite. I think in practice all standard attributes would be diagnosed before this. * The patch drops a call to standardAttributesAllowed in ParseFunctionDeclarator. This is because MaybeParseCXX11Attributes checks the same thing itself, where appropriate. * The new tests are based on c2x-attributes.c and cxx0x-attributes.cpp. The C++ test also incorporates a version of cxx11-base-spec-attributes.cpp. The FIXMEs are carried across from the originals. Differential Revision: https://reviews.llvm.org/D148702
2023-05-16[clang] Add a new annotation token: annot_repl_input_endJun Zhang1-3/+16
This patch is the first part of the below RFC: https://discourse.llvm.org/t/rfc-handle-execution-results-in-clang-repl/68493 It adds an annotation token which will replace the original EOF token when we are in the incremental C++ mode. In addition, when we're parsing an ExprStmt and there's a missing semicolon after the expression, we set a marker in the annotation token and continue parsing. Eventually, we propogate this info in ParseTopLevelStmtDecl and are able to mark this Decl as something we want to do value printing. Below is a example: clang-repl> int x = 42; clang-repl> x // `x` is a TopLevelStmtDecl and without a semicolon, we should set // it's IsSemiMissing bit so we can do something interesting in // ASTConsumer::HandleTopLevelDecl. The idea about annotation toke is proposed by Richard Smith, thanks! Signed-off-by: Jun Zhang <jun@junz.org> Differential Revision: https://reviews.llvm.org/D148997
2023-05-04[clang] Use -std=c++23 instead of -std=c++2bMark de Wever1-3/+3
During the ISO C++ Committee meeting plenary session the C++23 Standard has been voted as technical complete. This updates the reference to c++2b to c++23 and updates the __cplusplus macro. Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D149553
2023-05-04[clang][Sema][NFC] Move `EnterExpressionEvaluationContext` to its own fileDavid Stone1-0/+1
Sema.h is huge. This makes a small reduction to it by moving EnterExpressionEvaluationContext into a new header, since it is an independent component. Differential Revision: https://reviews.llvm.org/D149796
2023-04-13[clang] Type safety tweak for AttributeCommonInfo::FormRichard Sandiford1-1/+1
This patch adds static functions for constructing most AttributeCommonInfo::Forms. Direct construction is only retained where all fields (currently the syntax and spelling) are specified explicitly. This is a wash on its own. The purpose is to allow extra fields to be added to Form without disrupting all callers. In particular, it allows extra information to be stored about keywords without affecting non-keyword uses. No functional change intended. Differential Revision: https://reviews.llvm.org/D148104
2023-03-13Fix typo: statment to statement; NFCHerrCai09071-1/+1
Differential Revision: https://reviews.llvm.org/D145834
2023-01-14[clang] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata1-1/+1
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14[clang] Add #include <optional> (NFC)Kazu Hirata1-0/+1
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03[clang] Use std::nullopt instead of None (NFC)Kazu Hirata1-2/+4
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-11-18[clang][parse] Avoid creating StmtVectors every loop iterationTimm Bäder1-1/+1
2022-11-18[clang][Parser][NFC] Simplify ParseParenExprOrConditionTimm Bäder1-20/+13
Differential Revision: https://reviews.llvm.org/D138194
2022-11-08Fix duplicate word typos; NFCRageking81-1/+1
This revision fixes typos where there are 2 consecutive words which are duplicated. There should be no code changes in this revision (only changes to comments and docs). Do let me know if there are any undesirable changes in this revision. Thanks.
2022-09-21[Clang] Support case and default labels at end of compound statementEvgeny Shulgin1-28/+25
Direct continuation of https://reviews.llvm.org/D133887 Reviewed By: #clang-language-wg, aaron.ballman Differential Revision: https://reviews.llvm.org/D134207
2022-09-17[Clang] Support label at end of compound statementEvgeny Shulgin1-10/+27
Implements paper P2324R2 https://wg21.link/p2324r2 https://github.com/cplusplus/papers/issues/1006 Reviewed By: cor3ntin Differential Revision: https://reviews.llvm.org/D133887
2022-09-03[NFC][clang] LLVM_FALLTHROUGH => [[fallthrough]Sheng1-1/+1
2022-08-22[clang] adds unary type transformations as compiler built-insChristopher Di Bella1-2/+16
Adds * `__add_lvalue_reference` * `__add_pointer` * `__add_rvalue_reference` * `__decay` * `__make_signed` * `__make_unsigned` * `__remove_all_extents` * `__remove_extent` * `__remove_const` * `__remove_volatile` * `__remove_cv` * `__remove_pointer` * `__remove_reference` * `__remove_cvref` These are all compiler built-in equivalents of the unary type traits found in [[meta.trans]][1]. The compiler already has all of the information it needs to answer these transformations, so we can skip needing to make partial specialisations in standard library implementations (we already do this for a lot of the query traits). This will hopefully improve compile times, as we won't need use as much memory in such a base part of the standard library. [1]: http://wg21.link/meta.trans Co-authored-by: zoecarver Reviewed By: aaron.ballman, rsmith Differential Revision: https://reviews.llvm.org/D116203
2022-08-14Revert "[clang] adds unary type transformations as compiler built-ins"Nico Weber1-16/+2
This reverts commit bc60cf2368de90918719dc7e3d7c63a72cc007ad. Doesn't build on Windows and breaks gcc 9 build, see https://reviews.llvm.org/D116203#3722094 and https://reviews.llvm.org/D116203#3722128 Also revert two follow-ups. One fixed a warning added in bc60cf2368de90918719dc7e3d7c63a72cc007ad, the other makes use of the feature added in bc60cf2368de90918719dc7e3d7c63a72cc007ad in libc++: Revert "[libcxx][NFC] utilises compiler builtins for unary transform type-traits" This reverts commit 06a1d917ef1f507aaa2f6891bb654696c866ea3a. Revert "[Sema] Fix a warning" This reverts commit c85abbe879ef3257de4db862ce249b060cc3d2a4.
2022-08-14[clang] adds unary type transformations as compiler built-insChristopher Di Bella1-2/+16
Adds * `__add_lvalue_reference` * `__add_pointer` * `__add_rvalue_reference` * `__decay` * `__make_signed` * `__make_unsigned` * `__remove_all_extents` * `__remove_extent` * `__remove_const` * `__remove_volatile` * `__remove_cv` * `__remove_pointer` * `__remove_reference` * `__remove_cvref` These are all compiler built-in equivalents of the unary type traits found in [[meta.trans]][1]. The compiler already has all of the information it needs to answer these transformations, so we can skip needing to make partial specialisations in standard library implementations (we already do this for a lot of the query traits). This will hopefully improve compile times, as we won't need use as much memory in such a base part of the standard library. [1]: http://wg21.link/meta.trans Co-authored-by: zoecarver Reviewed By: aaron.ballman, rsmith Differential Revision: https://reviews.llvm.org/D116203
2022-08-08[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFCFangrui Song1-2/+2
With C++17 there is no Clang pedantic warning or MSVC C5051. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D131346
2022-08-01Fixed a number of typosGabriel Ravier1-1/+1
I went over the output of the following mess of a command: (ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less) and proceeded to spend a few days looking at it to find probable typos and fixed a few hundred of them in all of the llvm project (note, the ones I found are not anywhere near all of them, but it seems like a good start). Differential Revision: https://reviews.llvm.org/D130827
2022-06-17Stop wrapping GCCAsmStmts inside StmtExprs to destruct temporariesAkira Hatanaka1-1/+0
Instead, just pop the cleanups at the end of the asm statement. This fixes an assertion failure in BuildStmtExpr. It also fixes a bug where blocks and C compound literals were destructed at the end of the asm statement instead of at the end of the enclosing scope. Differential Revision: https://reviews.llvm.org/D125936
2022-06-15[clang] Reject non-declaration C++11 attributes on declarationsMartin Boehme1-46/+95
For backwards compatiblity, we emit only a warning instead of an error if the attribute is one of the existing type attributes that we have historically allowed to "slide" to the `DeclSpec` just as if it had been specified in GNU syntax. (We will call these "legacy type attributes" below.) The high-level changes that achieve this are: - We introduce a new field `Declarator::DeclarationAttrs` (with appropriate accessors) to store C++11 attributes occurring in the attribute-specifier-seq at the beginning of a simple-declaration (and other similar declarations). Previously, these attributes were placed on the `DeclSpec`, which made it impossible to reconstruct later on whether the attributes had in fact been placed on the decl-specifier-seq or ahead of the declaration. - In the parser, we propgate declaration attributes and decl-specifier-seq attributes separately until we can place them in `Declarator::DeclarationAttrs` or `DeclSpec::Attrs`, respectively. - In `ProcessDeclAttributes()`, in addition to processing declarator attributes, we now also process the attributes from `Declarator::DeclarationAttrs` (except if they are legacy type attributes). - In `ConvertDeclSpecToType()`, in addition to processing `DeclSpec` attributes, we also process any legacy type attributes that occur in `Declarator::DeclarationAttrs` (and emit a warning). - We make `ProcessDeclAttribute` emit an error if it sees any non-declaration attributes in C++11 syntax, except in the following cases: - If it is being called for attributes on a `DeclSpec` or `DeclaratorChunk` - If the attribute is a legacy type attribute (in which case we only emit a warning) The standard justifies treating attributes at the beginning of a simple-declaration and attributes after a declarator-id the same. Here are some relevant parts of the standard: - The attribute-specifier-seq at the beginning of a simple-declaration "appertains to each of the entities declared by the declarators of the init-declarator-list" (https://eel.is/c++draft/dcl.dcl#dcl.pre-3) - "In the declaration for an entity, attributes appertaining to that entity can appear at the start of the declaration and after the declarator-id for that declaration." (https://eel.is/c++draft/dcl.dcl#dcl.pre-note-2) - "The optional attribute-specifier-seq following a declarator-id appertains to the entity that is declared." (https://eel.is/c++draft/dcl.dcl#dcl.meaning.general-1) The standard contains similar wording to that for a simple-declaration in other similar types of declarations, for example: - "The optional attribute-specifier-seq in a parameter-declaration appertains to the parameter." (https://eel.is/c++draft/dcl.fct#3) - "The optional attribute-specifier-seq in an exception-declaration appertains to the parameter of the catch clause" (https://eel.is/c++draft/except.pre#1) The new behavior is tested both on the newly added type attribute `annotate_type`, for which we emit errors, and for the legacy type attribute `address_space` (chosen somewhat randomly from the various legacy type attributes), for which we emit warnings. Depends On D111548 Reviewed By: aaron.ballman, rsmith Differential Revision: https://reviews.llvm.org/D126061
2022-04-16Add some helpers to better check Scope's kind. NFCJun Zhang1-1/+1
Signed-off-by: Jun Zhang <jun@junz.org>
2022-03-24[clang][parse] Move source range into ParsedAttibutesViewTimm Bäder1-14/+14
Move the SourceRange from the old ParsedAttributesWithRange into ParsedAttributesView, so we have source range information available everywhere we use attributes. This also removes ParsedAttributesWithRange (replaced by simply using ParsedAttributes) and ParsedAttributesVieWithRange (replaced by using ParsedAttributesView). Differential Revision: https://reviews.llvm.org/D121201
2022-03-07[clang][parser] Stop dragging an EndLoc around when parsing attributesTimm Bäder1-3/+2
It's almost always entirely unused and if it is used, the end of the attribute range can be used instead. Differential Revision: https://reviews.llvm.org/D120888
2022-02-23Add support for floating-point option `ffp-eval-method` and forZahira Ammarguellat1-0/+10
`pragma clang fp eval_method`. Differential Revision: https://reviews.llvm.org/D109239
2022-02-18Revert "Add support for floating-point option `ffp-eval-method` and for"Florian Hahn1-10/+0
This reverts commit 32b73bc6ab8234b670c34d5ef999300e072cc706. This breaks builds on macOS in some configurations, because __FLT_EVAL_METHOD__ is set to an unexpected value. E.g. https://green.lab.llvm.org/green/job/clang-stage1-RA/28282/consoleFull#129538464349ba4694-19c4-4d7e-bec5-911270d8a58c More details available in the review thread https://reviews.llvm.org/D109239
2022-02-17Add support for floating-point option `ffp-eval-method` and forZahira Ammarguellat1-0/+10
`pragma clang fp eval_method`. https://reviews.llvm.org/D109239
2022-02-15Revert "Add support for floating-point option `ffp-eval-method` and for"Nico Weber1-10/+0
This reverts commit 4bafe65c2b2f1ce745894a509a6d80c87fb1c335. Breaks at least Misc/warning-flags.c, see comments on https://reviews.llvm.org/D109239
2022-02-15Add support for floating-point option `ffp-eval-method` and forZahira Ammarguellat1-0/+10
`pragma clang fp eval_method`.
2022-01-10[Parse] Use empty RecoveryExpr when if/while/do/switch conditions fail to parseSam McCall1-16/+38
This allows the body to be parsed. An special-case that would replace a missing if condition with OpaqueValueExpr was removed as it's now redundant (unless recovery-expr is disabled). For loops are not handled at this point, as the parsing is more complicated. Differential Revision: https://reviews.llvm.org/D113752
2022-01-09[clang] Use true/false instead of 1/0 (NFC)Kazu Hirata1-1/+1
Identified with modernize-use-bool-literals.
2021-11-22[C++20] [Coroutines] Warn for deprecated form 'for co_await'Chuanqi Xu1-0/+3
The form 'for co_await' is part of CoroutineTS instead of C++20. So if we detected the use of 'for co_await' in C++20, we should emit a warning at least.
2021-10-20consteval if does not form a discarded statementAaron Ballman1-6/+8
When we added support for if consteval, we accidentally formed a discarded statement evaluation context for the branch-not-taken. However, a discarded statement is a property of an if constexpr statement, not an if consteval statement (https://eel.is/c++draft/stmt.if#2.sentence-2). This turned out to cause issues when deducing the return type from a function with a consteval if statement -- we wouldn't consider the branch-not-taken when deducing the return type. This fixes PR52206. Note, there is additional work left to be done. We need to track discarded statement and immediate evaluation contexts separately rather than as being mutually exclusive.
2021-10-11[MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)Hans Wennborg1-1/+5
This adds support for the MSVC spelling of the pragma in -fms-extensions mode. Differential revision: https://reviews.llvm.org/D111440
generated by cgit v1.1 at 2024-07-31 23:11:56 +0000