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

resolve: Do not error on access to proc macros imported with `#[macro_use]` #53461

Merged
merged 1 commit into from Sep 16, 2018

Conversation

Projects
None yet
10 participants
@petrochenkov
Contributor

petrochenkov commented Aug 17, 2018

This error is artificial, but previously, when #[macro_use] extern crate x; was stable, but non-derive proc macros were not, it worked like kind of a feature gate. Now both features are stable, so the error is no longer necessary.

This PR simplifies how #[macro_use] extern crate x; works - it takes all items from macro namespace of x's root and puts them into macro prelude from which they all can now be accessed.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Aug 17, 2018

Collaborator

r? @aturon

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

Collaborator

rust-highfive commented Aug 17, 2018

r? @aturon

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

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov
Contributor

petrochenkov commented Aug 17, 2018

@rust-highfive rust-highfive assigned alexcrichton and unassigned aturon Aug 17, 2018

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 20, 2018

Member

While this seems plausible to me, I'd defer to @rust-lang/lang in this regard as it's moreso a language change they'd likely wish to discuss.

Folks on @rust-lang/lang, how do you feel about #[macro_use], a hopefully legacy attribute soon, working for new shiny new procedural macro attributes we've stabilized?

Member

alexcrichton commented Aug 20, 2018

While this seems plausible to me, I'd defer to @rust-lang/lang in this regard as it's moreso a language change they'd likely wish to discuss.

Folks on @rust-lang/lang, how do you feel about #[macro_use], a hopefully legacy attribute soon, working for new shiny new procedural macro attributes we've stabilized?

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 20, 2018

Member

Given that we're moving towards using use for macros, and use works for procedural macros, do we want to make #[macro_use] work for this?

Member

joshtriplett commented Aug 20, 2018

Given that we're moving towards using use for macros, and use works for procedural macros, do we want to make #[macro_use] work for this?

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Aug 20, 2018

Contributor

Given that #[macro_use] extern crate ... is being retired, I'd say that it largely doesn't matter from language usability point of view whether this case is allowed or not.
My primary motivation for doing this is simplification of the rules and removal of technical debt from the compiler.

Contributor

petrochenkov commented Aug 20, 2018

Given that #[macro_use] extern crate ... is being retired, I'd say that it largely doesn't matter from language usability point of view whether this case is allowed or not.
My primary motivation for doing this is simplification of the rules and removal of technical debt from the compiler.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 21, 2018

Member

@petrochenkov Fair enough. Sounds reasonable to me.

Member

joshtriplett commented Aug 21, 2018

@petrochenkov Fair enough. Sounds reasonable to me.

@Centril

This comment has been minimized.

Show comment
Hide comment
@Centril

Centril Aug 21, 2018

Contributor

I also think it sounds reasonable :)
...we should discuss this further on the meeting,
...but to expedite things, let's:

@rfcbot fcp merge

Contributor

Centril commented Aug 21, 2018

I also think it sounds reasonable :)
...we should discuss this further on the meeting,
...but to expedite things, let's:

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Aug 21, 2018

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot commented Aug 21, 2018

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Aug 21, 2018

Contributor

☔️ The latest upstream changes (presumably #53471) made this pull request unmergeable. Please resolve the merge conflicts.

Contributor

bors commented Aug 21, 2018

☔️ The latest upstream changes (presumably #53471) made this pull request unmergeable. Please resolve the merge conflicts.

@scottmcm

This comment has been minimized.

Show comment
Hide comment
@scottmcm

scottmcm Sep 6, 2018

Member

If this is just allowing the compiler to delete code, not changing idioms,

@rfcbot reviewed

Member

scottmcm commented Sep 6, 2018

If this is just allowing the compiler to delete code, not changing idioms,

@rfcbot reviewed

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Sep 6, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot commented Sep 6, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Sep 16, 2018

The final comment period, with a disposition to merge, as per the review above, is now complete.

rfcbot commented Sep 16, 2018

The final comment period, with a disposition to merge, as per the review above, is now complete.

@petrochenkov

This comment has been minimized.

Show comment
Hide comment
@petrochenkov

petrochenkov Sep 16, 2018

Contributor

Yay, FCP complete.
@bors r=alexcrichton

Contributor

petrochenkov commented Sep 16, 2018

Yay, FCP complete.
@bors r=alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 16, 2018

Contributor

📌 Commit e411bb3 has been approved by alexcrichton

Contributor

bors commented Sep 16, 2018

📌 Commit e411bb3 has been approved by alexcrichton

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 16, 2018

Contributor

⌛️ Testing commit e411bb3 with merge cb6d2df...

Contributor

bors commented Sep 16, 2018

⌛️ Testing commit e411bb3 with merge cb6d2df...

bors added a commit that referenced this pull request Sep 16, 2018

Auto merge of #53461 - petrochenkov:pmu, r=alexcrichton
resolve: Do not error on access to proc macros imported with `#[macro_use]`

This error is artificial, but previously, when `#[macro_use] extern crate x;` was stable, but non-derive proc macros were not, it worked like kind of a feature gate. Now both features are stable, so the error is no longer necessary.

This PR simplifies how `#[macro_use] extern crate x;` works - it takes all items from macro namespace of `x`'s root and puts them into macro prelude from which they all can now be accessed.
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 16, 2018

Contributor

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing cb6d2df to master...

Contributor

bors commented Sep 16, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing cb6d2df to master...

@bors bors merged commit e411bb3 into rust-lang:master Sep 16, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment