-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Check access control for the generic requirements of subscripts and typealiases #23726
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
Check access control for the generic requirements of subscripts and typealiases #23726
Conversation
Also oops. This one was a little more involved because the requirements on a generic typealias don't always carry a Type anymore; sometimes all you have is the TypeRepr. That should still be okay in practice as long as we don't start doing that for var/let, which can have part of a type be inferred but not all of it.
@swift-ci Please test |
@swift-ci Please test source compatibility |
@swift-ci Please smoke test compiler performance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think long term, we'll want this kind of thing to kick off requests to get referenced decls from where clauses, etc. Right now there's an ordering dependency between having evaluated certain requests and running the code here because it relies in the decl being bound in the TypeReprs, which is fragile. Ideally we'd remove the bound decl from IdentTypeRepr altogether.
The where clause logic is already doing that, but the inherited types aren't going through that logic. |
…y-name Check access control for the generic requirements of subscripts and typealiases (cherry picked from commit 4dcea1c)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
downgradeToWarning = DowngradeToWarning::Yes; | ||
|
||
auto diagID = diag::generic_param_usable_from_inline; | ||
if (downgradeToWarning == DowngradeToWarning::Yes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't do it in this PR even if you hadn't merged it already, but it might make sense to build something in to the DiagnosticEngine
that downgrades errors to warnings if the language version is not high enough.
TC.diagnoseLanguageChange(/*after:*/5, owner, diag::generic_param_usable_from_inline ...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's come up before. The main barrier in this case is that the text for these is slightly different (one is phrased as "oh, you shouldn't do this" and the other is "this doesn't work"), but maybe that could be abstracted out too.
Oops.
This is a little more involved than it should have been because the requirements on a generic typealias don't always carry a Type anymore; sometimes all you have is the TypeRepr. That should still be okay in practice as long as we don't start doing that for var/let, which can have part of a type be inferred but not all of it.
We don't have an idiom for "this should be an error in the next
-swift-version
" yet. Maybe it should be 9999, like we're using in the standard library for Apple OS availability?