Commit graph

8676 commits

Author SHA1 Message Date
LeSeulArtichaut
93c6135c15 Handle Guard::IfLet in clippy 2020-12-06 13:43:19 +01:00
LeSeulArtichaut
402f55f33f Implement lowering of if-let guards to MIR 2020-12-06 13:42:24 +01:00
Vishnunarayan K I
4e14c05976 fix clippy test 2020-12-05 20:21:21 +05:30
bors
3be53bc45a Auto merge of #79329 - camelid:int-lit-suffix-error, r=davidtwco
Update error to reflect that integer literals can have float suffixes

For example, `1` is parsed as an integer literal, but it can be turned
into a float with the suffix `f32`. Now the error calls them "numeric
literals" and notes that you can add a float suffix since they can be
either integers or floats.
2020-11-30 01:42:14 +00:00
bstrie
d55d791a3a Update tests to remove old numeric constants
Part of #68490.

Care has been taken to leave the old consts where appropriate, for testing backcompat regressions, module shadowing, etc. The intrinsics docs were accidentally referring to some methods on f64 as std::f64, which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros.

For places which have legitimate uses of the old consts, deprecated attributes have been optimistically inserted. Although currently unnecessary, they exist to emphasize to any future deprecation effort the necessity of these specific symbols and prevent them from being accidentally removed.
2020-11-29 00:55:55 -05:00
Camelid
2347eac4cc Update error to reflect that integer literals can have float suffixes
For example, `1` is parsed as an integer literal, but it can be turned
into a float with the suffix `f32`. Now the error calls them "numeric
literals" and notes that you can add a float suffix since they can be
either integers or floats.
2020-11-27 19:08:24 -08:00
bors
5d585ec022 Auto merge of #79318 - cjgillot:fitem, r=lcnr
Store HIR ForeignItem in a side table

In a similar fashion to Item, ImplItem and TraitItem.
2020-11-27 13:45:22 +00:00
Camille GILLOT
d95f11bcd6 Remove ForeignMod struct. 2020-11-26 21:32:27 +01:00
bors
f303168a0d Auto merge of #77671 - flip1995:lint_list_always_plugins, r=oli-obk,Manishearth
Always print lints from plugins, if they're available

Currently you can get a list of lints and lint groups by running `rustc
-Whelp`. This prints an additional line at the end:
```
Compiler plugins can provide additional lints and lint groups. To see a listing of these, re-run `rustc -W help` with a crate filename.
```

Clippy is such a "compiler plugin", that provides additional lints.
Running `clippy-driver -Whelp` (`rustc` wrapper) still only prints the
rustc lints with the above message at the end. But when running
`clippy-driver -Whelp main.rs`, where `main.rs` is any rust file, it
also prints Clippy lints. I don't think this is a good approach from a
UX perspective: Why is a random file necessary to print a help message?

This PR changes this behavior: Whenever a compiler callback
registers lints, it is assumed that these lints come from a plugin and
are printed without having to specify a Rust source file.

Fixes rust-lang/rust-clippy#6122

cc `@Manishearth` `@ebroto` for the Clippy changes.
2020-11-26 18:51:45 +00:00
Arlie Davis
f6827839c0 Move lev_distance to rustc_ast, make non-generic
rustc_ast currently has a few dependencies on rustc_lexer. Ideally, an AST
would not have any dependency its lexer, for minimizing unnecessarily
design-time dependencies. Breaking this dependency would also have practical
benefits, since modifying rustc_lexer would not trigger a rebuild of rustc_ast.

This commit does not remove the rustc_ast --> rustc_lexer dependency,
but it does remove one of the sources of this dependency, which is the
code that handles fuzzy matching between symbol names for making suggestions
in diagnostics. Since that code depends only on Symbol, it is easy to move
it to rustc_span. It might even be best to move it to a separate crate,
since other tools such as Cargo use the same algorithm, and have simply
contain a duplicate of the code.

This changes the signature of find_best_match_for_name so that it is no
longer generic over its input. I checked the optimized binaries, and this
function was duplicated at nearly every call site, because most call sites
used short-lived iterator chains, generic over Map and such. But there's
no good reason for a function like this to be generic, since all it does
is immediately convert the generic input (the Iterator impl) to a concrete
Vec<Symbol>. This has all of the costs of generics (duplicated method bodies)
with no benefit.

Changing find_best_match_for_name to be non-generic removed about 10KB of
code from the optimized binary. I know it's a drop in the bucket, but we have
to start reducing binary size, and beginning to tame over-use of generics
is part of that.
2020-11-24 16:12:23 -08:00
flip1995
03f04314dd clippy: Remove now obsolete lintlist module
Also stop updating the lintlist module in clippy_dev update_lints
2020-11-24 10:37:31 +01:00
flip1995
9f1505ce9f clippy: Let rustc handle describing lints 2020-11-24 10:37:15 +01:00
bors
53ce1dd719 Auto merge of #79228 - flip1995:clippyup, r=oli-obk
Update Clippy

Biweekly Clippy update

r? `@Manishearth`
2020-11-24 06:56:02 +00:00
bors
d5b40bf469 Auto merge of #78343 - camelid:macros-qualify-panic, r=m-ou-se
Qualify `panic!` as `core::panic!` in non-built-in `core` macros

Fixes #78333.

-----

Otherwise code like this

    #![no_implicit_prelude]

    fn main() {
        ::std::todo!();
        ::std::unimplemented!();
    }

will fail to compile, which is unfortunate and presumably unintended.

This changes many invocations of `panic!` in a `macro_rules!` definition
to invocations of `$crate::panic!`, which makes the invocations hygienic.

Note that this does not make the built-in macro `assert!` hygienic.
2020-11-23 22:05:28 +00:00
Camelid
d708b444e4 Qualify panic! as core::panic! in non-built-in core macros
Otherwise code like this

    #![no_implicit_prelude]

    fn main() {
        ::std::todo!();
        ::std::unimplemented!();
    }

will fail to compile, which is unfortunate and presumably unintended.

This changes many invocations of `panic!` in a `macro_rules!` definition
to invocations of `$crate::panic!`, which makes the invocations hygienic.

Note that this does not make the built-in macro `assert!` hygienic.
2020-11-23 11:28:25 -08:00
bors
e5fddb6747 Auto merge of #78439 - lzutao:rm-clouldabi, r=Mark-Simulacrum
Drop support for all cloudabi targets

`cloudabi` is a tier-3 target, and [it is no longer being maintained upstream][no].

This PR drops supports for cloudabi targets. Those targets are:
* aarch64-unknown-cloudabi
* armv7-unknown-cloudabi
* i686-unknown-cloudabi
* x86_64-unknown-cloudabi

Since this drops supports for a target, I'd like somebody to tag `relnotes` label to this PR.

Some other issues:
* The tidy exception for `cloudabi` crate is still remained because
  * `parking_lot v0.9.0` and `parking_lot v0.10.2` depends on `cloudabi v0.0.3`.
  * `parking_lot v0.11.0` depends on `cloudabi v0.1.0`.

[no]: https://github.com/NuxiNL/cloudabi#note-this-project-is-unmaintained
2020-11-23 19:01:19 +00:00
flip1995
284c359c61 Fix ICE in utils::implements_trait
This only happend when debug_assertions were enabled in rustc
2020-11-23 13:52:27 +01:00
flip1995
d3d2018ead Merge commit '3e7c6dec244539970b593824334876f8b6ed0b18' into clippyup 2020-11-23 13:51:04 +01:00
Lzu Tao
4b698f2069 Drop support for cloudabi targets 2020-11-22 17:11:41 -05:00
Jonas Schievink
1464dcedfb Thread Constness through selection 2020-11-22 02:13:53 +01:00
Mara Bos
113c1476c9 Clippy: Match on assert!() expansions without an inner block. 2020-11-19 19:47:25 +01:00
Mara Bos
78faaef8de Remove the clippy::panic-params lint.
Rustc itself now warns for all cases that triggered this lint.
2020-11-19 18:34:40 +01:00
Mara Bos
577ebc8cd6 Rollup merge of #79145 - camelid:clippy-fix-panics, r=flip1995
Fix handling of panic calls

This should make Clippy more resilient and will unblock #78343.

This PR is made against rust-lang/rust to avoid the need for a subtree
sync at ``@flip1995's`` suggestion in rust-lang/rust-clippy#6310.

r? ``@flip1995``
cc ``@m-ou-se``
2020-11-18 15:46:36 +01:00
Camelid
4e4c4fb8aa Fix handling of panic calls
This should make Clippy more resilient and will unblock #78343.

This PR is made against rust-lang/rust to avoid the need for a subtree
sync at @flip1995's suggestion in rust-lang/rust-clippy#6310.
2020-11-17 12:16:15 -08:00
bors
a467c514a3 Auto merge of #78779 - LeSeulArtichaut:ty-visitor-return, r=oli-obk
Introduce `TypeVisitor::BreakTy`

Implements MCP rust-lang/compiler-team#383.
r? `@ghost`
cc `@lcnr` `@oli-obk`

~~Blocked on FCP in rust-lang/compiler-team#383.~~
2020-11-17 12:24:34 +00:00
Bastian Kauschke
3567ea546f clippy: fold by value 2020-11-16 22:42:09 +01:00
Jonas Schievink
27a15721c5 Rollup merge of #79016 - fanzier:underscore-expressions, r=petrochenkov
Make `_` an expression, to discard values in destructuring assignments

This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the third and final part of #71156, which was split up to allow for easier review.

With this PR, an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value, similarly to the wildcard `_` in patterns. For instance,
```rust
(a, _) = (1, 2)
```
will simply assign 1 to `a` and discard the 2. Note that for consistency,
```
_ = foo
```
is also allowed and equivalent to just `foo`.

Thanks to ````@varkor```` who helped with the implementation, particularly around pre-expansion gating.

r? ````@petrochenkov````
2020-11-15 13:39:48 +01:00
LeSeulArtichaut
1b55cc79cc Set the default BreakTy to ! 2020-11-14 21:46:39 +01:00
LeSeulArtichaut
cbb6b1c338 Introduce TypeVisitor::BreakTy 2020-11-14 20:25:27 +01:00
bors
0c7a48c5f0 Auto merge of #78809 - vn-ki:fix-issue-76064, r=oli-obk
add error_occured field to ConstQualifs,

fix #76064

I wasn't sure what `in_return_place` actually did and not sure why it returns `ConstQualifs` while it's sibling functions return `bool`. So I tried to make as minimal changes to the structure as possible. Please point out whether I have to refactor it or not.

r? `@oli-obk`
cc `@RalfJung`
2020-11-14 18:03:17 +00:00
Fabian Zaiser
864e554b9a Add underscore expressions for destructuring assignments
Co-authored-by: varkor <github@varkor.com>
2020-11-14 13:53:12 +00:00
Vishnunarayan K I
7987f39ad5 update clippy test ouput 2020-11-13 17:11:13 +05:30
Mara Bos
3a648ffc02 Rollup merge of #78836 - fanzier:struct-and-slice-destructuring, r=petrochenkov
Implement destructuring assignment for structs and slices

This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review.

Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course.

This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern).

Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR.

Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes.

r? ``@petrochenkov``
2020-11-12 19:46:09 +01:00
bors
92ece84873 Auto merge of #78782 - petrochenkov:nodoctok, r=Aaron1011
Do not collect tokens for doc comments

Doc comment is a single token and AST has all the information to re-create it precisely.
Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0`, cc https://github.com/rust-lang/rust/pull/78736).

(I also moved token collection into `fn parse_attribute` to deduplicate code a bit.)

r? `@Aaron1011`
2020-11-12 00:33:55 +00:00
Fabian Zaiser
5f310d9b83 Implement destructuring assignment for structs and slices
Co-authored-by: varkor <github@varkor.com>
2020-11-11 12:10:52 +00:00
Ikko Ashimine
f92f8d095d Fix typo in comment
occurences -> occurrences
2020-11-11 20:23:08 +09:00
Dylan DPC
6294300b8e Rollup merge of #78710 - petrochenkov:macvisit, r=davidtwco
rustc_ast: Do not panic by default when visiting macro calls

Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them.

The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.
2020-11-09 19:06:55 +01:00
Vadim Petrochenkov
8845f10e94 Do not collect tokens for doc comments 2020-11-09 01:47:11 +03:00
flip1995
34244190d4 Merge commit 'b20d4c155d2fe3a8391f86dcf9a8c49e17188703' into clippyup 2020-11-05 14:29:48 +01:00
bors
0c1531a5c4 Auto merge of #78662 - sexxi-goose:add_expr_id_to_delegate, r=nikomatsakis
Provide diagnostic suggestion in ExprUseVisitor Delegate

The [Delegate trait](981346fc07/compiler/rustc_typeck/src/expr_use_visitor.rs (L28-L38)) currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.

Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.

Eg:

```
let arr : [String; 5];

let [a, ...]     =   arr;
 ^^^ E1 ^^^      =  ^^E2^^
 ```

 Here `arr` is moved because of the binding created E1. However, when we
 point to E1 in diagnostics with the message `arr` was moved, it can be
 confusing.  Rather we would like to report E2 to the user.

 Closes: https://github.com/rust-lang/project-rfc-2229/issues/20

r? `@ghost`
2020-11-04 22:45:15 +00:00
oli
83edb2f4e4 s/Scalar::Raw/Scalar::Int 2020-11-04 10:11:31 +00:00
Oliver Scherer
6fdbde5f46 Split the "raw integer bytes" part out of Scalar 2020-11-04 09:58:59 +00:00
Vadim Petrochenkov
c2a769f84c rustc_ast: visit_mac -> visit_mac_call 2020-11-03 23:39:51 +03:00
Vadim Petrochenkov
89fa373059 rustc_ast: Do not panic by default when visiting macro calls 2020-11-03 20:38:20 +03:00
Dhruv Jauhar
5f973264bd Provide diagnostic suggestion in ExprUseVisitor Delegate
The [Delegate
trait](981346fc07/compiler/rustc_typeck/src/expr_use_visitor.rs (L28-L38))
currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.

Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.

Eg:

```
let arr : [String; 5];

let [a, ...]     =   arr;
 ^^^ E1 ^^^      =  ^^E2^^
 ```

 Here `arr` is moved because of the binding created E1. However, when we
 point to E1 in diagnostics with the message `arr` was moved, it can be
 confusing.  Rather we would like to report E2 to the user.

 Closes: https://github.com/rust-lang/project-rfc-2229/issues/20
2020-11-02 01:31:34 -05:00
bors
8a18963f28 Auto merge of #75534 - Aaron1011:feature/new-future-breakage, r=pnkfelix
Implement rustc side of report-future-incompat

cc https://github.com/rust-lang/rust/issues/71249

This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch 😄 ).

My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`.

Several changes are made to support this feature:
* The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`.
* The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling).
* A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`.
* `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report).
* `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data.

Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future.

I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself.

cc `@pnkfelix`
2020-11-01 16:52:28 +00:00
Aaron Hill
4bbc7712fc Update Clippy path to Lint 2020-10-30 21:41:16 -04:00
LeSeulArtichaut
1c8c3d14ef Remove implicit Continue type 2020-10-30 12:27:47 +01:00
LeSeulArtichaut
4a06145ced Use ControlFlow::is{break,continue} 2020-10-30 12:27:46 +01:00
LeSeulArtichaut
fa79cc4f6f TypeVisitor: use ControlFlow in clippy 2020-10-30 12:27:45 +01:00