-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ICE deducing constrained components of member pointer type #57958
Comments
@llvm/issue-subscribers-clang-frontend |
@llvm/issue-subscribers-c-2b |
Got it, thanks. Looking at this plus one other regression from the deferred concepts instantiation patch, on Monday |
Simplified: https://godbolt.org/z/f6MEcfz8z. template<class> concept C = true;
template<int> constexpr bool v = [](C auto) { return true; }(0);
int _ = v<0>; This is rejected, but should be valid: https://godbolt.org/z/qeGjaW1v5. template<class> concept C = true;
template<int> constexpr bool v = [](C auto...) { return true; }(0);
int _ = v<0>;
|
Ok then, those look similar to what we saw from an additional reported bug, I suspect the instantiation setup for a lambda has a bug in it. The improper rejection is for about the same reason, it looks like we're not setting up the instantiation correctly for lambdas in certain situations. It is at least similar (if not identical) to the issue that @davidstone reported, so hopefully they won't take too long to debug. Thank you very much for the report, and the minimization. |
Patch up for review here: https://reviews.llvm.org/D134874 Took a little longer than I wish it did, it required a significant refactor of some pretty crufty/old code. |
As fallout of the Deferred Concept Instantiation patch (babdef2), we got a number of reports of a regression, where we asserted when instantiating a constraint on a generic lambda inside of a variable template. See: #57958 The problem was that getTemplateInstantiationArgs function only walked up declaration contexts, and missed that this is not necessarily the case with a lambda (which can ALSO be in a separate context). This patch refactors the getTemplateInstantiationArgs function in a way that is hopefully more readable, and fixes the problem with the concepts on a generic lambda. Differential Revision: https://reviews.llvm.org/D134874
As fallout of the Deferred Concept Instantiation patch (babdef2), we got a number of reports of a regression, where we asserted when instantiating a constraint on a generic lambda inside of a variable template. See: llvm/llvm-project#57958 The problem was that getTemplateInstantiationArgs function only walked up declaration contexts, and missed that this is not necessarily the case with a lambda (which can ALSO be in a separate context). This patch refactors the getTemplateInstantiationArgs function in a way that is hopefully more readable, and fixes the problem with the concepts on a generic lambda. Differential Revision: https://reviews.llvm.org/D134874
See https://godbolt.org/z/oacKbYb48.
Output:
The following works:
The text was updated successfully, but these errors were encountered: