aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Parse/Parser.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-04-12[Clang] CWG 1394: Incomplete types as parameters of deleted functionsPoYao Chang1-38/+47
According to CWG 1394 and C++20 [dcl.fct.def.general]p2, Clang should not diagnose incomplete types if function body is "= delete;". For example: ``` struct Incomplete; Incomplete f(Incomplete) = delete; // well-formed ``` Also close https://github.com/llvm/llvm-project/issues/52802 Differential Revision: https://reviews.llvm.org/D122981
2022-03-25[C++20][Modules][HU 1/5] Introduce header units as a module type.Iain Sandoe1-2/+3
This is the first in a series of patches that introduce C++20 importable header units. These differ from clang header modules in that: (a) they are identifiable by an internal name (b) they represent the top level source for a single header - although that might include or import other headers. We name importable header units with the path by which they are specified (although that need not be the absolute path for the file). So "foo/bar.h" would have a name "foo/bar.h". Header units are made a separate module type so that we can deal with diagnosing places where they are permitted but a named module is not. Differential Revision: https://reviews.llvm.org/D121095
2022-03-24[clang][parse] Move source range into ParsedAttibutesViewTimm Bäder1-34/+29
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-02[NFC] [C++20] [Modules] Simplify ActOnModuleImport by merging Path and ParitionChuanqi Xu1-9/+10
Reviewed By: iains Differential Revision: https://reviews.llvm.org/D120793
2022-02-24[C++20][Modules][3/8] Initial handling for module partitions.Iain Sandoe1-29/+32
This implements the parsing and recognition of module partition CMIs and removes the FIXMEs in the parser. Module partitions are recognised in the base computation of visibility, however additional amendments to visibility follow in subsequent patches. Differential Revision: https://reviews.llvm.org/D118586
2022-02-21[C++20][Modules][1/8] Track valid import state.Iain Sandoe1-14/+77
In C++20 modules imports must be together and at the start of the module. Rather than growing more ad-hoc flags to test state, this keeps track of the phase of of a valid module TU (first decl, global module frag, module, private module frag). If the phasing is broken (with some diagnostic) the pattern does not conform to a valid C++20 module, and we set the state accordingly. We can thus issue diagnostics when imports appear in the wrong places and decouple the C++20 modules state from other module variants (modules-ts and clang modules). Additionally, we attempt to diagnose wrong imports before trying to find the module where possible (the latter will generally emit an unhelpful diagnostic about the module not being available). Although this generally simplifies the handling of C++20 module import diagnostics, the motivation was that, in particular, it allows detecting invalid imports like: import module A; int some_decl(); import module B; where being in a module purview is insufficient to identify them. Differential Revision: https://reviews.llvm.org/D118893
2022-02-20Revert "[C++20][Modules][1/8] Track valid import state."Iain Sandoe1-77/+14
This reverts commit 8a3f9a584ad43369cf6a034dc875ebfca76d9033. need to investigate build failures that do not show on CI or local testing.
2022-02-20[C++20][Modules][1/8] Track valid import state.Iain Sandoe1-14/+77
In C++20 modules imports must be together and at the start of the module. Rather than growing more ad-hoc flags to test state, this keeps track of the phase of of a valid module TU (first decl, global module frag, module, private module frag). If the phasing is broken (with some diagnostic) the pattern does not conform to a valid C++20 module, and we set the state accordingly. We can thus issue diagnostics when imports appear in the wrong places and decouple the C++20 modules state from other module variants (modules-ts and clang modules). Additionally, we attempt to diagnose wrong imports before trying to find the module where possible (the latter will generally emit an unhelpful diagnostic about the module not being available). Although this generally simplifies the handling of C++20 module import diagnostics, the motivation was that, in particular, it allows detecting invalid imports like: import module A; int some_decl(); import module B; where being in a module purview is insufficient to identify them. Differential Revision: https://reviews.llvm.org/D118893
2022-01-09[clang] Fix bugprone argument comments (NFC)Kazu Hirata1-5/+5
Identified with bugprone-argument-comment.
2022-01-09[clang] Use true/false instead of 1/0 (NFC)Kazu Hirata1-2/+2
Identified with modernize-use-bool-literals.
2021-10-11[MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)Hans Wennborg1-0/+1
This adds support for the MSVC spelling of the pragma in -fms-extensions mode. Differential revision: https://reviews.llvm.org/D111440
2021-07-12[OpenMP] Support OpenMP 5.1 attributesAaron Ballman1-0/+2
OpenMP 5.1 added support for writing OpenMP directives using [[]] syntax in addition to using #pragma and this introduces support for the new syntax. In OpenMP, the attributes take one of two forms: [[omp::directive(...)]] or [[omp::sequence(...)]]. A directive attribute contains an OpenMP directive clause that is identical to the analogous #pragma syntax. A sequence attribute can contain either sequence or directive arguments and is used to ensure that the attributes are processed sequentially for situations where the order of the attributes matter (remember: https://eel.is/c++draft/dcl.attr.grammar#4.sentence-4). The approach taken here is somewhat novel and deserves mention. We could refactor much of the OpenMP parsing logic to work for either pragma annotation tokens or for attribute clauses. It would be a fair amount of effort to share the logic for both, but it's certainly doable. However, the semantic attribute system is not designed to handle the arbitrarily complex arguments that OpenMP directives contain. Adding support to thread the novel parsed information until we can produce a semantic attribute would be considerably more effort. What's more, existing OpenMP constructs are not (often) represented as semantic attributes. So doing this through Attr.td would be a massive undertaking that would likely only benefit OpenMP and comes with additional risks. Rather than walk down that path, I am taking advantage of the fact that the syntax of the directives within the directive clause is identical to that of the #pragma form. Once the parser recognizes that we're processing an OpenMP attribute, it caches all of the directive argument tokens and then replays them as though the user wrote a pragma. This reuses the same OpenMP parsing and semantic logic directly, but does come with a risk if the OpenMP committee decides to purposefully diverge their pragma and attribute syntaxes. So, despite this being a novel approach that does token replay, I think it's actually a better approach than trying to do this through the declarative syntax in Attr.td.
2021-07-01Fix an accepts-invalid issue with [[]] attributes in the type position in CAaron Ballman1-1/+1
A user reported an issue to me via email that Clang was accepting some code that GCC was rejecting. After investigation, it turned out to be a general problem of us failing to properly reject attributes written in the type position in C when they don't apply to types. The root cause was a terminology issue -- we sometimes use "CXX11Attr" to mean [[]] in C++11 mode and sometimes [[]] in general -- and this came back to bite us because in this particular case, it really meant [[]] in C++ mode. I fixed the issue by introducing a new function AttributeCommonInfo::isStandardAttributeSyntax() to represent [[]] in either C or C++ mode. This fix pointed out that we've had the issue in some of our existing tests, which have all been corrected. This resolves https://bugs.llvm.org/show_bug.cgi?id=50954.
2021-05-31Re-commit [clang] Add support for the "abstract" contextual keyword of MSVCAbbas Sabra1-0/+1
https://docs.microsoft.com/en-us/cpp/extensions/abstract-cpp-component-extensions?view=msvc-160 Note: like the already supported "sealed" keyword, the "abstract" keyword is supported by MSVC by default. This re-commits 818338add77411f5e9713247ea66142f332ef350 with added initialization of Parser::Ident_abstract. Differential revision: https://reviews.llvm.org/D102517
2021-05-20When vector is found as a type or non-type id, check if it is really the ↵Jamie Schmeiser1-0/+10
altivec vector token. Summary: Call TryAltiVecVectorToken when an identifier is seen in the parser before annotating the token. This checks the next token where necessary to ensure that vector is properly handled as the altivec token. Author: Jamie Schmeiser <schmeise@ca.ibm.com> Reviewed By: ZarkoCA (Zarko Todorovski) Differential Revision: https://reviews.llvm.org/D100991
2021-05-17[OpenCL] Drop pragma handling for extension types/decls.Anastasia Stulova1-2/+0
Drop non-conformant extension pragma implementation as it does not properly disable anything and therefore enabling non-disabled logic has no meaning. This simplifies clang code and user interface to the extension functionality. With this patch extension pragma 'begin'/'end' and 'enable'/'disable' are only accepted for backward compatibility and no longer have any default behavior. Differential Revision: https://reviews.llvm.org/D101043
2021-05-13Parse vector bool when stdbool.h and altivec.h are includedZarko Todorovski1-0/+2
Currently when including stdbool.h and altivec.h declaration of `vector bool` leads to errors due to `bool` being expanded to '_Bool`. This patch allows the parser to recognize `_Bool`. Reviewed By: hubert.reinterpretcast, Everybody0523 Differential Revision: https://reviews.llvm.org/D102064
2021-03-16[CodeCompletion] Avoid spurious signature help for init-list argsSam McCall1-5/+5
Somewhat surprisingly, signature help is emitted as a side-effect of computing the expected type of a function argument. The reason is that both actions require enumerating the possible function signatures and running partial overload resolution, and doing this twice would be wasteful and complicated. Change #1: document this, it's subtle :-) However, sometimes we need to compute the expected type without having reached the code completion cursor yet - in particular to allow completion of designators. eb4ab3358cd4dc834a761191b5531b38114f7b13 did this but introduced a regression - it emits signature help in the wrong location as a side-effect. Change #2: only emit signature help if the code completion cursor was reached. Currently there is PP.isCodeCompletionReached(), but we can't use it because it's set *after* running code completion. It'd be nice to set this implicitly when the completion token is lexed, but ConsumeCodeCompletionToken() makes this complicated. Change #3: call cutOffParsing() *first* when seeing a completion token. After this, the fact that the Sema::Produce*SignatureHelp() functions are even more confusing, as they only sometimes do that. I don't want to rename them in this patch as it's another large mechanical change, but we should soon. Change #4: prepare to rename ProduceSignatureHelp() to GuessArgumentType() etc. Differential Revision: https://reviews.llvm.org/D98488
2021-03-16[CodeCompletion] Don't track preferred types if code completion is disabled.Sam McCall1-4/+4
Some of this work isn't quite trivial. (As requested in D96058) Differential Revision: https://reviews.llvm.org/D98459
2020-11-21[NFC, Refactor] Modernize enum FunctionDefinitionKind (DeclSpech.h) into a ↵Faisal Vali1-2/+2
scoped enum Reviewed by aaron.ballman, rsmith, wchilders Highlights of review: - avoid specifying an underlying type (unless such an enum is stored (or part of an abi?)) - avoid using enums as bit-fields, preferring unsigned bit-fields that we static_cast enumerators to. (MS's abi laysout enum bit-fields differently). - clang-format, clang-format, clang-format. https://reviews.llvm.org/D91035 Thank you!
2020-11-10[NFC, Refactor] Rename the (scoped) enum DeclaratorContext's enumerators to ↵Faisal Vali1-10/+9
remove duplication Since these are scoped enumerators, they have to be prefixed by DeclaratorContext, so lets remove Context from the name, and return some characters to the multiverse. Patch was reviewed here: https://reviews.llvm.org/D91011 Thank you to aaron, bruno, wyatt and barry for indulging me.
2020-09-04[FPEnv] Partially implement #pragma STDC FENV_ROUNDSerge Pavlov1-0/+3
This change implements pragma STDC FENV_ROUND, which is introduced by the extension to standard (TS 18661-1). The pragma is implemented only in frontend, it sets apprpriate state of FPOptions stored in Sema. Use of these bits in constant evaluation adn/or code generator is not in the scope of this change. Parser issues warning on unsuppored pragma when it encounteres pragma STDC FENV_ROUND, however it makes syntax checks and updates Sema state as if the pragma were supported. Primary purpose of the partial implementation is to facilitate development of non-default floating poin environment. Previously a developer cannot set non-default rounding mode in sources, this mades preparing tests for say constant evaluation substantially complicated. Differential Revision: https://reviews.llvm.org/D86921
2020-08-31Fix -Wcompound-token-split to give the same warnings under -ERichard Smith1-8/+7
-frewrite-includes. Remove the special-case (and highly implausible) diagnostic for a compound token that crosses a file boundary, and instead model that case the same as a compound token separated by whitespace, so that file transitions and presumed file transitions behave the same way.
2020-08-28Add new warning for compound punctuation tokens that are split across macro ↵Richard Smith1-0/+33
expansions or split by whitespace. For example: #define FOO(x) (x) FOO({}); ... forms a statement-expression after macro expansion. This warning applies to '({' and '})' delimiting statement-expressions, '[[' and ']]' delimiting attributes, and '::*' introducing a pointer-to-member. The warning for forming these compound tokens across macro expansions (or across files!) is enabled by default; the warning for whitespace within the tokens is not, but is included in -Wall. Differential Revision: https://reviews.llvm.org/D86751
2020-08-13[Parser] Suppress -Wempty-translation-unit if this is a header fileSam McCall1-1/+2
This is motivated by tooling (clangd, libclang etc) - headers without declarations are legitimate even if they're not valid TUs. The other use -x c-header cases (PCH/modules) are nonstandard anyway and this warning doesn't seem necessary there either. Differential Revision: https://reviews.llvm.org/D85789
2020-07-27Don't form a 'context-independent expr' reference to a member duringRichard Smith1-3/+2
name annotation. Instead, defer forming the member access expression or DeclRefExpr until we build the use of ClassifyName's result. Just build an UnresolvedLookupExpr to track the LookupResult until we're ready to consume it. This also reverts commit 2f7269b6773de2750f9cd1417ef5f21cd6cf7a91 (other than its testcase). That change was an attempted workaround for the same problem.
2020-06-12Handle delayed-template-parsing functions imported into a non-dtp TUSam McCall1-3/+1
Summary: DelayedTemplateParsing is marked as BENIGN_LANGOPT, so we are allowed to use a delayed template in a non-delayed TU. (This is clangd's default configuration on windows: delayed-template-parsing is on for the preamble and forced off for the current file) However today clang fails to parse implicit instantiations in a non-dtp TU of templates defined in a dtp PCH file (and presumably module?). In this case the delayed parser is not registered, so the function is simply marked "delayed" again. We then hit an assert: end of TU template instantiation should not create more late-parsed templates Reviewers: rsmith Subscribers: ilya-biryukov, usaxena95, cfe-commits, kadircet Tags: #clang Differential Revision: https://reviews.llvm.org/D81474
2020-06-02Fix compiler crash when an expression parsed in the tentative parsing and ↵Alexey Bataev1-1/+2
must be claimed in the another evaluation context. Summary: Clang crashes when trying to finish function body. MaybeODRUseExprs is not empty because of const static data member parsed in outer evaluation context, upon call for isTypeIdInParens() function. It builds annot_primary_expr, later parsed in ParseConstantExpression() in inner constant expression evaluation context. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80925
2020-05-04Reapply "Add support for #pragma float_control" with buildbot fixesMelanie Blower1-0/+3
Add support for #pragma float_control Reviewers: rjmccall, erichkeane, sepavloff Differential Revision: https://reviews.llvm.org/D72841 This reverts commit fce82c0ed310174fe48e2402ac731b6340098389.
2020-05-01Revert "Reapply "Add support for #pragma float_control" with improvements to"Melanie Blower1-3/+0
This reverts commit 69aacaf699922ffe0450f567e21208c10c84731f.
2020-05-01Reapply "Add support for #pragma float_control" with improvements toMelanie Blower1-0/+3
test cases Add support for #pragma float_control Reviewers: rjmccall, erichkeane, sepavloff Differential Revision: https://reviews.llvm.org/D72841 This reverts commit 85dc033caccaa6ab919d57f9759290be41240146, and makes corrections to the test cases that failed on buildbots.
2020-05-01Revert "Add support for #pragma float_control"Melanie Blower1-3/+0
This reverts commit 4f1e9a17e9d28bdfd035313c96b3a5d4c91a7733. due to fail on buildbot, sorry for the noise
2020-05-01Add support for #pragma float_controlMelanie Blower1-0/+3
Reviewers: rjmccall, erichkeane, sepavloff Differential Revision: https://reviews.llvm.org/D72841
2020-04-05PR45239: Don't deallocate TemplateIdAnnotations if they might still beRichard Smith1-20/+8
in the token stream. Previously we deleted all template-id annotations at the end of each top-level declaration. That doesn't work: we can do some lookahead and form a template-id annotation, and then roll back that lookahead, parse, and decide that we're missing a semicolon at the end of a top-level declaration, before we reach the annotation token. In that situation, we'd end up parsing the annotation token after deleting its associated data, leading to various forms of badness. We now only delete template-id annotations if the preprocessor can assure us that there are no annotation tokens left in the token stream (or if we're already at EOF). This lets us delete the annotation tokens earlier in a lot of cases; we now clean them up at the end of each statement and class member, not just after each top-level declaration. This also permitted some simplification of the delay-parsed templates cleanup code.
2020-03-30Fix crash if base specifier parsing hits an invalid type annotation.Richard Smith1-1/+1
Also change type annotation representation from ParsedType to TypeResult to make it clearer to consumers that they can represent invalid types.
2020-03-27PR45294: Fix handling of assumed template names looked up in the lexicalRichard Smith1-13/+8
scope. There are a few contexts in which we assume a name is a template name; if such a context is one where we should perform an unqualified lookup, and lookup finds nothing, we would form a dependent template name even if the name is not dependent. This happens in particular for the lookup of a pseudo-destructor. In passing, rename ActOnDependentTemplateName to just ActOnTemplateName given that we apply it for non-dependent template names too.
2020-03-27Improve recovery from invalid template-ids.Richard Smith1-0/+2
Instead of bailing out of parsing when we encounter an invalid template-name or template arguments in a template-id, produce an annotation token describing the invalid construct. This avoids duplicate errors and generally allows us to recover better. In principle we should be able to extend this to store some kinds of invalid template-id in the AST for tooling use, but that isn't handled as part of this change.
2020-03-19[Parser] Avoid spurious 'missing template' error in presence of typos.Haojian Wu1-8/+18
Suppress those diagnostics if lhs of a member expression contains errors. Typo correction produces dependent expressions even in non-template code, that led to spurious diagnostics before. previous: /tmp/t.cpp:6:17: error: use 'template' keyword to treat 'f' as a dependent template name auto a = bilder.f<int>(); ^ template /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder vs now: /tmp/t.cpp:6:10: error: use of undeclared identifier 'bilder'; did you mean 'builder'? auto a = bilder.f<int>(); ^~~~~~ builder Original patch from Ilya. Reviewers: sammccall Reviewed By: sammccall Tags: #clang Differential Revision: https://reviews.llvm.org/D65592
2020-03-12[clang][Parse] properly parse asm-qualifiers, asm inlineNick Desaulniers1-5/+5
Summary: The parsing of GNU C extended asm statements was a little brittle and had a few issues: - It was using Parse::ParseTypeQualifierListOpt to parse the `volatile` qualifier. That parser is really meant for TypeQualifiers; an asm statement doesn't really have a type qualifier. This is still maybe nice to have, but not necessary. We now can check for the `volatile` token by properly expanding the grammer, rather than abusing Parse::ParseTypeQualifierListOpt. - The parsing of `goto` was position dependent, so `asm goto volatile` wouldn't parse. The qualifiers should be position independent to one another. Now they are. - We would warn on duplicate `volatile`, but the parse error for duplicate `goto` was a generic parse error and wasn't clear. - We need to add support for the recent GNU C extension `asm inline`. Adding support to the parser with the above issues highlighted the need for this refactoring. Link: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: aheejin, jfb, nathanchance, cfe-commits, echristo, efriedma, rsmith, chandlerc, craig.topper, erichkeane, jyu2, void, srhines Tags: #clang Differential Revision: https://reviews.llvm.org/D75563
2020-03-11Avoid including FileManager.h from SourceManager.hReid Kleckner1-0/+1
Most clients of SourceManager.h need to do things like turning source locations into file & line number pairs, but this doesn't require bringing in FileManager.h and LLVM's FS headers. The main code change here is to sink SM::createFileID into the cpp file. I reason that this is not performance critical because it doesn't happen on the diagnostic path, it happens along the paths of macro expansion (could be hot) and new includes (less hot). Saves some includes: 309 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileManager.h 272 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileSystemOptions.h 271 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/VirtualFileSystem.h 267 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/FileSystem.h 266 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Chrono.h Differential Revision: https://reviews.llvm.org/D75406
2020-02-04[Driver] Change -fmax-tokens $arg to -fmax-tokens=$argFangrui Song1-1/+1
Reviewed By: hans Differential Revision: https://reviews.llvm.org/D73937
2020-01-27Add a warning, flags and pragmas to limit the number of pre-processor tokens ↵Hans Wennborg1-0/+10
in a translation unit See https://docs.google.com/document/d/1xMkTZMKx9llnMPgso0jrx3ankI4cv60xeZ0y4ksf4wc/preview for background discussion. This adds a warning, flags and pragmas to limit the number of pre-processor tokens either at a certain point in a translation unit, or overall. The idea is that this would allow projects to limit the size of certain widely included headers, or for translation units overall, as a way to insert backstops for header bloat and prevent compile-time regressions. Differential revision: https://reviews.llvm.org/D72703
2020-01-23[Concepts] Placeholder constraints and abbreviated templatesSaar Raz1-0/+24
This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after fixing MSAN failures caused by incomplete initialization of AutoTypeLocs in TypeSpecLocFiller. Differential Revision: https://reviews.llvm.org/D65042
2020-01-23Revert "[Concepts] Placeholder constraints and abbreviated templates"Sam McCall1-24/+0
This reverts commit e57a9abc4b01fa69fe81ace8df70517983b6cbac. Parser/cxx2a-placeholder-type-constraint.cpp has MSan failures. Present at 7b81c3f8793d30a4285095a9b67dcfca2117916c: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/17133/steps/check-clang%20msan/logs/stdio not present at eaa594f4ec54eba52b03fd9f1c789b214c66a753: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/17132/steps/check-clang%20msan/logs/stdio Stack trace: ``` ==57032==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0xccfe016 in clang::AutoTypeLoc::getLocalSourceRange() const /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/AST/TypeLoc.h:2036:19 #1 0xcc56758 in CheckDeducedPlaceholderConstraints(clang::Sema&, clang::AutoType const&, clang::AutoTypeLoc, clang::QualType) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4505:56 #2 0xcc550ce in clang::Sema::DeduceAutoType(clang::TypeLoc, clang::Expr*&, clang::QualType&, llvm::Optional<unsigned int>, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4707:11 #3 0xcc52407 in clang::Sema::DeduceAutoType(clang::TypeSourceInfo*, clang::Expr*&, clang::QualType&, llvm::Optional<unsigned int>, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4457:10 #4 0xba38332 in clang::Sema::deduceVarTypeFromInitializer(clang::VarDecl*, clang::DeclarationName, clang::QualType, clang::TypeSourceInfo*, clang::SourceRange, bool, clang::Expr*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11351:7 #5 0xba3a8a9 in clang::Sema::DeduceVariableDeclarationType(clang::VarDecl*, bool, clang::Expr*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11385:26 #6 0xba3c520 in clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11725:9 #7 0xb39c498 in clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2399:17 #8 0xb394d80 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2128:21 #9 0xb383bbf in clang::Parser::ParseSimpleDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:1848:10 #10 0xb383129 in clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/ADT/PointerUnion.h #11 0xb53a388 in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:221:13 #12 0xb539309 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:106:20 #13 0xb55610e in clang::Parser::ParseCompoundStatementBody(bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:1079:11 #14 0xb559529 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:2204:21 #15 0xb33c13e in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1339:10 #16 0xb394703 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2068:11 #17 0xb338e52 in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1099:10 #18 0xb337674 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1115:12 #19 0xb334a96 in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:935:12 #20 0xb32f12a in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:686:12 #21 0xb31e193 in clang::ParseAST(clang::Sema&, bool, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseAST.cpp:158:20 #22 0x80263f0 in clang::FrontendAction::Execute() /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:936:8 #23 0x7f2a257 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:965:33 #24 0x8288bef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:290:25 #25 0xad44c2 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/cc1_main.cpp:239:15 #26 0xacd76a in ExecuteCC1Tool(llvm::ArrayRef<char const*>) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/driver.cpp:325:12 #27 0xacc9fd in main /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/driver.cpp:398:12 #28 0x7f7d82cdb2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #29 0xa4dde9 in _start (/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build_msan/bin/clang-11+0xa4dde9) ```
2020-01-22[Concepts] Placeholder constraints and abbreviated templatesSaar Raz1-0/+24
This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after incorrect check in NonTypeTemplateParmDecl broke lldb. Differential Revision: https://reviews.llvm.org/D65042
2020-01-21Revert "[Concepts] Placeholder constraints and abbreviated templates"Jonas Devlieghere1-24/+0
This temporarily reverts commit e03ead6771fc97b11cb0c94b7f023142184ad25f because it breaks LLDB. http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/3356 http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/12872 http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/6407/
2020-01-22[Concepts] Placeholder constraints and abbreviated templatesSaar Raz1-0/+24
This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Differential Revision: https://reviews.llvm.org/D65042
2020-01-17Remove redundant CXXScopeSpec from TemplateIdAnnotation.Richard Smith1-2/+2
A TemplateIdAnnotation represents only a template-id, not a nested-name-specifier plus a template-id. Don't make a redundant copy of the CXXScopeSpec and store it on the template-id annotation. This slightly improves error recovery by more properly handling the case where we would form an invalid CXXScopeSpec while parsing a typename specifier, instead of accidentally putting the token stream into a broken "annot_template_id with a scope specifier, but with no preceding annot_cxxscope token" state.
2020-01-15PR42694 Support explicit(bool) in older language modes as an extension.Richard Smith1-4/+1
This needs somewhat careful disambiguation, as C++2a explicit(bool) is a breaking change. We only enable it in cases where the source construct could not possibly be anything else.
2020-01-08Disallow an empty string literal in an asm labelAaron Ballman1-4/+12
An empty string literal in an asm label does not make a whole lot of sense. GCC does not diagnose such a construct, but it also generates code that cannot be assembled by gas should two symbols have an empty asm label within the same TU. This does not affect an asm statement with an empty string literal, which is still a useful construct.
generated by cgit v1.1 at 2025-10-01 06:32:29 +0000