Skip to content
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

Hygienize macros in the standard library #61629

Merged
merged 1 commit into from Jun 13, 2019

Conversation

Projects
None yet
8 participants
@petrochenkov
Copy link
Contributor

commented Jun 7, 2019

Same as #55597, but for all macros in the standard library.
Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site.
Technically this is a breaking change, so crater run would probably be useful.


One exception that is not hygienized is calls to panic!(...).
Macros defined in libcore do not want to call core::panic.
What they really want to call is either std::panic or core::panic depending on no_std settings.
EDIT: After some thought, recursive calls to panic from panic itself probably do want to use $crate (UPDATE: done).

Calling std::panic from macros defined in std and "whatever panic is in scope" from macros defined in libcore is probably even worse than always calling "whatever panic is in scope", so I kept the existing code.

The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to std::panic or core::panic using compiler magic.
Then standard library macros could delegate to this built-in macro.
The macro could be named panic too, that would fix #61567.
(This PR doesn't do that.)


cc #56389
cc #61567
Fixes #61699
r? @alexcrichton

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

commented Jun 7, 2019

@bors try

@bors

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2019

⌛️ Trying commit b5e00d8 with merge e212b7d...

bors added a commit that referenced this pull request Jun 7, 2019

Auto merge of #61629 - petrochenkov:stdmac, r=<try>
Hygienize macros in the standard library

Same as #55597, but for all macros in the standard library.
Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site.
Technically this is a breaking change, so crater run would probably be useful.

---

One exception that is not hygienized is calls to `panic!(...)`.
Macros defined in libcore do not want to call `core::panic`.
What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings.
EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate`.

Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse that always calling "whatever `panic` is in scope", so I kept the existing code.

The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic.
Then standard library macros could delegate to this built-in macro.
The macro could be named `panic` too, that would fix #61567.
(This PR doesn't do that.)

---
cc #56389
cc #61567
r? @alexcrichton
@bors

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2019

☀️ Try build successful - checks-travis
Build commit: e212b7d

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

commented Jun 7, 2019

@craterbot

This comment has been minimized.

Copy link
Collaborator

commented Jun 7, 2019

👌 Experiment pr-61629 created and queued.
🤖 Automatically detected try build e212b7d
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot

This comment has been minimized.

Copy link
Collaborator

commented Jun 7, 2019

🚧 Experiment pr-61629 is now running on agent aws-1.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@pietroalbini

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

@petrochenkov wait, does this need to be a cargo test run?

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2019

@pietroalbini
Yes.
The idea is that user code could previously shadow standard macros with its own macros with the same interface but different behavior.
This PR removes that possibility thus changing runtime behavior.

@matklad

This comment has been minimized.

Copy link
Member

commented Jun 9, 2019

Can this replace __rustc_unstable_column with crate::column as well?

$crate::panicking::panic(&($msg, file!(), line!(), __rust_unstable_column!()))

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

commented Jun 9, 2019

@matklad
column is a built-in macro, not standard library macro, so $crate::column won't work.

To call built-in macros reliably with $crate::mac!(...) we need to reexport them from the standard library first.
With 2018 edition and uniform paths it is generally possible, but there's a bug preventing reexports of built-in macros specifically.

@craterbot

This comment has been minimized.

Copy link
Collaborator

commented Jun 12, 2019

🎉 Experiment pr-61629 is completed!
📊 22 regressed and 11 fixed (60951 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Jun 12, 2019

This is looking good to me, and the crate run there looks all largely spurious to me, so I think we could probably go ahead and land this?

@petrochenkov petrochenkov force-pushed the petrochenkov:stdmac branch from b5e00d8 to 8fc9d13 Jun 12, 2019

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2019

Rebased/squashed.

Recursive calls from panic to itself are also hygienized.

@petrochenkov petrochenkov force-pushed the petrochenkov:stdmac branch from 8fc9d13 to eb09daa Jun 12, 2019

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Jun 12, 2019

@bors: r+

@bors

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

📌 Commit eb09daa has been approved by alexcrichton

@Centril

This comment has been minimized.

Copy link
Member

commented Jun 12, 2019

@bors rollup

Centril added a commit to Centril/rust that referenced this pull request Jun 12, 2019

Rollup merge of rust-lang#61629 - petrochenkov:stdmac, r=alexcrichton
Hygienize macros in the standard library

Same as rust-lang#55597, but for all macros in the standard library.
Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site.
Technically this is a breaking change, so crater run would probably be useful.

---

One exception that is not hygienized is calls to `panic!(...)`.
Macros defined in libcore do not want to call `core::panic`.
What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings.
EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done).

Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code.

The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic.
Then standard library macros could delegate to this built-in macro.
The macro could be named `panic` too, that would fix rust-lang#61567.
(This PR doesn't do that.)

---
cc rust-lang#56389
cc rust-lang#61567
Fixes rust-lang#61699
r? @alexcrichton

bors added a commit that referenced this pull request Jun 12, 2019

Auto merge of #61783 - Centril:rollup-r5u53z7, r=Centril
Rollup of 10 pull requests

Successful merges:

 - #60376 (Stabilize Option::xor)
 - #61398 (Stabilize copy_within)
 - #61629 (Hygienize macros in the standard library)
 - #61675 (Include frame pointer for bare metal RISC-V targets)
 - #61750 (Fix x.py install)
 - #61757 (Deprecate ONCE_INIT)
 - #61762 (rustbuild: fix libtest_stamp)
 - #61763 (ci: fix ci stats upload condition)
 - #61771 (Update cargo)
 - #61776 (Fix typos in error_codes)

Failed merges:

r? @ghost

Centril added a commit to Centril/rust that referenced this pull request Jun 12, 2019

Rollup merge of rust-lang#61629 - petrochenkov:stdmac, r=alexcrichton
Hygienize macros in the standard library

Same as rust-lang#55597, but for all macros in the standard library.
Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site.
Technically this is a breaking change, so crater run would probably be useful.

---

One exception that is not hygienized is calls to `panic!(...)`.
Macros defined in libcore do not want to call `core::panic`.
What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings.
EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done).

Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code.

The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic.
Then standard library macros could delegate to this built-in macro.
The macro could be named `panic` too, that would fix rust-lang#61567.
(This PR doesn't do that.)

---
cc rust-lang#56389
cc rust-lang#61567
Fixes rust-lang#61699
r? @alexcrichton

bors added a commit that referenced this pull request Jun 13, 2019

Auto merge of #61789 - Centril:rollup-hhyvopq, r=Centril
Rollup of 9 pull requests

Successful merges:

 - #60376 (Stabilize Option::xor)
 - #61398 (Stabilize copy_within)
 - #61629 (Hygienize macros in the standard library)
 - #61675 (Include frame pointer for bare metal RISC-V targets)
 - #61750 (Fix x.py install)
 - #61761 (Add an alias for x86_64-sun-solaris target tuple)
 - #61762 (rustbuild: fix libtest_stamp)
 - #61763 (ci: fix ci stats upload condition)
 - #61776 (Fix typos in error_codes)

Failed merges:

r? @ghost

@bors bors merged commit eb09daa into rust-lang:master Jun 13, 2019

1 of 2 checks passed

pr Build #20190612.17 failed
Details
Travis CI - Pull Request Build Passed
Details

@petrochenkov petrochenkov deleted the petrochenkov:stdmac branch Jun 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.