rust/tests/ui/path-lookahead.rs

//@ run-pass
//@ run-rustfix

#![allow(dead_code)]
#![warn(unused_parens)]

// Parser test for #37765

fn with_parens<T: ToString>(arg: T) -> String {
    return (<T as ToString>::to_string(&arg)); //~WARN unnecessary parentheses around `return` value
}

fn no_parens<T: ToString>(arg: T) -> String {
    return <T as ToString>::to_string(&arg);
}

fn main() {}
Introduce 'run-pass' header to 'ui' tests in compiletest. Fix issue #36516. The 'run-pass' header cause a 'ui' test to execute the result. It is used to test the lint output, at the same time ensure those lints won't cause the source code to become compile-fail. 12 run-pass/run-pass-fulldeps tests gained the header and are moved to ui/ui-fulldeps. After this move, no run-pass/run-pass-fulldeps tests should rely on the compiler's JSON message. This allows us to stop passing `--error-format json` in run-pass tests, thus fixing #36516. 2017-05-13 04:54:50 -05:00			`//@ run-pass`
Audit uses of `span_suggestion_short` 2020-07-02 00:32:12 -05:00			`//@ run-rustfix`

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			`#![allow(dead_code)]`
			`#![warn(unused_parens)]`
rustc: Rearchitect lints to be emitted more eagerly In preparation for incremental compilation this commit refactors the lint handling infrastructure in the compiler to be more "eager" and overall more incremental-friendly. Many passes of the compiler can emit lints at various points but before this commit all lints were buffered in a table to be emitted at the very end of compilation. This commit changes these lints to be emitted immediately during compilation using pre-calculated lint level-related data structures. Linting today is split into two phases, one set of "early" lints run on the `syntax::ast` and a "late" set of lints run on the HIR. This commit moves the "early" lints to running as late as possible in compilation, just before HIR lowering. This notably means that we're catching resolve-related lints just before HIR lowering. The early linting remains a pass very similar to how it was before, maintaining context of the current lint level as it walks the tree. Post-HIR, however, linting is structured as a method on the `TyCtxt` which transitively executes a query to calculate lint levels. Each request to lint on a `TyCtxt` will query the entire crate's 'lint level data structure' and then go from there about whether the lint should be emitted or not. The query depends on the entire HIR crate but should be very quick to calculate (just a quick walk of the HIR) and the red-green system should notice that the lint level data structure rarely changes, and should hopefully preserve incrementality. Overall this resulted in a pretty big change to the test suite now that lints are emitted much earlier in compilation (on-demand vs only at the end). This in turn necessitated the addition of many `#![allow(warnings)]` directives throughout the compile-fail test suite and a number of updates to the UI test suite. 2017-07-26 23:51:09 -05:00
add test for #37765 2016-11-14 11:35:37 -06:00			`// Parser test for #37765`

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			`fn with_parens<T: ToString>(arg: T) -> String {`
Audit uses of `span_suggestion_short` 2020-07-02 00:32:12 -05:00			return (<T as ToString>::to_string(&arg)); //~WARN unnecessary parentheses around `return` value
add test for #37765 2016-11-14 11:35:37 -06:00			`}`

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			`fn no_parens<T: ToString>(arg: T) -> String {`
Audit uses of `span_suggestion_short` 2020-07-02 00:32:12 -05:00			`return <T as ToString>::to_string(&arg);`
add test for #37765 2016-11-14 11:35:37 -06:00			`}`

Audit uses of `span_suggestion_short` 2020-07-02 00:32:12 -05:00			`fn main() {}`