-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Forbid type parameters and global paths in macro invocations #34495
Forbid type parameters and global paths in macro invocations #34495
Conversation
This probably needs a crater run. |
Starting a crater run. |
Crater report shows 0 regressions. |
LGTM. cc @nrc @Manishearth |
LGTM too. Since this doesn't actually change the grammar, it doesn't need to be part of the breaking batch either. |
@eddyb r=you? |
@jseyfried I'd like to hear back from another compiler/lang team member, like @nrc or @nikomatsakis (but niko is on vacation right now and might not respond for a while). Or maybe we should require that, e.g. for language breaking changes, you notify @rust-lang/lang. |
@eddyb ok, makes sense -- no hurry. We usually land clear bug fixes that cause no measurable breakage in practice without much discussion (perhaps we shouldn't). |
LGTM @bors: r=eddyb |
📌 Commit b4611b1 has been approved by |
…ons, r=eddyb Forbid type parameters and global paths in macro invocations Fixes rust-lang#28558. This is a [breaking-change]. For example, the following would break: ```rust macro_rules! m { () => { () } } fn main() { m::<T>!(); // Type parameters are no longer allowed in macro invocations ::m!(); // Global paths are no longer allowed in macro invocations } ``` Any breakage can be fixed by removing the type parameters or the leading `::` (respectively). r? @eddyb
Fixes #28558.
This is a [breaking-change]. For example, the following would break:
Any breakage can be fixed by removing the type parameters or the leading
::
(respectively).r? @eddyb