Commit graph

8607 commits

Author SHA1 Message Date
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
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
Eduardo Broto
50419118b4 Merge commit '645ef505da378b6f810b1567806d1bcc2856395f' into clippyup 2020-10-28 23:36:07 +01:00
Nathan Whitaker
a1bb10e9b8 Remove lint from clippy 2020-10-26 18:19:48 -04:00
Yuki Okushi
df85532112 Rollup merge of #78326 - Aaron1011:fix/min-stmt-lints, r=petrochenkov
Split out statement attributes changes from #78306

This is the same as PR https://github.com/rust-lang/rust/pull/78306, but `unused_doc_comments` is modified to explicitly ignore statement items (which preserves the current behavior).

This shouldn't have any user-visible effects, so it can be landed without lang team discussion.

---------
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
2020-10-25 18:43:49 +09:00
Aaron Hill
33f3cfcadc Fix inconsistencies in handling of inert attributes on statements
When the 'early' and 'late' visitors visit an attribute target, they
activate any lint attributes (e.g. `#[allow]`) that apply to it.
This can affect warnings emitted on sibiling attributes. For example,
the following code does not produce an `unused_attributes` for
`#[inline]`, since the sibiling `#[allow(unused_attributes)]` suppressed
the warning.

```rust
trait Foo {
    #[allow(unused_attributes)] #[inline] fn first();
    #[inline] #[allow(unused_attributes)] fn second();
}
```

However, we do not do this for statements - instead, the lint attributes
only become active when we visit the struct nested inside `StmtKind`
(e.g. `Item`).

Currently, this is difficult to observe due to another issue - the
`HasAttrs` impl for `StmtKind` ignores attributes for `StmtKind::Item`.
As a result, the `unused_doc_comments` lint will never see attributes on
item statements.

This commit makes two interrelated fixes to the handling of inert
(non-proc-macro) attributes on statements:

* The `HasAttr` impl for `StmtKind` now returns attributes for
  `StmtKind::Item`, treating it just like every other `StmtKind`
  variant. The only place relying on the old behavior was macro
  which has been updated to explicitly ignore attributes on item
  statements. This allows the `unused_doc_comments` lint to fire for
  item statements.
* The `early` and `late` lint visitors now activate lint attributes when
  invoking the callback for `Stmt`. This ensures that a lint
  attribute (e.g. `#[allow(unused_doc_comments)]`) can be applied to
  sibiling attributes on an item statement.

For now, the `unused_doc_comments` lint is explicitly disabled on item
statements, which preserves the current behavior. The exact locatiosn
where this lint should fire are being discussed in PR #78306
2020-10-24 11:55:48 -04:00
Eduardo Broto
6caeed1bfa Remove duplicate import of Target 2020-10-23 23:45:37 +02:00
Eduardo Broto
cdb555f4fc Merge commit 'bf1c6f9871f430e284b17aa44059e0d0395e28a6' into clippyup 2020-10-23 22:16:59 +02:00
varkor
fcde7683fe Fix clippy tests 2020-10-22 13:23:14 +01:00
Yuki Okushi
82f775d2c4 Rollup merge of #77851 - exrook:split-btreemap, r=dtolnay
BTreeMap: refactor Entry out of map.rs into its own file

btree/map.rs is approaching the 3000 line mark, splitting out the entry
code buys about 500 lines of headroom.

I've created this PR because the changes I've made in #77438 will push `map.rs` over the 3000 line limit and cause tidy to complain.

I picked `Entry` to factor out because it feels less tightly coupled to the rest of `BTreeMap` than the various iterator implementations.

Related: #60302
2020-10-18 04:11:07 +09:00
Jacob Hughes
29392a1728 Appease the almightly lord clippy, hallowed be thy name 2020-10-17 13:48:54 -04:00
Santiago Pastorino
0af467ebf2 Handle ExprKind::ConstBlock on clippy 2020-10-16 17:14:34 -03:00
Dylan DPC
d2feccc1ef Rollup merge of #77493 - hosseind88:ICEs_should_always_print_the_top_of_the_query_stack, r=oli-obk
ICEs should always print the top of the query stack

see #76920
2020-10-16 02:10:09 +02:00
est31
2c1e8cfc62 Remove rustc_session::config::Config
The wrapper type led to tons of target.target
across the compiler. Its ptr_width field isn't
required any more, as target_pointer_width
is already present in parsed form.
2020-10-15 12:02:24 +02:00
hosseind88
ab0fc477b8 fix stderr file of clippy/custom_ice_message test 2020-10-14 18:19:26 +03:30
bors
bf947fcba2 Auto merge of #77796 - jonas-schievink:switchint-refactor, r=oli-obk
Refactor how SwitchInt stores jump targets

Closes https://github.com/rust-lang/rust/issues/65693
2020-10-13 00:57:03 +00:00
bors
29cff6feff Auto merge of #77649 - dash2507:replace_run_compiler, r=matthewjasper
Replace run_compiler with RunCompiler builder pattern

Fixes #77286. Replaces rustc_driver:run_compiler with RunCompiler builder pattern.
2020-10-11 01:26:06 +00:00
Jonas Schievink
1178777457 Refactor how SwitchInt stores jump targets 2020-10-10 17:46:11 +02:00
hosseind75
3c94914f0c rebase with master 2020-10-09 20:57:45 +03:30
hosseind75
7f07577e6f add new line 2020-10-09 20:57:45 +03:30
hosseind75
49bc85e947 fix clippy custom_ice_message test 2020-10-09 20:57:45 +03:30