mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
96234d5363
rust/src/test/ui/lint/suggestions.stderr

120 lines
3.7 KiB
Plaintext
Raw Normal View History

Make WhileTrue into an EarlyLintPass lint.
2019-06-21 18:30:24 -05:00
warning: denote infinite loops with `loop { ... }`
--> $DIR/suggestions.rs:46:5
|
LL | while true {
| ^^^^^^^^^^ help: use `loop`
|
= note: #[warn(while_true)] on by default
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 01:52:51 -05:00
warning: unnecessary parentheses around assigned value
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:49:31
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 01:52:51 -05: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-16 23:36:02 -05: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 01:52:51 -05:00
|
Add several lints into `unused` lint group Remove a couple of obsolete lints
2017-10-20 16:00:57 -05:00
note: lint level defined here
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:3:21
Add several lints into `unused` lint group Remove a couple of obsolete lints
2017-10-20 16:00:57 -05:00
|
Update UI tests
2018-02-22 18:42:32 -06: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 16:00:57 -05:00
| ^^^^^^^^^^^^^
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 01:52:51 -05:00
warning: use of deprecated attribute `no_debug`: the `#[no_debug]` attribute was an experimental feature that has been deprecated due to lack of demand. See https://github.com/rust-lang/rust/issues/29721
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:42:1
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 01:52:51 -05:00
|
Update UI tests
2018-02-22 18:42:32 -06:00
LL | #[no_debug] // should suggest removal of deprecated attribute
code suggestions for unused-mut, while-true lints; UI test
2017-09-30 01:52:51 -05:00
| ^^^^^^^^^^^ help: remove this attribute
|
= note: #[warn(deprecated)] on by default
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 14:49:10 -05:00
warning: variable does not need to be mutable
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:49: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 14:49:10 -05: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-16 23:36:02 -05: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 14:49:10 -05:00
| |
| help: remove this `mut`
|
note: lint level defined here
Remove licenses
2018-12-25 09:56:47 -06: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 14:49:10 -05:00
|
Update UI tests
2018-02-22 18:42:32 -06: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 14:49:10 -05:00
| ^^^^^^^^^^
Consider all whitespace when preparing span
2018-01-23 12:54:57 -06:00
warning: variable does not need to be mutable
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:55:13
Consider all whitespace when preparing span
2018-01-23 12:54:57 -06:00
|
Update UI tests
2018-02-22 18:42:32 -06:00
LL | let mut
Consider all whitespace when preparing span
2018-01-23 12:54:57 -06:00
| _____________^
| |_____________|
| ||
Update UI tests
2018-02-22 18:42:32 -06:00
LL | || b = 1;
Consider all whitespace when preparing span
2018-01-23 12:54:57 -06:00
| ||____________-^
| |____________|
| help: remove this `mut`
bolster UI test converage for lint suggestions
2017-10-12 02:42:52 -05:00
error: const items should never be #[no_mangle]
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:6:14
bolster UI test converage for lint suggestions
2017-10-12 02:42:52 -05: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 00:50:24 -05:00
LL | #[no_mangle] const DISCOVERY: usize = 1;
bolster UI test converage for lint suggestions
2017-10-12 02:42:52 -05:00
| -----^^^^^^^^^^^^^^^^^^^^^^
| |
| help: try a static value: `pub static`
|
= note: #[deny(no_mangle_const_items)] on by default
Update tests Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-15 16:26:36 -06:00
warning: functions generic over types or consts must be mangled
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:12:1
bolster UI test converage for lint suggestions
2017-10-12 02:42:52 -05: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 00:50:24 -05:00
LL | #[no_mangle]
bolster UI test converage for lint suggestions
2017-10-12 02:42:52 -05:00
| ------------ help: remove this attribute
Update tests
2019-03-09 06:03:44 -06:00
LL |
Update UI tests
2018-02-22 18:42:32 -06:00
LL | pub fn defiant<T>(_t: T) {}
bolster UI test converage for lint suggestions
2017-10-12 02:42:52 -05:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(no_mangle_generic_items)] on by default
Update tests
2019-03-12 20:55:37 -05:00
warning: the `warp_factor:` in this pattern is redundant
--> $DIR/suggestions.rs:61:23
|
LL | Equinox { warp_factor: warp_factor } => {}
| ------------^^^^^^^^^^^^
| |
| help: remove this
|
= note: #[warn(non_shorthand_field_patterns)] on by default
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 17:58:11 -05:00
error: const items should never be #[no_mangle]
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:22:18
bolster UI test converage for lint suggestions
2017-10-12 02:42:52 -05: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 17:58:11 -05: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 02:42:52 -05:00
Update tests Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-15 16:26:36 -06:00
warning: functions generic over types or consts must be mangled
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:25: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 00:50:24 -05: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 17:58:11 -05: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-15 20:32:18 -06: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 17:58:11 -05:00
error: const items should never be #[no_mangle]
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:30: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-15 20:32:18 -06: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 17:58:11 -05: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 00:30:23 -05: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 17:58:11 -05: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 00:30:23 -05:00
Update tests Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-15 16:26:36 -06:00
warning: functions generic over types or consts must be mangled
Remove licenses
2018-12-25 09:56:47 -06:00
--> $DIR/suggestions.rs:33: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 00:30:23 -05: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 17:58:11 -05: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 00:30:23 -05: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 17:58:11 -05:00
error: aborting due to 3 previous errors
bolster UI test converage for lint suggestions
2017-10-12 02:42:52 -05:00
Reference in New Issue Copy Permalink