-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
test: cross-edition metavar fragment specifiers #129755
test: cross-edition metavar fragment specifiers #129755
Conversation
r? @chenyukang rustbot has assigned @chenyukang. Use |
Nominating for T-lang to get a gut check on what the desired behavior is here. |
This comment has been minimized.
This comment has been minimized.
For the record, I believe that this is totally fine behavior. The span of the identifier that is used for the nonterminal should be the thing that determines the edition, since it's coming from the edition that's "instantiating" the edition. It's otherwise a somewhat arbitrary choice, though. |
So regardless of how we want this to work, this is also how (edit: I misread the behavior of the test) |
errs note: I think I may have ended up changing my mind. We should consider whether we want to use the uninterpolated span of the nonterminal-kind's identifier. This would require fixing |
Something I realized is that the current behavior leaks the edition of the crate defining the macro. In our example, if the I think we probably want to change the behavior in this test. |
@rustbot labels -I-lang-nominated We discussed this in the lang call today. We agreed that the span of the token used to fill in the fragment specifier should be used for deciding the behavior. That is, if we have code like this in a Rust 2021 crate: #[macro_export]
macro_rules! make_matcher {
($name:ident, $fragment_type:ident, $d:tt) => {
#[macro_export]
macro_rules! $name {
($d _:$fragment_type) => { true };
(const { 0 }) => { false };
}
};
}
make_matcher!(is_expr_from_2021, expr, $); And code like this in a Rust 2024 crate: make_matcher!(is_expr_from_2024, expr, $); We would expect that We'd also like to fix this for |
f861467
to
e07b011
Compare
I actually don't think this is possible to implement, due to existing bugs (#85708). Namely, we have trouble determining the span of a nonterminal token (which is used to compute the edition) when there's extern crates involved. I would prefer if we decouple fixing this bug (both Re-lang-nominating to confirm this. @rustbot label: -S-waiting-on-review +S-waiting-on-team +I-lang-nominated |
I just pushed a change that adds coverage for |
While you're at it, can you squash that |
There's a subtle interaction between macros with metavar expressions and the edition-dependent fragment matching behavior. This test illustrates the current behavior when using macro-generating-macros across crate boundaries with different editions. Co-Authored-By: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Co-Authored-By: Eric Holk <eric@theincredibleholk.org>
In 2021 pat was changed to recognize `|` at the top level, with pat_param added to retain the old behavior. This means pat is subject to the same cross-edition behavior as expr will be in 2024. Co-authored-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
1e3d482
to
7653811
Compare
Done! |
This comment has been minimized.
This comment has been minimized.
I filed #130484 so as to be able to separately address this later. I'd suggest marking the test as: //@ known-bug: #130484 |
T-lang decided in the meeting that it would be fine for this to remain an open bug to decouple fixing this from the edition. r=me after updating the issue to have |
@bors r=compiler-errors |
…acros-between-edition, r=compiler-errors test: cross-edition metavar fragment specifiers There's a subtle interaction between macros with metavar expressions and the edition-dependent fragment matching behavior. This test illustrates the current behavior when using macro-generating-macros across crate boundaries with different editions. See the original suggestion rust-lang#123865 (comment) Tracking: - rust-lang#123742
…kingjubilee Rollup of 3 pull requests Successful merges: - rust-lang#129755 (test: cross-edition metavar fragment specifiers) - rust-lang#130511 (Support `char::encode_utf8` in const scenarios.) - rust-lang#130531 (Check params for unsafety in THIR) r? `@ghost` `@rustbot` modify labels: rollup
…ros-between-edition, r=compiler-errors test: cross-edition metavar fragment specifiers There's a subtle interaction between macros with metavar expressions and the edition-dependent fragment matching behavior. This test illustrates the current behavior when using macro-generating-macros across crate boundaries with different editions. See the original suggestion rust-lang#123865 (comment) Tracking: - rust-lang#123742
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
…llaumeGomez Rollup of 6 pull requests Successful merges: - rust-lang#129542 (Add regression test for rust-lang#129541) - rust-lang#129755 (test: cross-edition metavar fragment specifiers) - rust-lang#130566 (Break up compiletest `runtest.rs` into smaller helper modules) - rust-lang#130585 (Add tidy check for rustdoc templates to ensure the whitespace characters are all stripped) - rust-lang#130605 (Fix feature name in test) - rust-lang#130607 ([Clippy] Remove final std paths for diagnostic item) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#129755 - vincenzopalazzo:macros/recursive-macros-between-edition, r=compiler-errors test: cross-edition metavar fragment specifiers There's a subtle interaction between macros with metavar expressions and the edition-dependent fragment matching behavior. This test illustrates the current behavior when using macro-generating-macros across crate boundaries with different editions. See the original suggestion rust-lang#123865 (comment) Tracking: - rust-lang#123742
There's a subtle interaction between macros with metavar expressions and the edition-dependent fragment matching behavior. This test illustrates the current behavior when using macro-generating-macros across crate boundaries with different editions.
See the original suggestion #123865 (comment)
Tracking:
expr
macro fragment specifier for Rust 2024 #123742