| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Summary: Just like templates, they are excepted from the ODR rule.
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D68923
(cherry picked from commit 27684ae66d5545f211c0ac4393d0ba2bf3b5b47c)
|
|
|
|
| |
(cherry picked from commit b96c6b65b93f7b3878bced2374bef747a4c3b690)
|
|
|
|
|
|
|
|
|
|
| |
We did not have a CXXThisScope around constraint checking of functions and
function template specializations, causing a crash when checking a constraint
that had a 'this' (bug 44689).
Recommit after fixing test.
(cherry picked from commit 6c232441564f8934477e418347bf0c217abb0a00)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when building a defaulted comparison.
As a convenient way of asking whether `x @ y` is valid and building it,
we previouly always performed overload resolution and built an
overloaded expression, which would both end up picking a builtin
operator candidate when given a non-overloadable type. But that's not
quite right, because it can result in our finding a user-declared
operator overload, which we should never do when applying operators
non-overloadable types.
Handle this more correctly: skip overload resolution when building
`x @ y` if the operands are not overloadable. But still perform overload
resolution (considering only builtin candidates) when checking validity,
as we don't have any other good way to ask whether a binary operator
expression would be valid.
(cherry picked from commit 1f3f8c369a5067a132c871f33a955a7feaea8534)
|
|
|
|
|
|
| |
are equally constrained.
(cherry picked from commit cfacf9ae20b8c97a428f118a2720bc109ba6a143)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
along with function parameters
We previously instantiated type-constraints of template type parameters along with the type parameter itself,
this caused problems when the type-constraints created by abbreviated templates refreneced other parameters
in the abbreviated templates.
When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of
the type-constraint until the function parameter which created the invented template type parameter is
instantiated.
Reland after fixing bug caused by another flow reaching SubstParmVarDecl and instantiating the TypeConstraint
a second time.
(cherry picked from commit 84959ae47f447fca9d56a9c61e8c46e993d0387a)
|
|
|
|
|
|
| |
type-constraint along with function parameters"
This temporarily reverts commit 2b54b8b994b45d4e0a72f36dfb91dc9662543234 which caused some test failures.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
along with function parameters
We previously instantiated type-constraints of template type parameters along with the type parameter itself,
this caused problems when the type-constraints created by abbreviated templates refreneced other parameters
in the abbreviated templates.
When encountering a template type parameter with a type constraint, if it is implicit, delay instantiation of
the type-constraint until the function parameter which created the invented template type parameter is
instantiated.
(cherry picked from commit eacca4824463d8b96e2e1c9f8bbf886055218a16)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During the review of D73007 Aaron Puchert mentioned
`warn_for_range_variable_always_copy` shouldn't be part of -Wall since
some coding styles require `for(const auto &bar : bars)`. This warning
would cause false positives for these users. Based on Aaron's proposal
refactored the warnings:
* -Wrange-loop-construct warns about possibly unintended constructor
calls. This is part of -Wall. It contains
* warn_for_range_copy: loop variable A of type B creates a copy from
type C
* warn_for_range_const_reference_copy: loop variable A is initialized
with a value of a different type resulting in a copy
* -Wrange-loop-bind-reference warns about misleading use of reference
types. This is not part of -Wall. It contains
* warn_for_range_variable_always_copy: loop variable A is always a copy
because the range of type B does not return a reference
Differential Revision: https://reviews.llvm.org/D73434
(cherry picked from commit c03349e40f21f0375278138992a32694a99c830e)
|
|
|
|
|
|
| |
overrides the final overrider in a different base class.
(cherry picked from commit aade5fbbfef3e8555df202082bea905deebc2ca5)
|
|
|
|
|
|
|
|
|
|
| |
types are needed to compute the return type of a defaulted operator<=>.
This raises the question of what to do if return type deduction fails.
The standard doesn't say, and implementations vary, so for now reject
that case eagerly to keep our options open.
(cherry picked from commit 42d4a55f227a1cc78ab8071062d869abe88655d9)
|
|
|
|
|
|
|
|
|
| |
isDeclarationSpecifiers did not handle some cases of placeholder-type-specifiers with
type-constraints, causing parsing bugs in abbreviated constructor templates.
Add comprehensive handling of type-constraints to isDeclarationSpecifier.
(cherry picked from commit b7ce85a130789d23c69156f4b899962458d1f05d)
|
|
|
|
|
|
|
|
|
|
|
|
| |
support substitution into SubstNonTypeTemplateParmExpr
We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts.
Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into
template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator.
We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP
with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent).
(cherry picked from commit ba1f3db4b0729ad932aa4f091e9578132d98a0c8)
|
|
|
|
| |
(cherry picked from commit 1db66e705f4dbe7dbe17edac804289ef59d5f616)
|
|
|
|
|
|
|
|
|
|
| |
A constrained function with an auto return type would have it's definition
instantiated in order to deduce the auto return type before the constraints
are checked.
Move the constraints check after the return type deduction.
(cherry picked from commit 980517b3530ffb7faa1a23fdc007d78f5b45ae3c)
|
|
|
|
|
|
|
| |
Attributes are permitted on friend definitions, but we only checked for
a proper function body, not for the =default / =delete cases.
(cherry picked from commit 5ae6554a1dcd2e39346030c06d364492901c9e8d)
|
|
|
|
|
|
|
|
|
|
| |
We previously checked for containsUnexpandedParameterPack in CSEs by observing the property
in the converted arguments of the CSE. This may not work if the argument is an expanded
type-alias that contains a pack-expansion (see added test).
Check the as-written arguments when determining containsUnexpandedParameterPack and isInstantiationDependent.
(cherry picked from commit c83d9bedc0cc430dc620e7a807daeb985d390325)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes clang somewhat forward-compatible with new CUDA releases
without having to patch it for every minor release without adding
any new function.
If an unknown version is found, clang issues a warning (can be disabled
with -Wno-cuda-unknown-version) and assumes that it has detected
the latest known version. CUDA releases are usually supersets
of older ones feature-wise, so it should be sufficient to keep
released clang versions working with minor CUDA updates without
having to upgrade clang, too.
Differential Revision: https://reviews.llvm.org/D73231
(cherry picked from commit 12fefeef203ab4ef52d19bcdbd4180608a4deae1)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: lenary, asb
Reviewed By: lenary
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72755
(cherry picked from commit e15fb06e2d0a068de549464d72081811e7fac612)
|
|
|
|
|
|
|
| |
The wrong set of TemplateArgs was being provided to addInstantiatedParametersToScope.
Caused bug #44658.
(cherry picked from commit 9c24fca2a33fc0fd059e278bb95c84803dfff9ae)
|
|
|
|
|
|
|
|
|
|
|
| |
tests for scope specifiers in type-constraints
The code for parsing of type-constraints in compound-requirements was not adapted for the new TryAnnotateTypeConstraint which
caused compound-requirements with scope specifiers to ignore them.
Also add regression tests for scope specifiers in type-constraints in more contexts.
(cherry picked from commit 5043962dd3150c6ac72b75174b9460a510d1b5c3)
|
|
|
|
|
|
|
|
|
|
| |
We would previously try to evaluate atomic constraints of non-template functions as-is,
and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656).
Substitute into atomic constraints of non-template functions as we would atomic constraints
of template functions, in order to rebuild the expressions in a constant-evaluated context.
(cherry picked from commit 713562f54858f10bf8998ee21ff2c7e7bad0d177)
|
|
|
|
|
|
| |
Member functions will have the thiscall attribute on them.
(cherry picked from commit 698d1cd3b8154b3b74423386d3e111e6b756e87a)
|
|
|
|
|
|
|
|
|
|
| |
__attribute__((patchable_function_entry(N,M))) where M>0
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D73072
(cherry picked from commit 69bf40c45fd7f6dfe11b47de42571d8bff5ef94f)
|
|
|
|
|
|
|
|
|
| |
As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic
constraints only become constant evaluated during satisfaction checking.
Change the evaluation context during parsing and instantiation of constraints to unevaluated.
(cherry picked from commit 73eaf62463b4a29adf4194685af12d1a5d172987)
|
|
|
|
|
|
|
|
|
| |
Now with concepts support merged and mostly complete, we do not need -fconcepts-ts
(which was also misleading as we were not implementing the TS) and can enable
concepts features under C++2a. A warning will be generated if users still attempt
to use -fconcepts-ts.
(cherry picked from commit 67c608a9695496cfc9d3fdf9d0b12b554ac6b4df)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters with constrained templates
Summary: Allow unconstrained template template parameters to accept constrainted templates as arguments.
Reviewers: rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73155
(cherry picked from commit d42d5eb8ea77b3a3a502a60ba3f053fb81a897f3)
|
|
|
|
|
|
|
| |
Proper ExpressionEvaluationContext were not being entered when instantiating constraint
expressions, which caused assertion failures in certain cases, including bug #44614.
(cherry picked from commit 4d33a8dfcf67e970ea4d150d514b27de02e79aee)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
(cherry picked from commit b481f028144ca91c15d1db3649ce14f174259e7e)
|
|
|
|
|
|
|
|
|
|
|
| |
Profile TypeConstraints in ProfileTemplateParameterList so we can distinguish
between partial specializations which differ in their TemplateParameterList
type constraints.
Recommit, now profiling the IDC so that we can deal with situations where the
TemplateArgsAsWritten are nullptr (happens when canonicalizing type constraints).
(cherry picked from commit 62c221b5090c2e1d3ca408bcab6f69c4d9e175b7)
|
|
|
|
|
|
|
|
| |
function template requires clause
Fixes bug #44613 - incorrect instantiated parameters were being added when checking instantiated function constraints
(cherry picked from commit c2a250e1c43c05925fe040dc9624403af7879453)
|
|
|
|
|
|
|
|
|
|
|
| |
Add a simple cache for constraint satisfaction results. Whether or not this simple caching
would be permitted in final C++2a is currently being discussed but it is required for
acceptable performance so we use it in the meantime, with the possibility of adding some
cache invalidation mechanisms later.
Differential Revision: https://reviews.llvm.org/D72552
(cherry picked from commit b933d37cd3774e5431b35e82187eebb59b1ff59e)
|
|
|
|
|
|
|
|
|
|
| |
Implement support for C++2a requires-expressions.
Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair.
Differential Revision: https://reviews.llvm.org/D50360
(cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
(cherry picked from commit a42fd84cff265b7e9faa3fe42885ee171393e4db)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the same strategy as c38e42527b21.
D69825 revealed (introduced?) a problem when building with ASan, and
some memory leaks somewhere. More details are available in the original
patch.
Looks like we missed one failing tests, this patch adds the workaround
to this test as well.
(cherry picked from commit e174da447c180b586719cb28f7bd556e30625762)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using in-process cc1, the Clang Interface Stubs pipeline setup
exposes an ASAN bug. I am still investigating this issue but want to
green the bots for now. I don't think this is a huge issue since the
Clang Interface Stubs Driver setup code is the only code path that sets
up such a pipeline (ie N cc1's for N c files followed by another N cc1's
for to generate stub files for the same N c files).
This issue is being discussed in https://reviews.llvm.org/D69825.
If a resolution is not found soon, a bugzilla filling will be in order.
(cherry picked from commit c38e42527b21acee8d01a016d5bfa2fb83202e29)
|
|
|
|
|
|
|
|
|
|
|
|
| |
-flax-vector-conversions=all to -flax-vector-conversions=integer."
This patch broke the Sanitizer buildbots. Please see the commit's
differential revision for more information
(https://reviews.llvm.org/D67678).
This reverts commit b72a8c65e4e34779b6bc9e466203f553f5294486.
(cherry picked from commit edd4398f4cd33a305afbca76ac4e6590e9337f4d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When Wrange-loop-analysis issues a diagnostic on a dependent type in a
template the diagnostic may not be valid for all instantiations. Therefore
the diagnostic is suppressed during the instantiation. Non dependent types
still issue a diagnostic.
The same can happen when using macros. Therefore the diagnostic is
disabled for macros.
Fixes https://bugs.llvm.org/show_bug.cgi?id=44556
Differential Revision: https://reviews.llvm.org/D73007
(cherry picked from commit 41fcd17250fa0526e4b7fd2c7df7721b0f79b683)
|
|
|
|
|
|
|
|
|
|
| |
After rGb4a99a061f517e60985667e39519f60186cbb469, passing a response file such as -Wp,@a.rsp wasn't working anymore because .rsp expansion happens inside clang's main() function.
This patch adds response file expansion in the -cc1 tool.
Differential Revision: https://reviews.llvm.org/D73120
(cherry picked from commit 68d7f06092e56b17eb0cddf560a9d9fe8afb7dd8)
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue was reported by @xazax.hun here: https://reviews.llvm.org/D69825#1827826
"This patch (D69825) breaks scan-build-py which parses the output of "-###" to get -cc1 command. There might be other tools with the same problems. Could we either remove (in-process) from CC1Command::Print or add a line break?
Having the last line as a valid invocation is valuable and there might be tools relying on that."
Differential Revision: https://reviews.llvm.org/D72982
(cherry picked from commit 133a7e631cee97965e310f0d110739217427fd3d)
|
|
|
|
|
|
|
| |
implementation of some builtin""
This should no longer be necessary after
cd4c65f91d5 "Add __warn_memset_zero_len builtin as a workaround for glibc issue"
|
|
|
|
|
|
|
|
|
| |
This reverts commit 921f871ac438175ca8fcfcafdfcfac4d7ddf3905 because it
causes libc++ code to trigger __warn_memset_zero_len.
See https://reviews.llvm.org/D71082.
(cherry picked from commit 3d210ed3d1880c615776b07d1916edb400c245a6)
|
|
|
|
|
|
|
| |
This reverts commit 23058f9dd4d7e18239fd63b6da52549514b45fda. It breaks
builds of cuda code somehow in some cases.
(cherry picked from commit 6b29aa21180cf14bfb619d38fc4826913cabfb66)
|
|
|
|
|
|
|
|
|
| |
Glibc issue: https://sourceware.org/bugzilla/show_bug.cgi?id=25399
The fix consist in considering the missing function as a builtin lowered to a nop.
Differential Revision: https://reviews.llvm.org/D72869
(cherry picked from commit d293417931d3a9d46799b42795988ca3b5cfd766)
|
|
|
|
| |
(cherry picked from commit b78e8e0d79c47a6698a0abc10a37b8a253cb6064)
|
|
|
|
|
|
|
|
| |
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.
(cherry picked from commit 45d70806f4386adfb62b0d75949a8aad58e0576f)
|
|
|
|
|
|
|
|
|
|
| |
expanded by the deduced pack.
We recently started also deducing the arity of separately-expanded packs
that are merely mentioned within the pack in question, which is
incorrect.
(cherry picked from commit e8f198dd9e9dabed8d50276465906e7c8827cada)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to -flax-vector-conversions=integer.
Summary:
See proposal on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html
Reviewers: SjoerdMeijer, eli.friedman
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67678
(cherry picked from commit b72a8c65e4e34779b6bc9e466203f553f5294486)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flags are clang's default UI is flags.
We can have an env var in addition to that, but in D69825 nobody has yet
mentioned why this needs an env var, so omit it for now. If someone
needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS
mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1
for example).
Also mention the cc1-in-process change in the release notes.
Also spruce up the test a bit so it actually tests something :)
Differential Revision: https://reviews.llvm.org/D72769
(cherry picked from commit 8e5018e990b701391e6c33ba85b012343df67272)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fdollars-in-identifiers flag.
Summary:
Previously, the -fdollars-in-identifiers flag allows the '$' symbol to be used
in an identifier but the universal character name equivalent '\u0024' is not
allowed.
This patch changes this, so that \u0024 is valid in identifiers.
Reviewers: rsmith, jordan_rose
Reviewed By: rsmith
Subscribers: dexonsmith, simoncook, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71758
|