nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-23 23:34:48 +00:00
Code Issues Packages Projects Releases Wiki Activity
9491f18c5d
rust/src/test/ui/lint/suggestions.stderr

110 lines
3.4 KiB
Plaintext
Raw Normal View History

Make WhileTrue into an EarlyLintPass lint.
2019-06-21 23:30:24 +00:00
warning: denote infinite loops with `loop { ... }`
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:42:5
Make WhileTrue into an EarlyLintPass lint.
2019-06-21 23:30:24 +00:00
|
LL | while true {
| ^^^^^^^^^^ help: use `loop`
|
normalize use of backticks in compiler messages for librustc/lint https://github.com/rust-lang/rust/issues/60532
2019-07-16 20:17:38 +00:00
= note: `#[warn(while_true)]` on by default
Make WhileTrue into an EarlyLintPass lint.
2019-06-21 23:30:24 +00:00
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 06:52:51 +00:00
warning: unnecessary parentheses around assigned value
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:45:31
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 06:52:51 +00:00
|
in which unused-parens suggestions heed what the user actually wrote Aaron Hill pointed out that unnecessary parens around a macro call (paradigmatically, `format!`) yielded a suggestion of hideous macro-expanded code. (The slightly unusual choice of using the pretty-printer to compose suggestions was quite recently commented on in the commit message for 1081bbbfc ("abolish ICE when pretty-printing async block"), but without any grounds to condemn it as a 𝘣𝘢𝘥 choice. Hill's report provides the grounds.) `span_to_snippet` is fallable as far as the type system is concerned (because, who knows, macros or something), so the pretty-printing can live on in the oft-neglected `else` branch. Resolves #55109.
2018-10-17 04:36:02 +00:00
LL | let mut registry_no = (format!("NX-{}", 74205));
| ^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 06:52:51 +00:00
|
Normalise notes with the/is
2020-01-22 23:57:38 +00:00
note: the lint level is defined here
Remove licenses
2018-12-25 15:56:47 +00:00
--> $DIR/suggestions.rs:3:21
Add several lints into `unused` lint group Remove a couple of obsolete lints
2017-10-20 21:00:57 +00:00
|
Update UI tests
2018-02-23 00:42:32 +00:00
LL | #![warn(unused_mut, unused_parens)] // UI tests pass `-A unused`—see Issue #43896
Add several lints into `unused` lint group Remove a couple of obsolete lints
2017-10-20 21:00:57 +00:00
| ^^^^^^^^^^^^^
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 06:52:51 +00:00
rustc: Remove `used_mut_nodes` from `TyCtxt` This updates the borrowck query to return a result, and this result is then used to incrementally check for unused mutable nodes given sets of all the used mutable nodes. Closes #42384
2017-09-15 19:49:10 +00:00
warning: variable does not need to be mutable
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:45:13
rustc: Remove `used_mut_nodes` from `TyCtxt` This updates the borrowck query to return a result, and this result is then used to incrementally check for unused mutable nodes given sets of all the used mutable nodes. Closes #42384
2017-09-15 19:49:10 +00:00
|
in which unused-parens suggestions heed what the user actually wrote Aaron Hill pointed out that unnecessary parens around a macro call (paradigmatically, `format!`) yielded a suggestion of hideous macro-expanded code. (The slightly unusual choice of using the pretty-printer to compose suggestions was quite recently commented on in the commit message for 1081bbbfc ("abolish ICE when pretty-printing async block"), but without any grounds to condemn it as a 𝘣𝘢𝘥 choice. Hill's report provides the grounds.) `span_to_snippet` is fallable as far as the type system is concerned (because, who knows, macros or something), so the pretty-printing can live on in the oft-neglected `else` branch. Resolves #55109.
2018-10-17 04:36:02 +00:00
LL | let mut registry_no = (format!("NX-{}", 74205));
| ----^^^^^^^^^^^
rustc: Remove `used_mut_nodes` from `TyCtxt` This updates the borrowck query to return a result, and this result is then used to incrementally check for unused mutable nodes given sets of all the used mutable nodes. Closes #42384
2017-09-15 19:49:10 +00:00
| |
| help: remove this `mut`
|
Normalise notes with the/is
2020-01-22 23:57:38 +00:00
note: the lint level is defined here
Remove licenses
2018-12-25 15:56:47 +00:00
--> $DIR/suggestions.rs:3:9
rustc: Remove `used_mut_nodes` from `TyCtxt` This updates the borrowck query to return a result, and this result is then used to incrementally check for unused mutable nodes given sets of all the used mutable nodes. Closes #42384
2017-09-15 19:49:10 +00:00
|
Update UI tests
2018-02-23 00:42:32 +00:00
LL | #![warn(unused_mut, unused_parens)] // UI tests pass `-A unused`—see Issue #43896
rustc: Remove `used_mut_nodes` from `TyCtxt` This updates the borrowck query to return a result, and this result is then used to incrementally check for unused mutable nodes given sets of all the used mutable nodes. Closes #42384
2017-09-15 19:49:10 +00:00
| ^^^^^^^^^^
Consider all whitespace when preparing span
2018-01-23 18:54:57 +00:00
warning: variable does not need to be mutable
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:51:13
Consider all whitespace when preparing span
2018-01-23 18:54:57 +00:00
|
Update UI tests
2018-02-23 00:42:32 +00:00
LL | let mut
Consider all whitespace when preparing span
2018-01-23 18:54:57 +00:00
| _____________^
| |_____________|
| ||
Update UI tests
2018-02-23 00:42:32 +00:00
LL | || b = 1;
Consider all whitespace when preparing span
2018-01-23 18:54:57 +00:00
| ||____________-^
| |____________|
| help: remove this `mut`
normalize use of backticks in compiler messages for librustc_lint
2019-07-18 22:05:23 +00:00
error: const items should never be `#[no_mangle]`
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:5:14
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
|
private no-mangle lints: help hint note if visibility modifier is `pub` If the item is `pub`, one imagines users being confused as to why it's not reachable/exported; a code suggestion is beyond our local knowledge here, but we can at least offer a prose hint. (Thanks to Vadim Petrochenkov for shooting down the present author's original bad idea for the note text.) While we're here, use proper HELP expectations instead of ad hoc comments to communicate (and now, enforce) the expected suggestions in test/ui/lint/suggestions.rs.
2018-06-28 05:50:24 +00:00
LL | #[no_mangle] const DISCOVERY: usize = 1;
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
| -----^^^^^^^^^^^^^^^^^^^^^^
| |
| help: try a static value: `pub static`
|
normalize use of backticks in compiler messages for librustc/lint https://github.com/rust-lang/rust/issues/60532
2019-07-16 20:17:38 +00:00
= note: `#[deny(no_mangle_const_items)]` on by default
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
Update tests Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-15 22:26:36 +00:00
warning: functions generic over types or consts must be mangled
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:11:1
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
|
private no-mangle lints: help hint note if visibility modifier is `pub` If the item is `pub`, one imagines users being confused as to why it's not reachable/exported; a code suggestion is beyond our local knowledge here, but we can at least offer a prose hint. (Thanks to Vadim Petrochenkov for shooting down the present author's original bad idea for the note text.) While we're here, use proper HELP expectations instead of ad hoc comments to communicate (and now, enforce) the expected suggestions in test/ui/lint/suggestions.rs.
2018-06-28 05:50:24 +00:00
LL | #[no_mangle]
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
| ------------ help: remove this attribute
Update tests
2019-03-09 12:03:44 +00:00
LL |
Update UI tests
2018-02-23 00:42:32 +00:00
LL | pub fn defiant<T>(_t: T) {}
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
normalize use of backticks in compiler messages for librustc/lint https://github.com/rust-lang/rust/issues/60532
2019-07-16 20:17:38 +00:00
= note: `#[warn(no_mangle_generic_items)]` on by default
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
Update tests
2019-03-13 01:55:37 +00:00
warning: the `warp_factor:` in this pattern is redundant
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:57:23
Update tests
2019-03-13 01:55:37 +00:00
|
LL | Equinox { warp_factor: warp_factor } => {}
Tweak non_shorthand_field_patterns' suggestion
2019-12-21 22:59:38 +00:00
| ^^^^^^^^^^^^^^^^^^^^^^^^ help: use shorthand field pattern: `warp_factor`
Update tests
2019-03-13 01:55:37 +00:00
|
normalize use of backticks in compiler messages for librustc/lint https://github.com/rust-lang/rust/issues/60532
2019-07-16 20:17:38 +00:00
= note: `#[warn(non_shorthand_field_patterns)]` on by default
Update tests
2019-03-13 01:55:37 +00:00
normalize use of backticks in compiler messages for librustc_lint
2019-07-18 22:05:23 +00:00
error: const items should never be `#[no_mangle]`
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:21:18
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
|
rustc: Allow `#[no_mangle]` anywhere in a crate This commit updates the compiler to allow the `#[no_mangle]` (and `#[export_name]` attributes) to be located anywhere within a crate. These attributes are unconditionally processed, causing the compiler to always generate an exported symbol with the appropriate name. After some discussion on #54135 it was found that not a great reason this hasn't been allowed already, and it seems to match the behavior that many expect! Previously the compiler would only export a `#[no_mangle]` symbol if it were *publicly reachable*, meaning that it itself is `pub` and it's otherwise publicly reachable from the root of the crate. This new definition is that `#[no_mangle]` *is always reachable*, no matter where it is in a crate or whether it has `pub` or not. This should make it much easier to declare an exported symbol with a known and unique name, even when it's an internal implementation detail of the crate itself. Note that these symbols will persist beyond LTO as well, always making their way to the linker. Along the way this commit removes the `private_no_mangle_functions` lint (also for statics) as there's no longer any need to lint these situations. Furthermore a good number of tests were updated now that symbol visibility has been changed. Closes #54135
2018-09-21 22:58:11 +00:00
LL | #[no_mangle] pub const DAUNTLESS: bool = true;
| ---------^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: try a static value: `pub static`
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
Update tests Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-15 22:26:36 +00:00
warning: functions generic over types or consts must be mangled
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:24:18
private no-mangle lints: help hint note if visibility modifier is `pub` If the item is `pub`, one imagines users being confused as to why it's not reachable/exported; a code suggestion is beyond our local knowledge here, but we can at least offer a prose hint. (Thanks to Vadim Petrochenkov for shooting down the present author's original bad idea for the note text.) While we're here, use proper HELP expectations instead of ad hoc comments to communicate (and now, enforce) the expected suggestions in test/ui/lint/suggestions.rs.
2018-06-28 05:50:24 +00:00
|
rustc: Allow `#[no_mangle]` anywhere in a crate This commit updates the compiler to allow the `#[no_mangle]` (and `#[export_name]` attributes) to be located anywhere within a crate. These attributes are unconditionally processed, causing the compiler to always generate an exported symbol with the appropriate name. After some discussion on #54135 it was found that not a great reason this hasn't been allowed already, and it seems to match the behavior that many expect! Previously the compiler would only export a `#[no_mangle]` symbol if it were *publicly reachable*, meaning that it itself is `pub` and it's otherwise publicly reachable from the root of the crate. This new definition is that `#[no_mangle]` *is always reachable*, no matter where it is in a crate or whether it has `pub` or not. This should make it much easier to declare an exported symbol with a known and unique name, even when it's an internal implementation detail of the crate itself. Note that these symbols will persist beyond LTO as well, always making their way to the linker. Along the way this commit removes the `private_no_mangle_functions` lint (also for statics) as there's no longer any need to lint these situations. Furthermore a good number of tests were updated now that symbol visibility has been changed. Closes #54135
2018-09-21 22:58:11 +00:00
LL | #[no_mangle] pub fn val_jean<T>() {}
| ------------ ^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: remove this attribute
in which the private no-mangle lints receive a valued lesson in humility The incompetent fool who added these suggestions in 38e5a964f2 apparently thought it was safe to assume that, because the offending function or static was unreachable, it would therefore have not have any existing visibility modifiers, making it safe for us to unconditionally suggest inserting `pub`. This isn't true. This resolves #47383.
2018-01-16 02:32:18 +00:00
normalize use of backticks in compiler messages for librustc_lint
2019-07-18 22:05:23 +00:00
error: const items should never be `#[no_mangle]`
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:29:18
in which the private no-mangle lints receive a valued lesson in humility The incompetent fool who added these suggestions in 38e5a964f2 apparently thought it was safe to assume that, because the offending function or static was unreachable, it would therefore have not have any existing visibility modifiers, making it safe for us to unconditionally suggest inserting `pub`. This isn't true. This resolves #47383.
2018-01-16 02:32:18 +00:00
|
rustc: Allow `#[no_mangle]` anywhere in a crate This commit updates the compiler to allow the `#[no_mangle]` (and `#[export_name]` attributes) to be located anywhere within a crate. These attributes are unconditionally processed, causing the compiler to always generate an exported symbol with the appropriate name. After some discussion on #54135 it was found that not a great reason this hasn't been allowed already, and it seems to match the behavior that many expect! Previously the compiler would only export a `#[no_mangle]` symbol if it were *publicly reachable*, meaning that it itself is `pub` and it's otherwise publicly reachable from the root of the crate. This new definition is that `#[no_mangle]` *is always reachable*, no matter where it is in a crate or whether it has `pub` or not. This should make it much easier to declare an exported symbol with a known and unique name, even when it's an internal implementation detail of the crate itself. Note that these symbols will persist beyond LTO as well, always making their way to the linker. Along the way this commit removes the `private_no_mangle_functions` lint (also for statics) as there's no longer any need to lint these situations. Furthermore a good number of tests were updated now that symbol visibility has been changed. Closes #54135
2018-09-21 22:58:11 +00:00
LL | #[no_mangle] pub(crate) const VETAR: bool = true;
| ----------------^^^^^^^^^^^^^^^^^^^^
private no-mangle lints: issue suggestion for restricted visibility This is probably quite a lot less likely to come up in practice than the "inherited" (no visibility keyword) case, but now that we have visibility spans in the HIR, we can do this, and it presumably doesn't hurt to be exhaustive. (Who can say but that the attention to detail just might knock someone's socks off, someday, somewhere?) This is inspired by #47383.
2018-06-28 05:30:23 +00:00
| |
rustc: Allow `#[no_mangle]` anywhere in a crate This commit updates the compiler to allow the `#[no_mangle]` (and `#[export_name]` attributes) to be located anywhere within a crate. These attributes are unconditionally processed, causing the compiler to always generate an exported symbol with the appropriate name. After some discussion on #54135 it was found that not a great reason this hasn't been allowed already, and it seems to match the behavior that many expect! Previously the compiler would only export a `#[no_mangle]` symbol if it were *publicly reachable*, meaning that it itself is `pub` and it's otherwise publicly reachable from the root of the crate. This new definition is that `#[no_mangle]` *is always reachable*, no matter where it is in a crate or whether it has `pub` or not. This should make it much easier to declare an exported symbol with a known and unique name, even when it's an internal implementation detail of the crate itself. Note that these symbols will persist beyond LTO as well, always making their way to the linker. Along the way this commit removes the `private_no_mangle_functions` lint (also for statics) as there's no longer any need to lint these situations. Furthermore a good number of tests were updated now that symbol visibility has been changed. Closes #54135
2018-09-21 22:58:11 +00:00
| help: try a static value: `pub static`
private no-mangle lints: issue suggestion for restricted visibility This is probably quite a lot less likely to come up in practice than the "inherited" (no visibility keyword) case, but now that we have visibility spans in the HIR, we can do this, and it presumably doesn't hurt to be exhaustive. (Who can say but that the attention to detail just might knock someone's socks off, someday, somewhere?) This is inspired by #47383.
2018-06-28 05:30:23 +00:00
Update tests Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-15 22:26:36 +00:00
warning: functions generic over types or consts must be mangled
Update tests
2020-02-28 19:58:09 +00:00
--> $DIR/suggestions.rs:32:18
private no-mangle lints: issue suggestion for restricted visibility This is probably quite a lot less likely to come up in practice than the "inherited" (no visibility keyword) case, but now that we have visibility spans in the HIR, we can do this, and it presumably doesn't hurt to be exhaustive. (Who can say but that the attention to detail just might knock someone's socks off, someday, somewhere?) This is inspired by #47383.
2018-06-28 05:30:23 +00:00
|
rustc: Allow `#[no_mangle]` anywhere in a crate This commit updates the compiler to allow the `#[no_mangle]` (and `#[export_name]` attributes) to be located anywhere within a crate. These attributes are unconditionally processed, causing the compiler to always generate an exported symbol with the appropriate name. After some discussion on #54135 it was found that not a great reason this hasn't been allowed already, and it seems to match the behavior that many expect! Previously the compiler would only export a `#[no_mangle]` symbol if it were *publicly reachable*, meaning that it itself is `pub` and it's otherwise publicly reachable from the root of the crate. This new definition is that `#[no_mangle]` *is always reachable*, no matter where it is in a crate or whether it has `pub` or not. This should make it much easier to declare an exported symbol with a known and unique name, even when it's an internal implementation detail of the crate itself. Note that these symbols will persist beyond LTO as well, always making their way to the linker. Along the way this commit removes the `private_no_mangle_functions` lint (also for statics) as there's no longer any need to lint these situations. Furthermore a good number of tests were updated now that symbol visibility has been changed. Closes #54135
2018-09-21 22:58:11 +00:00
LL | #[no_mangle] pub(crate) fn crossfield<T>() {}
| ------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: remove this attribute
private no-mangle lints: issue suggestion for restricted visibility This is probably quite a lot less likely to come up in practice than the "inherited" (no visibility keyword) case, but now that we have visibility spans in the HIR, we can do this, and it presumably doesn't hurt to be exhaustive. (Who can say but that the attention to detail just might knock someone's socks off, someday, somewhere?) This is inspired by #47383.
2018-06-28 05:30:23 +00:00
rustc: Add a warning count upon completion
2020-03-11 15:30:09 +00:00
error: aborting due to 3 previous errors; 8 warnings emitted
bolster UI test converage for lint suggestions
2017-10-12 07:42:52 +00:00
Reference in New Issue Copy Permalink