2020-09-27 08:52:51 -05:00
|
|
|
// Regression tests for issue #55414, expansion happens in the value of a key-value attribute,
|
|
|
|
// and the expanded expression is more complex than simply a macro call.
|
|
|
|
|
|
|
|
// aux-build:key-value-expansion.rs
|
|
|
|
|
|
|
|
#![feature(rustc_attrs)]
|
|
|
|
|
|
|
|
extern crate key_value_expansion;
|
|
|
|
|
|
|
|
// Minimized test case.
|
|
|
|
|
|
|
|
macro_rules! bug {
|
|
|
|
($expr:expr) => {
|
|
|
|
#[rustc_dummy = $expr] // Any key-value attribute, not necessarily `doc`
|
|
|
|
struct S;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
// Any expressions containing macro call `X` that's more complex than `X` itself.
|
|
|
|
// Parentheses will work.
|
Overhaul `MacArgs::Eq`.
The value in `MacArgs::Eq` is currently represented as a `Token`.
Because of `TokenKind::Interpolated`, `Token` can be either a token or
an arbitrary AST fragment. In practice, a `MacArgs::Eq` starts out as a
literal or macro call AST fragment, and then is later lowered to a
literal token. But this is very non-obvious. `Token` is a much more
general type than what is needed.
This commit restricts things, by introducing a new type `MacArgsEqKind`
that is either an AST expression (pre-lowering) or an AST literal
(post-lowering). The downside is that the code is a bit more verbose in
a few places. The benefit is that makes it much clearer what the
possibilities are (though also shorter in some other places). Also, it
removes one use of `TokenKind::Interpolated`, taking us a step closer to
removing that variant, which will let us make `Token` impl `Copy` and
remove many "handle Interpolated" code paths in the parser.
Things to note:
- Error messages have improved. Messages like this:
```
unexpected token: `"bug" + "found"`
```
now say "unexpected expression", which makes more sense. Although
arbitrary expressions can exist within tokens thanks to
`TokenKind::Interpolated`, that's not obvious to anyone who doesn't
know compiler internals.
- In `parse_mac_args_common`, we no longer need to collect tokens for
the value expression.
2022-04-28 15:52:01 -05:00
|
|
|
bug!((column!())); //~ ERROR unexpected expression: `(7u32)`
|
2020-09-27 08:52:51 -05:00
|
|
|
|
|
|
|
// Original test case.
|
|
|
|
|
|
|
|
macro_rules! bug {
|
|
|
|
() => {
|
Overhaul `MacArgs::Eq`.
The value in `MacArgs::Eq` is currently represented as a `Token`.
Because of `TokenKind::Interpolated`, `Token` can be either a token or
an arbitrary AST fragment. In practice, a `MacArgs::Eq` starts out as a
literal or macro call AST fragment, and then is later lowered to a
literal token. But this is very non-obvious. `Token` is a much more
general type than what is needed.
This commit restricts things, by introducing a new type `MacArgsEqKind`
that is either an AST expression (pre-lowering) or an AST literal
(post-lowering). The downside is that the code is a bit more verbose in
a few places. The benefit is that makes it much clearer what the
possibilities are (though also shorter in some other places). Also, it
removes one use of `TokenKind::Interpolated`, taking us a step closer to
removing that variant, which will let us make `Token` impl `Copy` and
remove many "handle Interpolated" code paths in the parser.
Things to note:
- Error messages have improved. Messages like this:
```
unexpected token: `"bug" + "found"`
```
now say "unexpected expression", which makes more sense. Although
arbitrary expressions can exist within tokens thanks to
`TokenKind::Interpolated`, that's not obvious to anyone who doesn't
know compiler internals.
- In `parse_mac_args_common`, we no longer need to collect tokens for
the value expression.
2022-04-28 15:52:01 -05:00
|
|
|
bug!("bug" + stringify!(found)); //~ ERROR unexpected expression: `"bug" + "found"`
|
2020-09-27 08:52:51 -05:00
|
|
|
};
|
|
|
|
($test:expr) => {
|
2020-11-07 07:09:40 -06:00
|
|
|
#[doc = $test]
|
2020-09-27 08:52:51 -05:00
|
|
|
struct Test {}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
bug!();
|
|
|
|
|
|
|
|
// Test case from #66804.
|
|
|
|
|
|
|
|
macro_rules! doc_comment {
|
|
|
|
($x:expr) => {
|
2020-11-07 07:09:40 -06:00
|
|
|
#[doc = $x]
|
2020-09-27 08:52:51 -05:00
|
|
|
extern {}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
macro_rules! some_macro {
|
|
|
|
($t1: ty) => {
|
|
|
|
doc_comment! {format!("{coor}", coor = stringify!($t1)).as_str()}
|
Overhaul `MacArgs::Eq`.
The value in `MacArgs::Eq` is currently represented as a `Token`.
Because of `TokenKind::Interpolated`, `Token` can be either a token or
an arbitrary AST fragment. In practice, a `MacArgs::Eq` starts out as a
literal or macro call AST fragment, and then is later lowered to a
literal token. But this is very non-obvious. `Token` is a much more
general type than what is needed.
This commit restricts things, by introducing a new type `MacArgsEqKind`
that is either an AST expression (pre-lowering) or an AST literal
(post-lowering). The downside is that the code is a bit more verbose in
a few places. The benefit is that makes it much clearer what the
possibilities are (though also shorter in some other places). Also, it
removes one use of `TokenKind::Interpolated`, taking us a step closer to
removing that variant, which will let us make `Token` impl `Copy` and
remove many "handle Interpolated" code paths in the parser.
Things to note:
- Error messages have improved. Messages like this:
```
unexpected token: `"bug" + "found"`
```
now say "unexpected expression", which makes more sense. Although
arbitrary expressions can exist within tokens thanks to
`TokenKind::Interpolated`, that's not obvious to anyone who doesn't
know compiler internals.
- In `parse_mac_args_common`, we no longer need to collect tokens for
the value expression.
2022-04-28 15:52:01 -05:00
|
|
|
//~^ ERROR unexpected expression: `{
|
2020-09-27 08:52:51 -05:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
some_macro!(u8);
|
|
|
|
|
|
|
|
fn main() {}
|