mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
01c7118fa9
rust/tests/ui/attributes/key-value-expansion.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

31 lines
968 B
Plaintext
Raw Normal View History

Improve an error involving attribute values. Attribute values must be literals. The error you get when that doesn't hold is pretty bad, e.g.: ``` unexpected expression: 1 + 1 ``` You also get the same error if the attribute value is a literal, but an invalid literal, e.g.: ``` unexpected expression: "foo"suffix ``` This commit does two things. - Changes the error message to "attribute value must be a literal", which gives a better idea of what the problem is and how to fix it. It also no longer prints the invalid expression, because the carets below highlight it anyway. - Separates the "not a literal" case from the "invalid literal" case. Which means invalid literals now get the specific error at the literal level, rather than at the attribute level.
2023-12-11 16:55:50 -06:00
error: attribute value must be a literal
Accept arbitrary expressions in key-value attributes at parse time
2020-11-07 07:09:40 -06:00
--> $DIR/key-value-expansion.rs:21:6
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
|
LL | bug!((column!()));
Accept arbitrary expressions in key-value attributes at parse time
2020-11-07 07:09:40 -06:00
| ^^^^^^^^^^^
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
Improve an error involving attribute values. Attribute values must be literals. The error you get when that doesn't hold is pretty bad, e.g.: ``` unexpected expression: 1 + 1 ``` You also get the same error if the attribute value is a literal, but an invalid literal, e.g.: ``` unexpected expression: "foo"suffix ``` This commit does two things. - Changes the error message to "attribute value must be a literal", which gives a better idea of what the problem is and how to fix it. It also no longer prints the invalid expression, because the carets below highlight it anyway. - Separates the "not a literal" case from the "invalid literal" case. Which means invalid literals now get the specific error at the literal level, rather than at the attribute level.
2023-12-11 16:55:50 -06:00
error: attribute value must be a literal
Accept arbitrary expressions in key-value attributes at parse time
2020-11-07 07:09:40 -06:00
--> $DIR/key-value-expansion.rs:27:14
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
|
Accept arbitrary expressions in key-value attributes at parse time
2020-11-07 07:09:40 -06:00
LL | bug!("bug" + stringify!(found));
| ^^^^^^^^^^^^^^^^^^^^^^^^^
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
...
LL | bug!();
Bless tests
2021-10-14 13:28:28 -05:00
| ------ in this macro invocation
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
|
Show macro name in 'this error originates in macro' message When there are multiple macros in use, it can be difficult to tell which one was responsible for producing an error.
2021-02-13 13:52:25 -06:00
= note: this error originates in the macro `bug` (in Nightly builds, run with -Z macro-backtrace for more info)
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
Improve an error involving attribute values. Attribute values must be literals. The error you get when that doesn't hold is pretty bad, e.g.: ``` unexpected expression: 1 + 1 ``` You also get the same error if the attribute value is a literal, but an invalid literal, e.g.: ``` unexpected expression: "foo"suffix ``` This commit does two things. - Changes the error message to "attribute value must be a literal", which gives a better idea of what the problem is and how to fix it. It also no longer prints the invalid expression, because the carets below highlight it anyway. - Separates the "not a literal" case from the "invalid literal" case. Which means invalid literals now get the specific error at the literal level, rather than at the attribute level.
2023-12-11 16:55:50 -06:00
error: attribute value must be a literal
Accept arbitrary expressions in key-value attributes at parse time
2020-11-07 07:09:40 -06:00
--> $DIR/key-value-expansion.rs:48:23
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
|
Accept arbitrary expressions in key-value attributes at parse time
2020-11-07 07:09:40 -06:00
LL | doc_comment! {format!("{coor}", coor = stringify!($t1)).as_str()}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
...
LL | some_macro!(u8);
Bless tests
2021-10-14 13:28:28 -05:00
| --------------- in this macro invocation
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
|
Show macro name in 'this error originates in macro' message When there are multiple macros in use, it can be difficult to tell which one was responsible for producing an error.
2021-02-13 13:52:25 -06:00
= note: this error originates in the macro `some_macro` (in Nightly builds, run with -Z macro-backtrace for more info)
Expand `NtExpr` tokens only in key-value attributes
2020-09-27 08:52:51 -05:00
error: aborting due to 3 previous errors
Reference in New Issue Copy Permalink