syntax: Unsupport `foo! bar { ... }` macros in the parser by petrochenkov · Pull Request #62258 · rust-lang/rust

petrochenkov · 2019-06-30T22:30:31Z

Their support in expansion was removed in #61606.

Also un-reserve macro_rules as a macro name, there's no ambiguity between macro_rules definitions and macro calls (it also wasn't reserved correctly).

cc rust-lang/wg-grammar#51

rust-highfive · 2019-06-30T22:30:34Z

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

Centril

r=me with or without nits.

Centril · 2019-06-30T23:34:05Z

r? @Centril

eddyb · 2019-07-01T06:55:57Z

cc @rust-lang/lang This PR lets one define macros named macro_rules which would be used for an invocation like macro_rules!(...), while macro_rules! foo {...} would still refer to the builtin macro.

While from an implementation point of view this seems reasonable (treating macro_rules! foo {...} as a special syntax and not a macro invocation), I do want to make sure this is not a compatibility hazard (in case we want to, say, allow something like macro foo = macro_rules! {...}; in the future).

That said, I think we can land this PR as-is, and revert it later if we really don't want to do this.

petrochenkov · 2019-07-01T07:41:05Z

Two notes:

macro_rules was already a special syntax, not a macro invocation, this PR doesn't change that

the "reservation" could be worked around by use foo as macro_rules previously

macro_rules! foo {() => (0)}use foo as macro_rules;fnmain(){println!("{}", macro_rules!());}

eddyb · 2019-07-01T08:39:43Z

@petrochenkov Oh, and that use wouldn't affect macro_rules! ident {...} syntax anyway?
I can see how that makes this PR even more of a slam-dunk.

Like I said, I think we should just land it and if anyone has any concerns, they can be raised async.

petrochenkov · 2019-07-01T09:13:16Z

Oh, and that use wouldn't affect macro_rules! ident {...} syntax anyway?

Yes, macro_rules in macro_rules! foo { ... } doesn't go through name resolution, since it's a context-dependent keyword like union and processed during parsing.
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=aa35ddb773e577d4d2b9842d3f0059d1

Unreserve `macro_rules` as a macro name

petrochenkov · 2019-07-01T09:58:28Z

@bors r=Centril

bors · 2019-07-01T09:58:30Z

📌 Commit d0dc41a has been approved by Centril

Centril · 2019-07-01T14:31:04Z

Removing nomination per @eddyb's note re. async and since the whole team was pinged.

(It's clear to me that this is a slam dunk)

syntax: Unsupport `foo! bar { ... }` macros in the parser Their support in expansion was removed in rust-lang#61606. Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly). cc rust-lang/wg-grammar#51

@ghost

Rollup of 17 pull requests Successful merges: - #62039 (Remove needless lifetimes (rustc)) - #62153 (Update the `rust-installer` submodule) - #62173 (rename InterpretCx -> InterpCx) - #62240 (wfcheck: resolve the type-vars in `AdtField` types) - #62249 (Use mem::take instead of mem::replace with default) - #62252 (Update mem::replace example to not be identical to mem::take) - #62258 (syntax: Unsupport `foo! bar { ... }` macros in the parser) - #62268 (Clean up inherent_impls) - #62287 (Use link attributes on extern "C" blocks with llvm-libuwind) - #62295 (miri realloc: do not require giving old size+align) - #62297 (refactor check_for_substitution) - #62316 (When possible without changing semantics, implement Iterator::last in terms of DoubleEndedIterator::next_back for types in liballoc and libcore.) - #62317 (Migrate `compile-pass` annotations to `build-pass`) - #62337 (Fix bucket in CPU usage script) - #62344 (simplify Option::get_or_insert) - #62346 (enable a few more tests in Miri and update the comment for others) - #62351 (remove bogus example from drop_in_place) Failed merges: r? @ghost

syntax: Unsupport `foo! bar { ... }` macros in the parser Their support in expansion was removed in rust-lang#61606. Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly). cc rust-lang/wg-grammar#51

@ghost

Rollup of 16 pull requests Successful merges: - #62039 (Remove needless lifetimes (rustc)) - #62173 (rename InterpretCx -> InterpCx) - #62240 (wfcheck: resolve the type-vars in `AdtField` types) - #62249 (Use mem::take instead of mem::replace with default) - #62252 (Update mem::replace example to not be identical to mem::take) - #62258 (syntax: Unsupport `foo! bar { ... }` macros in the parser) - #62268 (Clean up inherent_impls) - #62287 (Use link attributes on extern "C" blocks with llvm-libuwind) - #62295 (miri realloc: do not require giving old size+align) - #62297 (refactor check_for_substitution) - #62316 (When possible without changing semantics, implement Iterator::last in terms of DoubleEndedIterator::next_back for types in liballoc and libcore.) - #62317 (Migrate `compile-pass` annotations to `build-pass`) - #62337 (Fix bucket in CPU usage script) - #62344 (simplify Option::get_or_insert) - #62346 (enable a few more tests in Miri and update the comment for others) - #62351 (remove bogus example from drop_in_place) Failed merges: r? @ghost

This is now unsupported and treated as a hard syntax error. cc rust-lang/rust#62258.

rust-highfive assigned eddyb Jun 30, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 30, 2019

petrochenkov mentioned this pull request Jun 30, 2019
Should MacroCall include optional ident? rust-lang/wg-grammar#51
Open

petrochenkov force-pushed the idclean branch from 778f43e to e3779f1Compare June 30, 2019 23:03

Centril reviewed Jun 30, 2019
View reviewed changes

Comment threadsrc/libsyntax/parse/parser.rs Outdated
Comment threadsrc/libsyntax/parse/parser.rs Outdated

rust-highfive assigned Centril and unassigned eddyb Jun 30, 2019

eddyb added I-nominated T-lang Relevant to the language team labels Jul 1, 2019

petrochenkov added 2 commits July 1, 2019 12:20

syntax: Unsupport foo! bar { ... } macros in the parser
3f39dc1
Unreserve `macro_rules` as a macro name

Address review comments
d0dc41a

petrochenkov force-pushed the idclean branch from e3779f1 to d0dc41aCompare July 1, 2019 09:34

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 1, 2019

Centril removed the I-nominated label Jul 1, 2019

Centril mentioned this pull request Jul 1, 2019
Rollup of 12 pull requests #62271
Closed

Centril mentioned this pull request Jul 3, 2019
Rollup of 17 pull requests #62349
Closed

Centril mentioned this pull request Jul 3, 2019
Rollup of 18 pull requests #62352
Closed

Centril mentioned this pull request Jul 3, 2019
Rollup of 17 pull requests #62354
Closed

Centril mentioned this pull request Jul 3, 2019
Rollup of 16 pull requests #62355
Merged

bors merged commit d0dc41a into rust-lang:masterJul 4, 2019

petrochenkov deleted the idclean branch July 8, 2019 13:33

topecongiro added a commit to topecongiro/rustfmt that referenced this pull request Jul 28, 2019
Remove macros with optional ident
bdbe7a7
This is now unsupported and treated as a hard syntax error. cc rust-lang/rust#62258.

This was referenced Aug 24, 2019
Crater runs for Rust 1.38.0 #63628
Closed
[1.38] Regression: expected open delimiter #63889
Closed

EliseZeroTwo mentioned this pull request Dec 14, 2023
Better errors with bad/missing identifiers in MBEs #118939
Closed

Navigation Menu

Uh oh!

Uh oh!

syntax: Unsupport `foo! bar { ... }` macros in the parser - #62258

syntax: Unsupport `foo! bar { ... }` macros in the parser#62258
bors merged 2 commits into
rust-lang:masterfrom
petrochenkov:idclean

petrochenkov commented Jun 30, 2019

Uh oh!

rust-highfive commented Jun 30, 2019

Uh oh!

Centril left a comment

Uh oh!

Uh oh!

Uh oh!

Centril commented Jun 30, 2019

Uh oh!

eddyb commented Jul 1, 2019

Uh oh!

petrochenkov commented Jul 1, 2019

Uh oh!

eddyb commented Jul 1, 2019

Uh oh!

petrochenkov commented Jul 1, 2019•
edited
Loading

Uh oh!

petrochenkov commented Jul 1, 2019

Uh oh!

bors commented Jul 1, 2019

Uh oh!

Centril commented Jul 1, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

petrochenkov commented Jun 30, 2019

Uh oh!

rust-highfive commented Jun 30, 2019

Uh oh!

Centril left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Centril commented Jun 30, 2019

Uh oh!

eddyb commented Jul 1, 2019

Uh oh!

petrochenkov commented Jul 1, 2019

Uh oh!

eddyb commented Jul 1, 2019

Uh oh!

petrochenkov commented Jul 1, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

petrochenkov commented Jul 1, 2019

Uh oh!

bors commented Jul 1, 2019

Uh oh!

Centril commented Jul 1, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

petrochenkov commented Jul 1, 2019•
edited
Loading