2019-01-03 17:57:11 -06:00
|
|
|
error: suffixed literals are not allowed in attributes
|
2020-11-07 07:09:40 -06:00
|
|
|
--> $DIR/malformed-interpolated.rs:12:8
|
2019-01-03 17:57:11 -06:00
|
|
|
|
|
2019-05-09 19:00:51 -05:00
|
|
|
LL | check!(0u8);
|
|
|
|
|
| ^^^
|
2019-01-03 17:57:11 -06:00
|
|
|
|
|
2020-01-10 08:57:36 -06:00
|
|
|
= help: instead of using a suffixed literal (`1u8`, `1.0f32`, etc.), use an unsuffixed version (`1`, `1.0`, etc.)
|
2019-01-03 17:57:11 -06:00
|
|
|
|
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: `-0`
|
2020-11-07 07:09:40 -06:00
|
|
|
--> $DIR/malformed-interpolated.rs:13:8
|
2019-12-16 07:56:47 -06:00
|
|
|
|
|
2020-11-07 07:09:40 -06:00
|
|
|
LL | check!(-0);
|
|
|
|
|
| ^^
|
2019-01-03 17:57:11 -06:00
|
|
|
|
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: `0 + 0`
|
2020-11-07 07:09:40 -06:00
|
|
|
--> $DIR/malformed-interpolated.rs:14:8
|
2019-12-16 07:56:47 -06:00
|
|
|
|
|
2020-11-07 07:09:40 -06:00
|
|
|
LL | check!(0 + 0);
|
|
|
|
|
| ^^^^^
|
2019-01-03 17:57:11 -06:00
|
|
|
|
|
|
|
|
error: aborting due to 3 previous errors
|
|
|
|
|
|
