2018-08-08 07:28:26 -05:00
|
|
|
error: struct is never constructed: `Bar`
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
--> $DIR/lint-dead-code-1.rs:12:16
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | pub struct Bar;
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
| ^^^
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
|
|
|
|
note: lint level defined here
|
2018-12-25 09:56:47 -06:00
|
|
|
--> $DIR/lint-dead-code-1.rs:5:9
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
|
|
|
|
LL | #![deny(dead_code)]
|
|
|
|
|
| ^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
error: static item is never used: `priv_static`
|
2018-12-25 09:56:47 -06:00
|
|
|
--> $DIR/lint-dead-code-1.rs:20:1
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | static priv_static: isize = 0;
|
2018-08-08 07:28:26 -05:00
|
|
|
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
error: constant item is never used: `priv_const`
|
2018-12-25 09:56:47 -06:00
|
|
|
--> $DIR/lint-dead-code-1.rs:27:1
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | const priv_const: isize = 0;
|
2018-08-08 07:28:26 -05:00
|
|
|
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
error: struct is never constructed: `PrivStruct`
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
--> $DIR/lint-dead-code-1.rs:35:8
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | struct PrivStruct;
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
| ^^^^^^^^^^
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
|
|
|
error: enum is never used: `priv_enum`
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
--> $DIR/lint-dead-code-1.rs:64:6
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | enum priv_enum { foo2, bar2 }
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
| ^^^^^^^^^
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
|
|
|
error: variant is never constructed: `bar3`
|
2018-12-25 09:56:47 -06:00
|
|
|
--> $DIR/lint-dead-code-1.rs:67:5
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | bar3
|
2018-08-08 07:28:26 -05:00
|
|
|
| ^^^^
|
|
|
|
|
|
|
|
|
|
error: function is never used: `priv_fn`
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
--> $DIR/lint-dead-code-1.rs:88:4
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | fn priv_fn() {
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
| ^^^^^^^
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
|
|
|
error: function is never used: `foo`
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
--> $DIR/lint-dead-code-1.rs:93:4
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | fn foo() {
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
| ^^^
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
|
|
|
error: function is never used: `bar`
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
--> $DIR/lint-dead-code-1.rs:98:4
|
2018-08-08 07:28:26 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | fn bar() {
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
| ^^^
|
2018-08-08 07:28:26 -05:00
|
|
|
|
2018-10-04 05:38:06 -05:00
|
|
|
error: function is never used: `baz`
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
--> $DIR/lint-dead-code-1.rs:102:4
|
2018-10-04 05:38:06 -05:00
|
|
|
|
|
2019-03-09 06:03:44 -06:00
|
|
|
LL | fn baz() -> impl Copy {
|
Use ident instead of def_span in dead-code pass
According to @estebank, def_span scans forward on the line until it finds a {,
and if it can't find one, fallse back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
2019-10-25 13:46:07 -05:00
|
|
|
| ^^^
|
2018-10-04 05:38:06 -05:00
|
|
|
|
|
|
|
|
error: aborting due to 10 previous errors
|
2018-08-08 07:28:26 -05:00
|
|
|
|
