Uh oh!
There was an error while loading. Please reload this page.
Forbid type parameters and global paths in macro invocations - #34495
Conversation
jseyfried
commented
Jun 27, 2016
This probably needs a crater run. |
eddyb
commented
Jun 27, 2016
Starting a crater run. |
eddyb
commented
Jun 27, 2016
Crater report shows 0 regressions. |
eddyb
commented
Jun 27, 2016
LGTM. cc @nrc@Manishearth |
Manishearth
commented
Jun 27, 2016
LGTM too. Since this doesn't actually change the grammar, it doesn't need to be part of the breaking batch either. |
jseyfried
commented
Jun 27, 2016
@eddyb r=you? |
eddyb
commented
Jun 27, 2016
@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). |
nrc
commented
Jun 27, 2016
LGTM @bors: r=eddyb |
bors
commented
Jun 27, 2016
📌 Commit b4611b1 has been approved by |
…ons, r=eddyb Forbid type parameters and global paths in macro invocations Fixesrust-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