Commit Graph

673 Commits

Author SHA1 Message Date
Fabian Wolff
9626f2bd84 Fix extra non_snake_case warning for shorthand field bindings 2021-10-03 14:33:14 +02:00
Hirochika Matsumoto
3818981ca1 Practice diagnostic message convention 2021-10-03 16:16:28 +09:00
bors
77f1e504a9 Auto merge of #89479 - camsteffen:diag-naming, r=Manishearth
Make diangostic item naming consistent

Right now there is about a 50/50 split of naming diagnostic items as `vec_type` vs `Vec`. So it is hard to guess a diagnostic item name with confidence. I know it's not great to change these retroactively, but I think it will be much easier to maintain consistency after consistency is established.
2021-10-03 03:43:21 +00:00
bors
c70b35efd8 Auto merge of #84267 - dtolnay:ptrunit, r=nagisa
Make *const (), *mut () okay for FFI

Pointer-to-() is used occasionally in the standard library to mean "pointer to none-of-your-business". Examples:

- `RawWakerVTable::new` https://doc.rust-lang.org/1.51.0/std/task/struct.RawWakerVTable.html#method.new
- `<*const T>::to_raw_parts` https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.to_raw_parts

I believe it's useful for the same purpose in FFI signatures, even while `()` itself is not FFI safe. The following should be allowed:

```rust
extern "C" {
    fn demo(pc: *const (), pm: *mut ());
}
```

Prior to this PR, those pointers were not considered okay for an extern signature.

```console
warning: `extern` block uses type `()`, which is not FFI-safe
 --> src/main.rs:2:17
  |
2 |     fn demo(pc: *const (), pm: *mut ());
  |                 ^^^^^^^^^ not FFI-safe
  |
  = note: `#[warn(improper_ctypes)]` on by default
  = help: consider using a struct instead
  = note: tuples have unspecified layout

warning: `extern` block uses type `()`, which is not FFI-safe
 --> src/main.rs:2:32
  |
2 |     fn demo(pc: *const (), pm: *mut ());
  |                                ^^^^^^^ not FFI-safe
  |
  = help: consider using a struct instead
  = note: tuples have unspecified layout
```
2021-10-03 00:41:49 +00:00
Cameron Steffen
eec856bfbc Make diangostic item names consistent 2021-10-02 19:38:19 -05:00
bjorn3
83ddedf170 Remove various unused feature gates 2021-10-02 19:09:18 +02:00
Camille GILLOT
faa7d4221b Do not pass hir::Crate to lints. 2021-09-30 17:39:54 +02:00
Camille GILLOT
db9fea508a Avoid more invocations of hir_crate query. 2021-09-29 23:16:47 +02:00
Vadim Petrochenkov
a09fb901cb rustc_session: Remove lint store from Session 2021-09-28 11:56:15 +03:00
Samuel Moelius
1e15bbe552 Pass real crate-level attributes to pre_expansion_lint 2021-09-26 21:50:50 +00:00
bors
ce45663e14 Auto merge of #88865 - guswynn:must_not_suspend, r=oli-obk
Implement `#[must_not_suspend]`

implements #83310

Some notes on the impl:

1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared, as the logic did diverge
2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects), like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this, as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC, and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time, but `must_not_suspend` would need to answer the question: "for some value X with type T, find any fn call that COULD have produced this value". That would require significant changes to `generator_interior.rs`, and I would need mentorship on that. `@eholk` and I are discussing it.
3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden

Also, I am not sure if we should run perf on this

r? `@nikomatsakis`
2021-09-22 06:43:33 +00:00
Mark Rousskov
3b89679671 Adjust documentation for compatibility with 2021
This also adjusts the lint docs generation to accept (and ignore) an allow
attribute, rather than expecting the documentation to be immediately followed by
the lint name.
2021-09-20 22:21:43 -04:00
Mark Rousskov
c746be2219 Migrate to 2021 2021-09-20 22:21:42 -04:00
bors
7b5f95270f Auto merge of #88703 - cjgillot:lazymod, r=petrochenkov
Gather module items after lowering.

This avoids having a non-local analysis inside lowering.

By implementing `hir_module_items` using a visitor, we make sure that iterations and visitors are consistent.
2021-09-19 16:13:42 +00:00
Yuki Okushi
81dc21699e
Rollup merge of #87529 - FabianWolff:issue-87496, r=nikomatsakis
Fix ICE in `improper_ctypes_definitions` lint with all-ZST transparent types

Fixes #87496. There is also another function in the same file that looks fishy, but I haven't been able to produce an ICE there, and in any case, it's not related to #87496:
fd853c00e2/compiler/rustc_lint/src/types.rs (L720-L734)

r? ```@JohnTitor```
2021-09-17 14:09:44 +09:00
bors
cdeba02ff7 Auto merge of #88558 - fee1-dead:const-drop, r=oli-obk
Const drop

The changes are pretty primitive at this point. But at least it works. ^-^

Problems with the current change that I can think of now:
 - [x] `~const Drop` shouldn't change anything in the non-const world.
 - [x] types that do not have drop glues shouldn't fail to satisfy `~const Drop` in const contexts. `struct S { a: u8, b: u16 }` This might not fail for `needs_non_const_drop`, but it will fail in `rustc_trait_selection`.
 - [x] The current change accepts types that have `const Drop` impls but have non-const `Drop` glue.

Fixes #88424.

Significant Changes:

- `~const Drop` is no longer treated as a normal trait bound. In non-const contexts, this bound has no effect, but in const contexts, this restricts the input type and all of its transitive fields to either a) have a `const Drop` impl or b) can be trivially dropped (i.e. no drop glue)
- `T: ~const Drop` will not be linted like `T: Drop`.
- Instead of recursing and iterating through the type in `rustc_mir::transform::check_consts`, we use the trait system to special case `~const Drop`. See [`rustc_trait_selection::...::candidate_assembly#assemble_const_drop_candidates`](https://github.com/fee1-dead/rust/blob/const-drop/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs#L817) and others.

Changes not related to `const Drop`ping and/or changes that are insignificant:

 - `Node.constness_for_typeck` no longer returns `hir::Constness::Const` for type aliases in traits. This was previously used to hack how we determine default bound constness for items. But because we now use an explicit opt-in, it is no longer needed.
 - Removed `is_const_impl_raw` query. We have `impl_constness`, and the only existing use of that query uses `HirId`, which means we can just operate it with hir.
 - `ty::Destructor` now has a field `constness`, which represents the constness of the destructor.

r? `@oli-obk`
2021-09-15 03:51:03 +00:00
Camille GILLOT
fa6f5adf73 Gather module items after lowering. 2021-09-12 16:33:16 +02:00
Gus Wynn
2271376fb2 must_not_suspend impl 2021-09-11 10:45:17 -07:00
Jubilee
5648859e50
Rollup merge of #88779 - estebank:unused-delims, r=davidtwco
Use more accurate spans for "unused delimiter" lint
2021-09-11 08:23:43 -07:00
Esteban Kuber
dc02b51382 Use more accurate spans for "unused delimiter" lint 2021-09-09 14:24:33 +00:00
Andreas Liljeqvist
5b2f757dae Make abi::Abi Copy and remove a *lot* of refs
fix

fix

Remove more refs and clones

fix

more

fix
2021-09-09 10:41:19 +02:00
Deadbeef
48a3ba9a33
fmt 2021-09-09 05:21:30 +00:00
Deadbeef
9125fbfd60
Do not lint for ~const Drop bounds 2021-09-09 05:21:29 +00:00
bors
7849e3e9dd Auto merge of #88435 - cjgillot:no-walk-crate, r=Aaron1011
Avoid invoking the hir_crate query to traverse the HIR

Walking the HIR tree is done using the `hir_crate` query. However, this is unnecessary, since `hir_owner(CRATE_DEF_ID)` provides the same information. Since depending on `hir_crate` forces dependents to always be executed, this leads to unnecessary work.

By splitting HIR and attributes visits, we can avoid an edge to `hir_crate` when trying to visit the HIR tree.
2021-09-05 21:40:34 +00:00
bors
e2750baf53 Auto merge of #88499 - eddyb:layout-off, r=nagisa
Provide `layout_of` automatically (given tcx + param_env + error handling).

After #88337, there's no longer any uses of `LayoutOf` within `rustc_target` itself, so I realized I could move the trait to `rustc_middle::ty::layout` and redesign it a bit.

This is similar to #88338 (and supersedes it), but at no ergonomic loss, since there's no funky `C: LayoutOf<Ty = Ty>` -> `Ty: TyAbiInterface<C>` generic `impl` chain, and each `LayoutOf` still corresponds to one `impl` (of `LayoutOfHelpers`) for the specific context.

After this PR, this is what's needed to get `trait LayoutOf` (with the `layout_of` method) implemented on some context type:
* `TyCtxt`, via `HasTyCtxt`
* `ParamEnv`, via `HasParamEnv`
* a way to transform `LayoutError`s into the desired error type
  * an error type of `!` can be paired with having `cx.layout_of(...)` return `TyAndLayout` *without* `Result<...>` around it, such as used by codegen
  * this is done through a new `LayoutOfHelpers` trait (and so is specifying the type of `cx.layout_of(...)`)

When going through this path (and not bypassing it with a manual `impl` of `LayoutOf`), the end result is that only the error case can be customized, the query itself and the success paths are guaranteed to be uniform.

(**EDIT**: just noticed that because of the supertrait relationship, you cannot actually implement `LayoutOf` yourself, the blanket `impl` fully covers all possible context types that could ever implement it)

Part of the motivation for this shape of API is that I've been working on querifying `FnAbi::of_*`, and what I want/need to introduce for that looks a lot like the setup in this PR - in particular, it's harder to express the `FnAbi` methods in `rustc_target`, since they're much more tied to `rustc` concepts.

r? `@nagisa` cc `@oli-obk` `@bjorn3`
2021-09-05 16:14:41 +00:00
bors
72a51c39c6 Auto merge of #88547 - notriddle:notriddle/is-expr-delims-necessary, r=davidtwco
fix(rustc_lint): better detect when parens are necessary

Fixes #88519
2021-09-04 09:46:58 +00:00
Camille GILLOT
d119a13137 Rename walk_crate. 2021-09-02 19:23:11 +02:00
Mara Bos
ea82d0651a
Rollup merge of #88512 - m-ou-se:array-into-iter-deref-stuff, r=estebank
Upgrade array_into_iter lint to include Deref-to-array types.

Fixes https://github.com/rust-lang/rust/issues/88099

Fixes the issue mentioned here: https://github.com/rust-lang/rust/pull/84147#issuecomment-819000436
2021-09-02 19:10:15 +02:00
Camille GILLOT
7ec973d9ce Stop using walk_crate. 2021-09-02 19:08:58 +02:00
Eduard-Mihai Burtescu
f53c93cf65 ty::layout: split LayoutOf into required and (blanket) provided halves. 2021-09-02 01:17:14 +03:00
Eduard-Mihai Burtescu
1e02262dcc ty::layout: implement layout_of automatically as a default method. 2021-09-02 01:17:14 +03:00
Eduard-Mihai Burtescu
4ce933f13f rustc_target: move LayoutOf to ty::layout. 2021-09-02 01:17:14 +03:00
Michael Howell
59b245e754 fix(rustc_lint): better detect when parens are necessary
Fixes #88519
2021-08-31 21:48:25 -07:00
bors
c2a408840a Auto merge of #87688 - camsteffen:let-else, r=cjgillot
Introduce `let...else`

Tracking issue: #87335

The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect.

Overall, I believe this PR is feature-complete with regard to the RFC.
2021-09-01 01:02:42 +00:00
Mara Bos
caca256b52
Rollup merge of #88503 - m-ou-se:array-into-inter-ambiguous, r=cjgillot
Warn when [T; N].into_iter() is ambiguous in the new edition.

Fixes https://github.com/rust-lang/rust/issues/88475

In https://github.com/rust-lang/rust/issues/88475, a situation was found where `[T; N].into_iter()` becomes *ambiguous* in the new edition. This is different than the case where `(&[T; N]).into_iter()` resolves differently, which was the only case handled by the `array_into_iter` lint. This is almost identical to the new-traits-in-the-prelude problem. Effectively, due to the array-into-iter hack disappearing in Rust 2021, we effectively added `IntoIterator` to the 'prelude' in Rust 2021 specifically for arrays.

This modifies the prelude collisions lint to detect that case and emit a `array_into_iter` lint in that case.
2021-08-31 10:41:29 +02:00
Cameron Steffen
29bc94ff0d Handle let-else initializer edge case errors 2021-08-30 20:18:42 -05:00
Cameron Steffen
89d2600d01 Add let-else to AST 2021-08-30 20:17:45 -05:00
Mara Bos
90080f4703 Don't give invalid suggestions in array_into_iter. 2021-08-30 23:43:38 +02:00
Mara Bos
422ad3bec2 Upgrade array_into_iter lint to include Deref-to-array types. 2021-08-30 23:43:38 +02:00
Mara Bos
336f31432d Warn when [T; N].into_iter() is ambiguous in the new edition. 2021-08-30 21:27:31 +02:00
lcnr
0c28e028b6 feature(const_generics) -> feature(const_param_types) 2021-08-30 11:00:21 +02:00
bors
9556d7a09a Auto merge of #88337 - eddyb:field-failure-is-not-an-option, r=nagisa
rustc_target: `TyAndLayout::field` should never error.

This refactor (making `TyAndLayout::field` return `TyAndLayout` without any `Result` around it) is based on a simple observation, regarding `TyAndLayout::field`:

If `cx.layout_of(ty)` succeeds (for some `cx` and `ty`), then `.field(cx, i)` on the resulting `TyAndLayout` should *always* succeed in computing `cx.layout_of(field_ty)` (where `field_ty` is the type of the `i`th field of `ty`).

The reason for this is that no matter which field is chosen, `cx.layout_of(field_ty)` *will have already been computed*, as part of computing `cx.layout_of(ty)`, as we cannot determine the layout of *any* type without considering the layouts of *all* of its fields.

And so it should be fine to turn any errors into ICEs, since they likely indicate a `cx` mismatch, or some other edge case that is due to a compiler bug (as opposed to ever being an user-facing error).

<hr/>

Each commit should probably be reviewed separately, though note that there's some `where` clauses (in `rustc_target::abi::call::*`) that change in most commits.

cc `@nagisa` `@oli-obk`
2021-08-29 22:54:26 +00:00
inquisitivecrystal
8c62fa0575 Treat macros as HIR items 2021-08-28 00:16:34 -07:00
Eduard-Mihai Burtescu
87d1fb747f rustc_target: require TyAbiInterface in LayoutOf. 2021-08-27 13:09:32 +03:00
Eduard-Mihai Burtescu
83d986aa28 rustc_target: add lifetime parameter to LayoutOf. 2021-08-27 13:09:32 +03:00
lcnr
f3996f6a88 review 2021-08-26 11:14:31 +02:00
lcnr
ab9108b70f update TypeFlags to deal with missing ct substs 2021-08-26 11:00:30 +02:00
lcnr
cc47998e28 add tcx to fn walk 2021-08-26 11:00:30 +02:00
lcnr
bfaf13af4e make unevaluated const substs optional 2021-08-26 11:00:30 +02:00
lcnr
f4b606fd17 require a tcx for TypeVisitor 2021-08-26 10:54:01 +02:00
Léo Lanteri Thauvin
891fa3c555
Rollup merge of #88196 - asquared31415:named-asm-labels-refactor, r=Amanieu
Refactor `named_asm_labels` to a HIR lint

As discussed on #88169, the `named_asm_labels` lint could be moved to a HIR lint.  That allows future lints or custom plugins or clippy lints to more easily access the `asm!` macro's data and create better error messages with the lints.
2021-08-25 15:48:50 +02:00
bors
e5484cec0e Auto merge of #88242 - bonega:allocation_range, r=oli-obk
Use custom wrap-around type instead of RangeInclusive

Two reasons:

1. More memory is allocated than necessary for `valid_range` in `Scalar`. The range is not used as an iterator and `exhausted` is never used.
2. `contains`, `count` etc. methods in `RangeInclusive` are doing very unhelpful(and dangerous!) things when used as a wrap-around range. - In general this PR wants to limit potentially confusing methods, that have a low probability of working.

Doing a local perf run, every metric shows improvement except for instructions.
Max-rss seem to have a very consistent improvement.

Sorry - newbie here, probably doing something wrong.
2021-08-25 02:17:41 +00:00
asquared31415
0b81c2eb82 Move named_asm_labels to a HIR lint 2021-08-24 08:23:58 -04:00
bors
f66e825f73 Auto merge of #87739 - Aaron1011:remove-used-attrs, r=wesleywiser
Remove `Session.used_attrs` and move logic to `CheckAttrVisitor`

Instead of updating global state to mark attributes as used,
we now explicitly emit a warning when an attribute is used in
an unsupported position. As a side effect, we are to emit more
detailed warning messages (instead of just a generic "unused" message).

`Session.check_name` is removed, since its only purpose was to mark
the attribute as used. All of the callers are modified to use
`Attribute.has_name`

Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed
used' attribute is implemented by simply not performing any checks
in `CheckAttrVisitor` for a particular attribute.

We no longer emit unused attribute warnings for the `#[rustc_dummy]`
attribute - it's an internal attribute used for tests, so it doesn't
mark sense to treat it as 'unused'.

With this commit, a large source of global untracked state is removed.
2021-08-24 03:58:22 +00:00
Mara Bos
5cf025f076
Rollup merge of #88230 - steffahn:a_an, r=oli-obk
Fix typos “a”→“an”

Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an.

While automation was used to find these, every change was checked manually.

Changes in submodules get separate PRs:
* https://github.com/rust-lang/stdarch/pull/1201
* https://github.com/rust-lang/cargo/pull/9821
* https://github.com/rust-lang/miri/pull/1874
* https://github.com/rust-lang/rls/pull/1746
* https://github.com/rust-analyzer/rust-analyzer/pull/9984
  _folks @ rust-analyzer are fast at merging…_
  * https://github.com/rust-analyzer/rust-analyzer/pull/9985
  * https://github.com/rust-analyzer/rust-analyzer/pull/9987
  * https://github.com/rust-analyzer/rust-analyzer/pull/9989

_For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._

<hr>

This has some overlap with #88226, but neither is a strict superset of the other.

If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.
2021-08-23 20:45:49 +02:00
Andreas Liljeqvist
5a501f73ff Use custom wrap-around type instead of Range 2021-08-22 21:46:03 +02:00
Guillaume Gomez
2627db6a3c
Rollup merge of #86747 - FabianWolff:issue-86653, r=GuillaumeGomez
Improve wording of the `drop_bounds` lint

This PR addresses #86653. The issue is sort of a false positive of the `drop_bounds` lint, but I would argue that the best solution for #86653 is simply a rewording of the warning message and lint description, because even if the lint is _technically_ wrong, it still forces the programmer to think about what they are doing, and they can always use `#[allow(drop_bounds)]` if they think that they really need the `Drop` bound.

There are two issues with the current warning message and lint description:
- First, it says that `Drop` bounds are "useless", which is technically incorrect because they actually do have the effect of allowing you e.g. to call methods that also have a `Drop` bound on their generic arguments for some reason. I have changed the wording to emphasize not that the bound is "useless", but that it is most likely not what was intended.
- Second, it claims that `std::mem::needs_drop` detects whether a type has a destructor. But I think this is also technically wrong: The `Drop` bound says whether the type has a destructor or not, whereas `std::mem::needs_drop` also takes nested types with destructors into account, even if the top-level type does not itself have one (although I'm not 100% sure about the exact terminology here, i.e. whether the "drop glue" of the top-level type counts as a destructor or not).

cc `@jonhoo,` does this solve the issue for you?

r? `@GuillaumeGomez`
2021-08-22 20:52:50 +02:00
Frank Steffahn
2396fad095 Fix more “a”/“an” typos 2021-08-22 17:27:18 +02:00
Frank Steffahn
bf88b113ea Fix typos “a”→“an” 2021-08-22 15:35:11 +02:00
Aaron Hill
af46699f81
Remove Session.used_attrs and move logic to CheckAttrVisitor
Instead of updating global state to mark attributes as used,
we now explicitly emit a warning when an attribute is used in
an unsupported position. As a side effect, we are to emit more
detailed warning messages (instead of just a generic "unused" message).

`Session.check_name` is removed, since its only purpose was to mark
the attribute as used. All of the callers are modified to use
`Attribute.has_name`

Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed
used' attribute is implemented by simply not performing any checks
in `CheckAttrVisitor` for a particular attribute.

We no longer emit unused attribute warnings for the `#[rustc_dummy]`
attribute - it's an internal attribute used for tests, so it doesn't
mark sense to treat it as 'unused'.

With this commit, a large source of global untracked state is removed.
2021-08-21 13:27:27 -05:00
bors
99b73e81b3 Auto merge of #88134 - rylev:force-warn-improvements, r=nikomatsakis
Force warn improvements

As part of stablization of the `--force-warn` option (#86516) I've made the following changes:
* Error when the `warnings` lint group is based to the `--force-warn` option
* Tests have been updated to make it easier to understand the semantics of `--force-warn`

r? `@nikomatsakis`
2021-08-21 15:51:50 +00:00
Niko Matsakis
947c0de028 introduce a Coerce predicate 2021-08-19 17:28:24 -04:00
Ryan Levick
d70056e30c Error when warnings lint group is used with force-warn 2021-08-18 11:53:59 +02:00
est31
dd4cc0c57d Remove box syntax from rustc_lint 2021-08-18 09:31:51 +02:00
bors
d83da1d05d Auto merge of #88083 - m-ou-se:non-fmt-panics-suggest-debug, r=estebank
Improve non_fmt_panics suggestion based on trait impls.

This improves the non_fmt_panics lint suggestions by checking first which trait (Display or Debug) are actually implemented on the type.

Fixes https://github.com/rust-lang/rust/issues/87313

Fixes https://github.com/rust-lang/rust/issues/87999

Before:

```
help: add a "{}" format string to Display the message
  |
2 |     panic!("{}", Some(1));
  |            +++++
help: or use std::panic::panic_any instead
  |
2 |     std::panic::panic_any(Some(1));
  |     ~~~~~~~~~~~~~~~~~~~~~
```

After:

```
help: add a "{:?}" format string to use the Debug implementation of `Option<i32>`
  |
2 |     panic!("{:?}", Some(1));
  |            +++++++
help: or use std::panic::panic_any instead
  |
2 |     std::panic::panic_any(Some(1));
  |     ~~~~~~~~~~~~~~~~~~~~~
```

r? `@estebank`
2021-08-17 16:43:40 +00:00
Mara Bos
beeff0440f
Rollup merge of #87967 - m-ou-se:non-fmt-panic-detect-fake-spans, r=cjgillot
Detect fake spans in non_fmt_panic lint.

This addresses https://github.com/rust-lang/rust/issues/87621

Some proc_macros claim that the user wrote all of the tokens it outputs, by applying a span from the input to all of the produced tokens. That can result in confusing suggestions, as in #87621. This is a simple patch that avoids suggesting anything for `panic!("{}")` if the span of `"{}"` and `panic!(..)` are identical, which is normally not possible.
2021-08-16 23:37:28 +02:00
Mara Bos
ab8cbc3190 Show correct macro name in non_fmt_panics message. 2021-08-16 17:39:50 +02:00
Mara Bos
0a313250a4 Improve non_fmt_panics suggestion based on trait impls. 2021-08-16 17:25:35 +02:00
bors
92f3753b07 Auto merge of #84039 - jyn514:uplift-atomic-ordering, r=wesleywiser
Uplift the invalid_atomic_ordering lint from clippy to rustc

This is mostly just a rebase of https://github.com/rust-lang/rust/pull/79654; I've copy/pasted the text from that PR below.

r? `@lcnr` since you reviewed the last one, but feel free to reassign.

---

This is an implementation of https://github.com/rust-lang/compiler-team/issues/390.

As mentioned, in general this turns an unconditional runtime panic into a (compile time) lint failure. It has no false positives, and the only false negatives I'm aware of are if `Ordering` isn't specified directly and is comes from an argument/constant/whatever.

As a result of it having no false positives, and the alternative always being strictly wrong, it's on as deny by default. This seems right.

In the [zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Uplift.20the.20.60invalid_atomic_ordering.60.20lint.20from.20clippy/near/218483957) `@joshtriplett` suggested that lang team should FCP this before landing it. Perhaps libs team cares too?

---

Some notes on the code for reviewers / others below

## Changes from clippy

The code is changed from [the implementation in clippy](68cf94f6a6/clippy_lints/src/atomic_ordering.rs) in the following ways:

1. Uses `Symbols` and `rustc_diagnostic_item`s instead of string literals.
    - It's possible I should have just invoked Symbol::intern for some of these instead? Seems better to use symbol, but it did require adding several.
2. The functions are moved to static methods inside the lint struct, as a way to namespace them.
    - There's a lot of other code in that file — which I picked as the location for this lint because `@jyn514` told me that seemed reasonable.
3. Supports unstable AtomicU128/AtomicI128.
    - I did this because it was almost easier to support them than not — not supporting them would have (ideally) required finding a way not to give them a `rustc_diagnostic_item`, which would have complicated an already big macro.
    - These don't have tests since I wasn't sure if/how I should make tests conditional on whether or not the target has the atomic... This is to a certain extent an issue of 64bit atomics too, but 128-bit atomics are much less common. Regardless, the existing tests should be *more* than thorough enough here.
4. Minor changes like:
    - grammar tweaks ("loads cannot have `Release` **and** `AcqRel` ordering" => "loads cannot have `Release` **or** `AcqRel` ordering")
    - function renames (`match_ordering_def_path` => `matches_ordering_def_path`),
    - avoiding clippy-specific helper methods that don't exist in rustc_lint and didn't seem worth adding for this case (for example `cx.struct_span_lint` vs clippy's `span_lint_and_help` helper).

## Potential issues

(This is just about the code in this PR, not conceptual issues with the lint or anything)

1. I'm not sure if I should have used a diagnostic item for `Ordering` and its variants (I couldn't figure out how really, so if I should do this some pointers would be appreciated).
    - It seems possible that failing to do this might possibly mean there are more cases this lint would miss, but I don't really know how `match_def_path` works and if it has any pitfalls like that, so maybe not.

2. I *think* I deprecated the lint in clippy (CC `@flip1995` who asked to be notified about clippy changes in the future in [this comment](https://github.com/rust-lang/rust/pull/75671#issuecomment-718731659)) but I'm not sure if I need to do anything else there.
    - I'm kind of hoping CI will catch if I missed anything, since `x.py test src/tools/clippy` fails with a lot of errors with and without my changes (and is probably a nonsense command regardless). Running `cargo test` from src/tools/clippy also fails with unrelated errors that seem like refactorings that didnt update clippy? So, honestly no clue.

3. I wasn't sure if the description/example I gave good. Hopefully it is. The example is less thorough than the one from clippy here: https://rust-lang.github.io/rust-clippy/master/index.html#invalid_atomic_ordering. Let me know if/how I should change it if it needs changing.

4. It pulls in the `if_chain` crate. This crate was already used in clippy, and seems like it's used elsewhere in rustc, but I'm willing to rewrite it to not use this if needed (I'd prefer not to, all things being equal).
2021-08-16 06:36:13 +00:00
Joshua Nelson
5522177db6 Only run expensive calculations if the method name is recognized 2021-08-16 03:55:27 +00:00
Thom Chiovoloni
402a9c9f5e Uplift the invalid_atomic_ordering lint from clippy to rustc
- Deprecate clippy::invalid_atomic_ordering
- Use rustc_diagnostic_item for the orderings in the invalid_atomic_ordering lint
- Reduce code duplication
- Give up on making enum variants diagnostic items and just look for
`Ordering` instead

  I ran into tons of trouble with this because apparently the change to
  store HIR attrs in a side table also gave the DefIds of the
  constructor instead of the variant itself. So I had to change
  `matches_ordering` to also check the grandparent of the defid as well.

- Rename `atomic_ordering_x` symbols to just the name of the variant
- Fix typos in checks - there were a few places that said "may not be
  Release" in the diagnostic but actually checked for SeqCst in the lint.
- Make constant items const
- Use fewer diagnostic items
- Only look at arguments after making sure the method matches

  This prevents an ICE when there aren't enough arguments.

- Ignore trait methods
- Only check Ctors instead of going through `qpath_res`

  The functions take values, so this couldn't ever be anything else.

- Add if_chain to allowed dependencies
- Fix grammar
- Remove unnecessary allow
2021-08-16 03:55:27 +00:00
bors
2a6fb9a4c0 Auto merge of #80357 - c410-f3r:new-hir-let, r=matthewjasper
Introduce `hir::ExprKind::Let` - Take 2

Builds on #68577 and depends on #79328.

cc #53667
2021-08-16 00:31:42 +00:00
Caio
6aa9937a76 Introduce hir::ExprKind::Let - Take 2 2021-08-15 16:18:26 -03:00
bors
2d2bc94c8c Auto merge of #87982 - m-ou-se:non-fmt-panic-assert-str, r=cjgillot
Add automatic migration for assert!(.., string).

Fixes part of #87313.
2021-08-15 17:57:39 +00:00
bors
e55c13e109 Auto merge of #87324 - asquared31415:named-asm-labels, r=Amanieu
Lint against named asm labels

This adds a deny-by-default lint to prevent the use of named labels in inline `asm!`.  Without a solution to #81088 about whether the compiler should rewrite named labels or a special syntax for labels, a lint against them should prevent users from writing assembly that could break for internal compiler reasons, such as inlining or anything else that could change the number of actual inline assembly blocks emitted.

This does **not** resolve the issue with rewriting labels, that still needs a decision if the compiler should do any more work to try to make them work.
2021-08-14 17:33:38 +00:00
bors
136eaa1b25 Auto merge of #87375 - fee1-dead:move-constness-to-traitpred, r=oli-obk
Try filtering out non-const impls when we expect const impls

**TL;DR**: Associated types on const impls are now bounded; we now disallow calling a const function with bounds when the specified type param only has a non-const impl.

r? `@oli-obk`
2021-08-14 12:06:34 +00:00
bors
5a19ffe1c2 Auto merge of #86492 - hyd-dev:no-mangle-method, r=petrochenkov
Associated functions that contain extern indicator or have `#[rustc_std_internal_symbol]` are reachable

Previously these fails to link with ``undefined reference to `foo'``:

<details>
<summary>Example 1</summary>

```rs
struct AssocFn;

impl AssocFn {
    #[no_mangle]
    fn foo() {}
}

fn main() {
    extern "Rust" {
        fn foo();
    }
    unsafe { foo() }
}
```
([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f1244afcdd26e2a28445f6e82ca46b50))
</details>

<details>
<summary>Example 2</summary>

```rs
#![crate_name = "lib"]
#![crate_type = "lib"]

struct AssocFn;

impl AssocFn {
    #[no_mangle]
    fn foo() {}
}
```
```rs
extern crate lib;

fn main() {
    extern "Rust" {
        fn foo();
    }
    unsafe { foo() }
}
```
</details>

But I believe they should link successfully, because this works:
<details>

```rs
#[no_mangle]
fn foo() {}

fn main() {
    extern "Rust" {
        fn foo();
    }
    unsafe { foo() }
}
```
([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=789b3f283ee6126f53939429103ed98d))
</details>

This PR fixes the problem, by adding associated functions that have "custom linkage" to `reachable_set`, just like normal functions.

I haven't tested whether #76211 and [Miri](https://github.com/rust-lang/miri/issues/1837) are fixed by this PR yet, but I'm submitting this anyway since this fixes the examples above.

I added a `run-pass` test that combines my two examples above, but I'm not sure if that's the right way to test this. Maybe I should add / modify an existing codegen test (`src/test/codegen/export-no-mangle.rs`?) instead?
2021-08-13 19:47:03 +00:00
Mara Bos
8fedb31649 Use is_diagnostic_item instead of get_diagnostic_item. 2021-08-13 12:21:31 +02:00
Mara Bos
b4f448a7ea non_fmt_panic: machine app. suggestion for assert with string msg. 2021-08-13 11:50:32 +02:00
Deadbeef
32390a0df6
move Constness into TraitPredicate 2021-08-13 09:26:33 +00:00
Manish Goregaokar
2d27976b8b
Rollup merge of #87965 - m-ou-se:non-fmt-panic-external, r=estebank
Silence non_fmt_panic from external macros.

This stops the non_fmt_panic lint from triggering if a macro from another crate is entirely responsible. In those cases there's nothing that the current crate can/should do.

See also https://github.com/rust-lang/rust/issues/87621#issuecomment-890311054
2021-08-12 10:04:16 -07:00
Mara Bos
079bf755a3 Detect fake spans in non_fmt_panic lint. 2021-08-12 14:56:41 +02:00
Mara Bos
a6da55c70e Silence non_fmt_panic from external macros. 2021-08-12 14:33:30 +02:00
hyd-dev
0bb2ea653e
Adjust #[no_mangle]-related checks and lints for impl items 2021-08-12 17:11:44 +08:00
Mara Bos
260f9b9e91 Link to edition guide instead of issues for 2021 lints. 2021-08-09 17:45:01 +02:00
bors
7129033b42 Auto merge of #87462 - ibraheemdev:tidy-file-length-ignore-comment, r=Mark-Simulacrum
Ignore comments in tidy-filelength

Ref https://github.com/rust-lang/rust/issues/60302#issuecomment-652402127
2021-08-06 02:07:01 +00:00
asquared31415
1ae19b69e8 Fix lint capitalization and ignoring, test with include_str 2021-08-04 13:38:17 -04:00
asquared31415
75915ad16f Lint against named asm labels 2021-08-04 13:38:17 -04:00
bors
49ca3d9796 Auto merge of #87026 - FabianWolff:issue-86948, r=estebank
Allow labeled loops as value expressions for `break`

Fixes #86948. This is currently allowed:
```rust
return 'label: loop { break 'label 42; };
break ('label: loop { break 'label 42; });
break 1 + 'label: loop { break 'label 42; };
break 'outer 'inner: loop { break 'inner 42; };
```
But not this:
```rust
break 'label: loop { break 'label 42; };
```
I have fixed this, so that the above now parses as an unlabeled break with a labeled loop as its value expression.
2021-08-04 07:17:25 +00:00
bors
bb744e1e9f Auto merge of #87568 - petrochenkov:localevel, r=cjgillot
rustc: Replace `HirId`s with `LocalDefId`s in `AccessLevels` tables

and passes using those tables - primarily privacy checking, stability checking and dead code checking.

All these passes work with definitions rather than with arbitrary HIR nodes.
r? `@cjgillot`
cc `@lambinoo` (#87487)
2021-08-04 02:04:04 +00:00
Fabian Wolff
7c81132a60 Use a multipart suggestion for the parentheses 2021-08-03 21:23:29 +02:00
bors
b53a93db2d Auto merge of #87535 - lf-:authors, r=Mark-Simulacrum
rfc3052 followup: Remove authors field from Cargo manifests

Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
2021-08-02 05:49:17 +00:00
bors
aadd6189ad Auto merge of #87449 - matthiaskrgr:clippyy_v2, r=nagisa
more clippy::complexity fixes

(also a couple of clippy::perf fixes)
2021-08-01 09:15:15 +00:00
Fabian Wolff
470cbc0e2e Require parentheses to avoid confusions around labeled break and loop expressions 2021-07-31 19:10:58 +02:00
Vadim Petrochenkov
b08576b2ad rustc: Replace HirIds with LocalDefIds in AccessLevels tables
and passes using them - primarily privacy checking, stability checking and dead code checking.

WIP
2021-07-31 19:31:29 +03:00
Fabian Wolff
4e76c3820f Fix ICE in improper_ctypes_definitions lint with all-ZST transparent types 2021-07-31 15:57:51 +02:00
Yuki Okushi
924eddf30d
Apply review suggestion 2021-07-31 06:21:52 +09:00
Yuki Okushi
eaff0fc25b
Add a hint that the expressions produce a value 2021-07-31 06:12:42 +09:00
Jade
3cf820e17d rfc3052: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field anyway, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information, we should remove it from
crates in this repo.
2021-07-29 14:56:05 -07:00
bors
fd853c00e2 Auto merge of #83484 - JulianKnodt:infer, r=oli-obk,lcnr
Add hir::GenericArg::Infer

In order to extend inference to consts, make an Infer type on hir::GenericArg.
2021-07-27 16:24:45 +00:00
ibraheemdev
3171bd5bf5 ignore comments in tidy-filelength 2021-07-25 17:10:51 -04:00
bors
6489ee1041 Auto merge of #83723 - cjgillot:ownernode, r=petrochenkov
Store all HIR owners in the same container

This replaces the previous storage in a BTreeMap for each of Item/ImplItem/TraitItem/ForeignItem.
This should allow for a more compact storage.

Based on https://github.com/rust-lang/rust/pull/83114
2021-07-25 11:11:02 +00:00
Matthias Krüger
3fd8cbb404 clippy::useless_format 2021-07-25 12:26:03 +02:00
Matthias Krüger
d0a8a12dc6 clippy::flat_map_identity 2021-07-25 12:26:03 +02:00
Camille GILLOT
fee421685d Introduce OwnerNode::Crate. 2021-07-25 12:22:47 +02:00
Camille GILLOT
36a28060f1 Merge the BTreeMap in hir::Crate. 2021-07-25 12:18:56 +02:00
kadmin
3605675bb1 Add inferred args to typeck 2021-07-25 07:28:51 +00:00
Aaron Hill
0df5ac8269
Display an extra note for trailing semicolon lint with trailing macro
Currently, we parse macros at the end of a block
(e.g. `fn foo() { my_macro!() }`) as expressions, rather than
statements. This means that a macro invoked in this position
cannot expand to items or semicolon-terminated expressions.

In the future, we might want to start parsing these kinds of macros
as statements. This would make expansion more 'token-based'
(i.e. macro expansion behaves (almost) as if you just textually
replaced the macro invocation with its output). However,
this is a breaking change (see PR #78991), so it will require
further discussion.

Since the current behavior will not be changing any time soon,
we need to address the interaction with the
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint. Since we are parsing
the result of macro expansion as an expression, we will emit a lint
if there's a trailing semicolon in the macro output. However, this
results in a somewhat confusing message for users, since it visually
looks like there should be no problem with having a semicolon
at the end of a block
(e.g. `fn foo() { my_macro!() }` => `fn foo() { produced_expr; }`)

To help reduce confusion, this commit adds a note explaining
that the macro is being interpreted as an expression. Additionally,
we suggest adding a semicolon after the macro *invocation* - this
will cause us to parse the macro call as a statement. We do *not*
use a structured suggestion for this, since the user may actually
want to remove the semicolon from the macro definition (allowing
the block to evaluate to the expression produced by the macro).
2021-07-24 11:46:44 -05:00
bors
18840b0719 Auto merge of #87296 - Aaron1011:inert-warn, r=petrochenkov
Warn on inert attributes used on bang macro invocation

These attributes are currently discarded.
This may change in the future (see #63221), but for now,
placing inert attributes on a macro invocation does nothing,
so we should warn users about it.

Technically, it's possible for there to be attribute macro
on the same macro invocation (or at a higher scope), which
inspects the inert attribute. For example:

```rust
#[look_for_inline_attr]
#[inline]
my_macro!()

#[look_for_nested_inline]
mod foo { #[inline] my_macro!() }
```

However, this would be a very strange thing to do.
Anyone running into this can manually suppress the warning.
2021-07-24 13:19:17 +00:00
Ryan Levick
800c5f9202 Rename force-warns to force-warn 2021-07-21 15:41:10 +02:00
bors
c9aa2595d9 Auto merge of #84959 - camsteffen:lint-suggest-group, r=estebank
Suggest lint groups

Fixes rust-lang/rust-clippy#6986
2021-07-20 02:11:55 +00:00
Aaron Hill
070df9e676
Warn on inert attributes used on bang macro invocation
These attributes are currently discarded.
This may change in the future (see #63221), but for now,
placing inert attributes on a macro invocation does nothing,
so we should warn users about it.

Technically, it's possible for there to be attribute macro
on the same macro invocation (or at a higher scope), which
inspects the inert attribute. For example:

```rust
#[look_for_inline_attr]
#[inline]
my_macro!()

#[look_for_nested_inline]
mod foo { #[inline] my_macro!() }
```

However, this would be a very strange thing to do.
Anyone running into this can manually suppress the warning.
2021-07-19 17:49:28 -05:00
bors
b543e0dc03 Auto merge of #86970 - inquisitivecrystal:force-warn, r=davidtwco
Make `--force-warns` a normal lint level option

Now that `ForceWarn` is a lint level, there's no reason `--force-warns` should be treated differently from other options that set lint levels. This merges the `ForceWarn` handling in with the other lint level command line options. It also unifies all of the relevant selection logic in `compiler/rustc_lint/src/levels.rs`, rather than having some of it weirdly elsewhere.

Fixes #86958, which arose from the special-cased handling of `ForceWarn` having had an error in it.
2021-07-19 13:18:04 +00:00
bors
0ecff8c623 Auto merge of #87146 - Aaron1011:better-macro-lint, r=petrochenkov
Compute a better `lint_node_id` during expansion

When we need to emit a lint at a macro invocation, we currently use the
`NodeId` of its parent definition (e.g. the enclosing function). This
means that any `#[allow]` / `#[deny]` attributes placed 'closer' to the
macro (e.g. on an enclosing block or statement) will have no effect.

This commit computes a better `lint_node_id` in `InvocationCollector`.
When we visit/flat_map an AST node, we assign it a `NodeId` (earlier
than we normally would), and store than `NodeId` in current
`ExpansionData`. When we collect a macro invocation, the current
`lint_node_id` gets cloned along with our `ExpansionData`, allowing it
to be used if we need to emit a lint later on.

This improves the handling of `#[allow]` / `#[deny]` for
`SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` and some `asm!`-related lints.
The 'legacy derive helpers' lint retains its current behavior
(I've inlined the now-removed `lint_node_id` function), since
there isn't an `ExpansionData` readily available.
2021-07-19 04:22:51 +00:00
Michael Howell
dbd4fd5716 feat(rustc_lint): add dyn_drop
Based on the conversation in #86747.

Explanation
-----------

A trait object bound of the form `dyn Drop` is most likely misleading
and not what the programmer intended.

`Drop` bounds do not actually indicate whether a type can be trivially
dropped or not, because a composite type containing `Drop` types does
not necessarily implement `Drop` itself. Naïvely, one might be tempted
to write a deferred drop system, to pull cleaning up memory out of a
latency-sensitive code path, using `dyn Drop` trait objects. However,
this breaks down e.g. when `T` is `String`, which does not implement
`Drop`, but should probably be accepted.

To write a trait object bound that accepts anything, use a placeholder
trait with a blanket implementation.

```rust
trait Placeholder {}
impl<T> Placeholder for T {}
fn foo(_x: Box<dyn Placeholder>) {}
```
2021-07-18 07:55:57 -07:00
inquisitivecrystal
2f2db99432 Make --force-warns a normal lint level option 2021-07-17 23:13:59 -07:00
Aaron Hill
d6e3c11101
Add additional missing lint handling logic 2021-07-17 23:03:58 -05:00
Aaron Hill
2bd15a25ef
Add missing visit_expr_field 2021-07-17 23:03:57 -05:00
Jack Huey
f1ab6f93e6 Make GATs no longer incomplete 2021-07-16 00:22:01 -04:00
bors
3e1c75c6e2 Auto merge of #86827 - camsteffen:hash-lint-resolved, r=oli-obk
Fix internal `default_hash_types` lint to use resolved path

I run into false positives now and then (mostly in Clippy) when I want to name some util after HashMap.
2021-07-13 15:06:10 +00:00
Vadim Petrochenkov
28f4dba438 rustc_span: Revert addition of proc_macro field to ExpnKind::Macro
The flag has a vague meaning and is used for a single diagnostic change that is low benefit and appears only under `-Z macro_backtrace`.
2021-07-10 23:03:35 +03:00
bors
8eae2eb1d3 Auto merge of #86968 - inquisitivecrystal:missing-docs-v2, r=oli-obk
Remove `missing_docs` lint on private 2.0 macros

798baebde1/compiler/rustc_lint/src/builtin.rs (L573-L584)

This code is the source of #57569. The problem is subtle, so let me point it out. This code makes the mistake of assuming that all of the macros in `krate.exported_macros` are exported.

...Yeah. For some historical reason, all `macro` macros are marked as exported, regardless of whether they actually are, which is dreadfully confusing. It would be more accurate to say that `exported_macros` currently contains only macros that have paths.

This PR renames `exported_macros` to `importable_macros`, since these macros can be imported with `use` while others cannot. It also fixes the code above to no longer lint on private `macro` macros, since the `missing_docs` lint should only appear on exported items.

Fixes #57569.
2021-07-10 03:32:42 +00:00
Cameron Steffen
d6b0d0bf97 Fix default_hash_types to use resolved path 2021-07-09 09:10:45 -05:00
inquisitivecrystal
b49936c0bf Improve handing of missing_docs for macros 2021-07-08 22:55:04 -07:00
inquisitivecrystal
2bcbb25cb5 Remove missing_docs lint on private 2.0 macros 2021-07-08 22:54:01 -07:00
Guillaume Gomez
d891c8cd54 Update to last upstream version 2021-07-08 17:14:28 +02:00
Yuki Okushi
c2d3f5f772
Rollup merge of #86639 - eholk:lint-tool, r=petrochenkov
Support lint tool names in rustc command line options

When rustc is running without a lint tool such as clippy enabled, options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs, such as `#![allow(clippy::foo)]`, but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue.

Note that we discovered this issue while discussing https://github.com/rust-lang/cargo/issues/5034.

Fixes #86628.
2021-07-08 10:44:29 +09:00
Eric Holk
4a83a93e9a Cleanup: unify lint name checking
This change merges `check_lint_and_tool_name` into `check_lint_name` in
order to avoid having two very similar functions.

Also adds the `.stderr` file back for the test case, since apparently
it is still needed.
2021-07-07 10:50:50 -07:00
Eric Holk
8b4f538320 Unify lint tool and lint name checking
This shares a little more code between checking command line and
attribute lint specifications.
2021-07-06 17:19:20 -07:00
Eric Holk
1e0db4cfed Parse tool name for command line lint options 2021-07-06 15:50:10 -07:00
Ryan Levick
a902e25f58 Add s to non_fmt_panic 2021-07-06 20:12:56 +02:00
Ryan Levick
1d49658f5c Change or_patterns_back_compat lint to rust_2021_incompatible_or_patterns 2021-07-06 20:11:45 +02:00
Ryan Levick
df71a99a0e Rename lint 2021-07-06 20:11:45 +02:00
bors
d5a406bb66 Auto merge of #82985 - cjgillot:lint, r=jackh726
Cleanup the computation of lint levels

This now uses an `IndexVec` and a special root `LintStackIndex = 0` to encode command-line levels.
2021-07-06 00:33:21 +00:00
Joshua Nelson
7a774a8537 Warn when rustdoc:: group is omitted from lint names 2021-07-03 15:32:09 -04:00
Yuki Okushi
086eb4764a
Add a help message to unused_doc_comments lint 2021-07-03 01:00:08 +09:00
Yuki Okushi
1823b3f2b3
Rollup merge of #85520 - FabianWolff:issue-85475, r=jackh726
Fix typo and improve documentation for E0632

Edit: After https://github.com/rust-lang/rust/pull/85520#issuecomment-870095546, this PR has been boiled down to just an extended description for `E0632` and a fixed typo.
2021-07-01 05:20:55 +09:00
Fabian Wolff
1deef26324 Improve wording of the drop_bounds lint 2021-06-30 16:43:02 +02:00
bors
51fd129ac1 Auto merge of #86689 - rylev:future-compat-lint-group, r=nikomatsakis
Only include lint in future_incompatible lint group if not an edition lint

A follow up to #86330 - this only includes lints annotated with `FutureIncompatibleInfo` in the `future_incompatibile` lint group if the future compatibility is not tied to an edition.

We probably want to rename `FutureIncompatibleInfo` to something else since this type is now used to indicate future breakages of all kinds (even those that happen in editions). I'd prefer to do that in a separate PR though.

r? `@nikomatsakis`
2021-06-30 05:02:01 +00:00
Camille GILLOT
5a731ffdae Encode CommandLine in the index only. 2021-06-29 20:05:11 +02:00
Camille GILLOT
66fee063b6 Use a newtype_index instead of a u32. 2021-06-29 19:44:03 +02:00
bors
8971fff984 Auto merge of #86009 - cjgillot:fwarn, r=davidtwco
Make ForceWarn a lint level.

Follow-up to #85788
cc `@rylev`
2021-06-29 13:11:16 +00:00
bors
fecc65a197 Auto merge of #86446 - Smittyvb:rustc_insignificant_dtor-ice, r=Mark-Simulacrum
Don't make `rustc_insignificant_dtor` feature gate

This isn't a feature gate, it's an attribute that is feature gated behind the `rustc_attrs` attribute. Closes #85680.
2021-06-29 02:48:08 +00:00
Yuki Okushi
14f333597e
Rollup merge of #86671 - m-ou-se:non-fmt-panic-future-incompatible, r=nikomatsakis
Turn non_fmt_panic into a future_incompatible edition lint.

This turns the `non_fmt_panic` lint into a future_incompatible edition lint, so it becomes part of the `rust_2021_compatibility` group. See https://github.com/rust-lang/rust/issues/85894.

This lint produces both warnings about semantical changes (e.g. `panic!("{{")`) and things that will become hard errors (e.g. `panic!("{")`). So I added a `explain_reason: false` that supresses the default "this will become a hard error" or "the semantics will change" message, and instead added a note depending on the situation. (cc `@rylev)`

r? `@nikomatsakis`
2021-06-29 08:46:14 +09:00
Fabian Wolff
4e08bb5225 Fix typo and improve documentation for E0632 2021-06-29 01:09:44 +02:00
Smitty
11ebd80fe7 Make incomplete features part of delcaration
This prevents mistakes where the feature is in the list of incomplete
features but not actually a feature by making the incompleteness a part
of the declaration.
2021-06-28 14:39:20 -04:00
Ryan Levick
f0d7280ff3 Add comment for future_incompatible lint group 2021-06-28 17:42:27 +02:00
Ryan Levick
0e28575909 Only include lint in future_incompatible lint group if not an edition lint 2021-06-28 16:40:46 +02:00
bors
e8cb1a4a56 Auto merge of #85359 - lrh2000:reserved-prefixes, r=nikomatsakis
Reserve prefixed identifiers and literals (RFC 3101)

This PR denies any identifiers immediately followed by one of three tokens `"`, `'` or `#`, which is stricter than the requirements of RFC 3101 but may be necessary according to the discussion at [Zulip].

[Zulip]: https://rust-lang.zulipchat.com/#narrow/stream/268952-edition-2021/topic/reserved.20prefixes/near/238470099

The tracking issue #84599 says we'll add a feature gate named `reserved_prefixes`, but I don't think I can do this because it is impossible for the lexer to know whether a feature is enabled or not. I guess determining the behavior by the edition information should be enough.

Fixes #84599
2021-06-27 20:33:25 +00:00
Mara Bos
934e6058eb Turn non_fmt_panic into a future_incompatible edition lint. 2021-06-27 14:47:26 +00:00
Mara Bos
d837c00d10 Add migration lint for reserved prefixes. 2021-06-26 23:11:04 +08:00
Mara Bos
ef152d9b9f Better suggestion for array_into_iter in for loop. 2021-06-26 12:14:22 +00:00
Mara Bos
5cfe2a5fc6 Add new suggestion to array_into_iter lint. 2021-06-26 12:03:33 +00:00
Mara Bos
37e17803b5 Change wording on array_into_iter lint for 1.53 and edition changes. 2021-06-26 12:03:33 +00:00
Camille GILLOT
e42271db0d Make ForceWarn a lint level. 2021-06-26 12:41:19 +02:00
Ryan Levick
7b3940f44b Address PR feedback 2021-06-25 14:51:56 +02:00
Ryan Levick
23176f60e7 Change how edition based future compatibility warnings are handled 2021-06-25 14:51:56 +02:00
hi-rustin
88abd7d81d Lint for unused borrows as part of UNUSED_MUST_USE 2021-06-18 15:09:40 +08:00
Ryan Levick
6936349233 Add support for using qualified paths with structs in expression and pattern
position.
2021-06-10 13:18:41 +02:00
Yuki Okushi
472dbec026
Rollup merge of #85906 - LingMan:iter_find, r=matthewjasper
Use `Iterator::find` instead of open-coding it

```@rustbot``` modify labels +C-cleanup +T-compiler
2021-06-08 13:26:28 +09:00
Guillaume Gomez
b71bc91192
Rollup merge of #85912 - LingMan:iter_any, r=nagisa
Use `Iterator::any` and `filter_map` instead of open-coding them

``@rustbot`` modify labels +C-cleanup +T-compiler
2021-06-07 01:06:50 +02:00
David Tolnay
abfad74ec6
Make *const (), *mut () okay for FFI 2021-06-04 22:19:43 -07:00
bors
2c106885d5 Auto merge of #85457 - jyn514:remove-doc-include, r=GuillaumeGomez
Remove `doc(include)`

This nightly feature is redundant now that `extended_key_value_attributes` is stable (https://github.com/rust-lang/rust/pull/83366). `@rust-lang/rustdoc` not sure if you think this needs FCP; there was already an FCP in #82539, but technically it was for deprecating, not removing the feature altogether.

This should not be merged before #83366.

cc `@petrochenkov`
2021-06-05 03:36:26 +00:00
Yuki Okushi
ec9e7d5df1
Rollup merge of #85853 - marmeladema:improper-ctypes-definitions-boxed-dst, r=petrochenkov
Warn against boxed DST in `improper_ctypes_definitions` lint

Fixes #85714
2021-06-05 06:13:38 +09:00
bors
595088d602 Auto merge of #85788 - rylev:force-warns, r=nikomatsakis
Support for force-warns

Implements https://github.com/rust-lang/rust/issues/85512.

This PR adds a new command line option `force-warns` which will force the provided lints to warn even if they are allowed by some other mechanism such as `#![allow(warnings)]`.

Some remaining issues:
* https://github.com/rust-lang/rust/issues/85512 mentions that `force-warns` should also be capable of taking lint groups instead of individual lints. This is not implemented.
* If a lint has a higher warning level than `warn`, this will cause that lint to warn instead. We probably want to allow the lint to error if it is set to a higher lint and is not allowed somewhere else.
* One test is currently ignored because it's not working - when a deny-by-default lint is allowed, it does not currently warn under `force-warns`. I'm not sure why, but I wanted to get this in before the weekend.

r? `@nikomatsakis`
2021-06-04 13:31:51 +00:00
Joshua Nelson
15fec1fb80 Remove doc(include) 2021-06-04 08:05:54 -04:00
Yuki Okushi
36f1ed6de2
Rollup merge of #85850 - bjorn3:less_feature_gates, r=jyn514
Remove unused feature gates

The first commit removes a usage of a feature gate, but I don't expect it to be controversial as the feature gate was only used to workaround a limitation of rust in the past. (closures never being `Clone`)

The second commit uses `#[allow_internal_unstable]` to avoid leaking the `trusted_step` feature gate usage from inside the index newtype macro. It didn't work for the `min_specialization` feature gate though.

The third commit removes (almost) all feature gates from the compiler that weren't used anyway.
2021-06-04 13:42:54 +09:00
marmeladema
877cfb1aad Warn against boxed DST in improper_ctypes_definitions lint 2021-06-03 23:21:43 +01:00
Yuki Okushi
ad7b56e1f4
Rollup merge of #85900 - LingMan:pat_mat, r=petrochenkov
Use pattern matching instead of checking lengths explicitly

This piece of code checks that there are exaclty two variants, one having
exactly one field, the other having exactly zero fields. If any of these
conditions is violated, it returns `None`. Otherwise it assigns that one
field's ty to `field_ty`.

Instead of fiddling with indices and length checks explicitly, use pattern
matching to simplify this.

`@rustbot` modify labels +C-cleanup +T-compiler
2021-06-03 14:35:38 +09:00
Camille GILLOT
0e71283495 Restrict access to crate_name.
Also remove original_crate_name, which had the exact same implementation
2021-06-02 18:35:32 +02:00
Ryan Levick
3b206b7a70 Force warn on lint groups as well 2021-06-02 17:09:07 +02:00
LingMan
e2b22b56b8 Use pattern matching instead of checking lengths explicitly
This piece of code checks that there are exaclty two variants, one having
exactly one field, the other having exactly zero fields. If any of these
conditions is violated, it returns `None`. Otherwise it assigns that one
field's ty to `field_ty`.

Instead of fiddling with indices and length checks explicitly, use pattern
matching to simplify this.
2021-06-01 22:31:46 +02:00
LingMan
0933fbd05a Use Iterator::any and filter_map instead of open-coding them 2021-06-01 21:07:07 +02:00
LingMan
86562b4fdb Use Iterator::find instead of open-coding it 2021-06-01 20:50:08 +02:00
Ryan Levick
4675690ac4 Fix issues and add test 2021-06-01 18:45:29 +02:00
Camille Gillot
0f0f3138cb
Revert "Reduce the amount of untracked state in TyCtxt" 2021-06-01 09:05:22 +02:00
bjorn3
312f964478 Remove unused feature gates 2021-05-31 13:55:43 +02:00
Camille GILLOT
10fb4b2fe5 Restrict access to crate_name.
Also remove original_crate_name, which had the exact same implementation
2021-05-30 19:54:04 +02:00
Ryan Levick
69a19bfd43 Initial support for force-warns 2021-05-28 18:19:59 +02:00
Smitty
edef5bc31b Lint against non-camelCase trait alias names
Type aliases are linted as such, so (unstable) trait aliases should be
treated the same way.
2021-05-26 19:55:27 -04:00
Pietro Albini
9e22b844dd remove cfg(bootstrap) 2021-05-24 11:07:48 -04:00
bors
3396a383bb Auto merge of #85178 - cjgillot:local-crate, r=oli-obk
Remove CrateNum parameter for queries that only work on local crate

The pervasive `CrateNum` parameter is a remnant of the multi-crate rustc idea.

Using `()` as query key in those cases avoids having to worry about the validity of the query key.
2021-05-17 01:42:03 +00:00
Eric Huss
5bbc240ffb Fix unused attributes on macro_rules. 2021-05-15 16:13:46 -07:00
Camille GILLOT
9849327384 Use () for privacy. 2021-05-12 13:58:45 +02:00
Camille GILLOT
9d15abe0cc Use () for lint_levels. 2021-05-12 13:58:43 +02:00
Aaron Hill
f916b0474a
Implement span quoting for proc-macros
This PR implements span quoting, allowing proc-macros to produce spans
pointing *into their own crate*. This is used by the unstable
`proc_macro::quote!` macro, allowing us to get error messages like this:

```
error[E0412]: cannot find type `MissingType` in this scope
  --> $DIR/auxiliary/span-from-proc-macro.rs:37:20
   |
LL | pub fn error_from_attribute(_args: TokenStream, _input: TokenStream) -> TokenStream {
   | ----------------------------------------------------------------------------------- in this expansion of procedural macro `#[error_from_attribute]`
...
LL |             field: MissingType
   |                    ^^^^^^^^^^^ not found in this scope
   |
  ::: $DIR/span-from-proc-macro.rs:8:1
   |
LL | #[error_from_attribute]
   | ----------------------- in this macro invocation
```

Here, `MissingType` occurs inside the implementation of the proc-macro
`#[error_from_attribute]`. Previosuly, this would always result in a
span pointing at `#[error_from_attribute]`

This will make many proc-macro-related error message much more useful -
when a proc-macro generates code containing an error, users will get an
error message pointing directly at that code (within the macro
definition), instead of always getting a span pointing at the macro
invocation site.

This is implemented as follows:
* When a proc-macro crate is being *compiled*, it causes the `quote!`
  macro to get run. This saves all of the sapns in the input to `quote!`
  into the metadata of *the proc-macro-crate* (which we are currently
  compiling). The `quote!` macro then expands to a call to
  `proc_macro::Span::recover_proc_macro_span(id)`, where `id` is an
opaque identifier for the span in the crate metadata.
* When the same proc-macro crate is *run* (e.g. it is loaded from disk
  and invoked by some consumer crate), the call to
`proc_macro::Span::recover_proc_macro_span` causes us to load the span
from the proc-macro crate's metadata. The proc-macro then produces a
`TokenStream` containing a `Span` pointing into the proc-macro crate
itself.

The recursive nature of 'quote!' can be difficult to understand at
first. The file `src/test/ui/proc-macro/quote-debug.stdout` shows
the output of the `quote!` macro, which should make this eaier to
understand.

This PR also supports custom quoting spans in custom quote macros (e.g.
the `quote` crate). All span quoting goes through the
`proc_macro::quote_span` method, which can be called by a custom quote
macro to perform span quoting. An example of this usage is provided in
`src/test/ui/proc-macro/auxiliary/custom-quote.rs`

Custom quoting currently has a few limitations:

In order to quote a span, we need to generate a call to
`proc_macro::Span::recover_proc_macro_span`. However, proc-macros
support renaming the `proc_macro` crate, so we can't simply hardcode
this path. Previously, the `quote_span` method used the path
`crate::Span` - however, this only works when it is called by the
builtin `quote!` macro in the same crate. To support being called from
arbitrary crates, we need access to the name of the `proc_macro` crate
to generate a path. This PR adds an additional argument to `quote_span`
to specify the name of the `proc_macro` crate. Howver, this feels kind
of hacky, and we may want to change this before stabilizing anything
quote-related.

Additionally, using `quote_span` currently requires enabling the
`proc_macro_internals` feature. The builtin `quote!` macro
has an `#[allow_internal_unstable]` attribute, but this won't work for
custom quote implementations. This will likely require some additional
tricks to apply `allow_internal_unstable` to the span of
`proc_macro::Span::recover_proc_macro_span`.
2021-05-12 00:51:31 -04:00
Dylan DPC
37c603864e
Rollup merge of #85075 - ptrojahn:panic_warning, r=jackh726
Improve "panic message is not a string literal" warning

This warning always referenced panic! even in case of an
assert. Related to #84656
2021-05-10 16:15:01 +02:00
Paul Trojahn
8f14592aa2 Improve "panic message is not a string literal" warning
This warning always referenced panic! even in case of an
assert. Related to #84656
2021-05-09 17:56:50 +02:00
Cameron Steffen
2e2bba94be Fix duplicate unknown lint errors 2021-05-07 17:26:32 -05:00
Cameron Steffen
25c66a13a9 Suggest lint groups 2021-05-05 13:11:52 -05:00
bors
7a0f1781d0 Auto merge of #83213 - rylev:update-lints-to-errors, r=nikomatsakis
Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021

This addresses https://github.com/rust-lang/rust/pull/81244 by updating two lints to errors in the Rust 2021 edition.

r? `@estebank`
2021-05-04 08:09:23 +00:00
Brent Kerby
6679f5ceb1 Change 'NULL' to 'null' 2021-05-02 17:46:00 -06:00
bors
ca075d268d Auto merge of #83386 - mark-i-m:stabilize-pat2015, r=nikomatsakis
Stabilize `:pat_param` and remove `:pat2021`

Blocked on #83384

cc `@rust-lang/lang` #79278

If I understand `@nikomatsakis` in  https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/or.20patterns/near/231133873, another FCP is not needed.

r? `@nikomatsakis`
2021-04-28 20:35:17 +00:00
klensy
f43ee8ebf6 fix few typos 2021-04-19 15:57:08 +03:00
bors
c4ba8e3e5f Auto merge of #83799 - crlf0710:stablize_non_ascii_idents, r=Manishearth
Stablize `non-ascii-idents`

This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467).

r? `@Manishearth`
2021-04-18 23:28:43 +00:00
bors
dc99219d3a Auto merge of #84064 - hyd-dev:unknown-lints, r=petrochenkov
Do not ignore path segments in the middle in `#[allow]`/`#[warn]`/`#[deny]`/`#[forbid]` attributes

Fixes #83477.
2021-04-18 02:12:13 +00:00
hyd-dev
ac044e35aa
Do not ignore path segments in the middle in #[allow]/#[warn]/#[deny]/#[forbid] attributes 2021-04-17 18:11:07 +08:00
mark
0566ccc72f rename pat2015 to pat_param 2021-04-15 13:52:09 -05:00
Aaron Hill
19c9d93ab5
Run buffered lints attached to anon consts
Fixes #84195
2021-04-15 11:11:44 -04:00
bors
7537b20626 Auto merge of #83948 - ABouttefeux:lint-nullprt-deref, r=RalfJung
add lint deref_nullptr detecting when a null ptr is dereferenced

fixes #83856
changelog: add lint that detect code like
```rust
unsafe {
      &*core::ptr::null::<i32>()
 };
unsafe {
     addr_of!(std::ptr::null::<i32>())
};
let x: i32 = unsafe {*core::ptr::null()};
let x: i32 = unsafe {*core::ptr::null_mut()};
unsafe {*(0 as *const i32)};
unsafe {*(core::ptr::null() as *const i32)};
```
```
warning: Dereferencing a null pointer causes undefined behavior
 --> src\main.rs:5:26
  |
5 |     let x: i32 = unsafe {*core::ptr::null()};
  |                          ^^^^^^^^^^^^^^^^^^
  |                          |
  |                          a null pointer is dereferenced
  |                          this code causes undefined behavior when executed
  |
  = note: `#[warn(deref_nullptr)]` on by default
```

Limitation:
It does not detect code like
```rust
const ZERO: usize = 0;
unsafe {*(ZERO as *const i32)};
```
or code where `0` is not directly a literal
2021-04-14 18:04:22 +00:00
Ryan Levick
aa4457fa5f Add compatibility info to lints 2021-04-13 16:55:54 +02:00
Manish Goregaokar
664c3e71b8 Turn old edition lints (anonymous-parameters, keyword-idents) into warn-by-default on 2015 2021-04-12 09:45:59 -07:00
Aliénore Bouttefeux
79666c8857 changes based on review 2021-04-09 16:13:04 +02:00
Dylan DPC
74b23f9d11
Rollup merge of #83980 - pierwill:fix-compiler-librustc-names, r=davidtwco
Fix outdated crate names in compiler docs

Changes `librustc_X` to `rustc_X`, only in documentation comments.
Plain code comments are left unchanged.
2021-04-08 20:29:58 +02:00
Dylan DPC
9aed9c1353
Rollup merge of #81764 - jyn514:lint-links, r=GuillaumeGomez
Stabilize `rustdoc::bare_urls` lint

Closes https://github.com/rust-lang/rust/issues/77501. Closes https://github.com/rust-lang/rust/issues/83598.
2021-04-08 20:29:56 +02:00
pierwill
0019ca9141 Fix outdated crate names in compiler docs
Changes `librustc_X` to `rustc_X`, only in documentation comments.
Plain code comments are left unchanged.

Also fix incorrect file paths.
2021-04-08 11:12:14 -05:00
Ryan Levick
d7b226398e Change how edition is determined 2021-04-08 15:36:29 +02:00
Ryan Levick
c2d0f1457a Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021 2021-04-08 15:36:27 +02:00
Aliénore Bouttefeux
0531ed0b62 fix lint doc 2021-04-08 12:09:32 +02:00
Aliénore Bouttefeux
3d215bdf42 change documentation of lint 2021-04-07 21:54:29 +02:00
Charles Lew
e5f9271f36 Stablize non_ascii_idents feature. 2021-04-08 02:52:00 +08:00
Aliénore Bouttefeux
c7bc41f97a add test 2021-04-07 19:23:17 +02:00
Aliénore Bouttefeux
389100921a add lint deref_nullptr 2021-04-06 22:01:00 +02:00
Joshua Nelson
d19083d9da Fix bug where rustc_lint would not apply renamed tool lints 2021-04-05 04:13:36 -04:00
Yuki Okushi
81f00c98a6 Trigger unused_doc_comments on macros at once 2021-04-04 05:06:51 +09:00
hi-rustin
2c66e15468 add OR_PATTERNS_BACK_COMPAT lint
test: add more cases

test: add comments

refine msg
2021-04-01 23:14:14 +08:00
Jack Huey
62a49c3bb8 Add tcx lifetime to Binder 2021-03-31 10:13:57 -04:00
Camille GILLOT
9d8f833e05 Remove hir::CrateItem. 2021-03-30 20:31:06 +02:00
Joshua Nelson
441dc3640a Remove (lots of) dead code
Found with https://github.com/est31/warnalyzer.

Dubious changes:
- Is anyone else using rustc_apfloat? I feel weird completely deleting
  x87 support.
- Maybe some of the dead code in rustc_data_structures, in case someone
  wants to use it in the future?
- Don't change rustc_serialize

  I plan to scrap most of the json module in the near future (see
  https://github.com/rust-lang/compiler-team/issues/418) and fixing the
  tests needed more work than I expected.

TODO: check if any of the comments on the deleted code should be kept.
2021-03-27 22:16:33 -04:00
Dylan DPC
b2e254318d
Rollup merge of #82917 - cuviper:iter-zip, r=m-ou-se
Add function core::iter::zip

This makes it a little easier to `zip` iterators:

```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```

You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:

```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```

It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:

```rust
    iter::zip(
        trait_ref.substs.types().skip(1),
        impl_trait_ref.substs.types().skip(1),
    )
    // vs.
    trait_ref
        .substs
        .types()
        .skip(1)
        .zip(impl_trait_ref.substs.types().skip(1))
```

This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].

[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html
2021-03-27 20:37:07 +01:00
Ralf Jung
fb4f48e032 make unaligned_refereces future-incompat lint warn-by-default, and remove the safe_packed_borrows lint that it replaces 2021-03-27 16:59:37 +01:00
Josh Stone
72ebebe474 Use iter::zip in compiler/ 2021-03-26 09:32:31 -07:00
mark
db5629adcb stabilize or_patterns 2021-03-19 19:45:32 -05:00
Dylan DPC
bcb9226efb
Rollup merge of #83216 - jyn514:register-tool, r=petrochenkov
Allow registering tool lints with `register_tool`

Previously, there was no way to add a custom tool prefix, even if the tool
itself had registered a lint:

 ```rust
 #![feature(register_tool)]
 #![register_tool(xyz)]
 #![warn(xyz::my_lint)]
 ```

```
$ rustc unknown-lint.rs  --crate-type lib
error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint`
 --> unknown-lint.rs:3:9
  |
3 | #![warn(xyz::my_lint)]
  |         ^^^
```

This allows opting-in to lints from other tools using `register_tool`.

cc https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, ``@chorman0773``
r? ``@petrochenkov``
2021-03-18 00:28:14 +01:00
bors
b4adc21c4f Auto merge of #83188 - petrochenkov:field, r=lcnr
ast/hir: Rename field-related structures

I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.

- `StructField` -> `FieldDef` ("field definition")
- `Field` -> `ExprField` ("expression field", not "field expression")
- `FieldPat` -> `PatField` ("pattern field", not "field pattern")

Various visiting and other methods working with the fields are renamed correspondingly too.

The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
2021-03-17 16:49:46 +00:00
Joshua Nelson
e3031fe22a Allow registering tool lints with register_tool
Previously, there was no way to add a custom tool prefix, even if the tool
itself had registered a lint:

 ```
 #![feature(register_tool)]
 #![register_tool(xyz)]
 #![warn(xyz::my_lint)]
 ```

```
$ rustc unknown-lint.rs  --crate-type lib
error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint`
 --> unknown-lint.rs:3:9
  |
3 | #![warn(xyz::my_lint)]
  |         ^^^
```

This allows opting-in to lints from other tools using `register_tool`.
2021-03-16 17:33:03 -04:00
Joshua Nelson
c1b99f0b90 Don't warn about old rustdoc lint names (temporarily)
Right now, rustdoc users have an unpleasant situation: they can either
use the new tool lint names (`rustdoc::non_autolinks`) or they can use
the old names (`non_autolinks`). If they use the tool lints, they get a
hard error on stable compilers, because rustc rejects all tool names it
doesn't recognize. If they use the old name, they get a warning to
rename the lint to the new name. The only way to compile without
warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the
whole point of the change: we *want* people to switch to the new name.

To avoid people silencing the lint and never migrating to the tool lint,
this avoids warning about the old name, while still allowing you to use
the new name. Once the new `rustdoc` tool name makes it to the stable
channel, we can change these lints to warn again.

This adds the new lint functions `register_alias` and `register_ignored`
- I didn't see an existing way to do this.
2021-03-16 13:13:59 -04:00
Vadim Petrochenkov
b25d3ba781 ast/hir: Rename field-related structures
StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")

Also rename visiting and other methods working on them.
2021-03-16 11:41:24 +03:00
Aaron Hill
f190bc4f47
Introduce proc_macro_back_compat lint, and emit for time-macros-impl
Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.

This PR introduces a new lint `proc_macro_back_compat`, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.

I've added code to fire this lint for the `time-macros-impl` case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to `time-macros`, so seeing a filename with
`time-macros-impl` guarantees that an older version of the parent `time`
crate is in use.

When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.
2021-03-14 21:31:46 -04:00
Yuki Okushi
33614023a1
Rollup merge of #82798 - jyn514:rustdoc-group, r=Manishearth,GuillaumeGomez
Rename `rustdoc` to `rustdoc::all`

When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like

```
warning: unknown lint: `rustdoc`
```

The lint group still worked when rustdoc ran, since rustdoc added the group itself.

This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints.

Follow-up to #80527.
r? ``@Manishearth``
2021-03-14 13:07:32 +09:00
Camille GILLOT
27ef0eeaa4 Track HirId when visiting attributes. 2021-03-09 19:27:59 +01:00
Camille GILLOT
c701872a6c Remove hir::Item::attrs. 2021-03-09 19:27:50 +01:00
Camille GILLOT
a987bbb97c Remove hir::Crate::attrs. 2021-03-09 19:22:55 +01:00
Camille GILLOT
c05c90275c Remove hir::MacroDef::attrs. 2021-03-09 19:09:36 +01:00
Camille GILLOT
4bb07bedf5 Visit attributes in one go. 2021-03-09 19:09:34 +01:00
Camille GILLOT
8e816056a5 Do not store attrs in FnKind. 2021-03-09 19:09:33 +01:00
Camille GILLOT
662f11ade6 Access attrs directly from HirId in rustc_lint::builtin. 2021-03-09 19:09:31 +01:00
Camille GILLOT
7e16e1e815 Access attrs directly from HirId in rustc_lint::levels. 2021-03-09 18:51:37 +01:00
Camille GILLOT
b84bdf1dae Access attrs directly from HirId in rustc_lint::late. 2021-03-09 18:51:37 +01:00
Mara Bos
0d97f9b22a
Rollup merge of #82048 - mark-i-m:or-pat-type-ascription, r=petrochenkov
or-patterns: disallow in `let` bindings

~~Blocked on https://github.com/rust-lang/rust/pull/81869~~

Disallows top-level or-patterns before type ascription. We want to reserve this syntactic space for possible future generalized type ascription.

r? ``@petrochenkov``
2021-03-09 09:05:20 +00:00
Mara Bos
6a55aa1246
Rollup merge of #82854 - estebank:issue-82827, r=oli-obk
Account for `if (let pat = expr) {}`

Fix #82827.
2021-03-08 20:09:02 +01:00
Esteban Küber
e62a543344 Account for if (let pat = expr) {}
Partially address #82827.
2021-03-07 13:49:36 -08:00
Yuki Okushi
6e4dcea0d9 Handle negative literals in cast overflow warning 2021-03-06 17:33:21 +09:00
Joshua Nelson
45229b0777 Rename rustdoc to rustdoc::all
When rustdoc lints were changed to be tool lints, the `rustdoc` group
was removed, leading to spurious warnings like

```
warning: unknown lint: `rustdoc`
```

The lint group still worked when rustdoc ran, since rustdoc added the group itself.

This renames the group to `rustdoc::all` for consistency with
`clippy::all` and the rest of the rustdoc lints.
2021-03-05 15:26:55 -05:00
mark
e64138c534 use pat<no_top_alt> for patterns in let bindings 2021-03-05 10:10:04 -06:00
Mara
e6a6df5daa
Rollup merge of #80723 - rylev:noop-lint-pass, r=estebank
Implement NOOP_METHOD_CALL lint

Implements the beginnings of https://github.com/rust-lang/lang-team/issues/67 - a lint for detecting noop method calls (e.g, calling `<&T as Clone>::clone()` when `T: !Clone`).

This PR does not fully realize the vision and has a few limitations that need to be addressed either before merging or in subsequent PRs:
* [ ] No UFCS support
* [ ] The warning message is pretty plain
* [ ] Doesn't work for `ToOwned`

The implementation uses [`Instance::resolve`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/instance/struct.Instance.html#method.resolve) which is normally later in the compiler. It seems that there are some invariants that this function relies on that we try our best to respect. For instance, it expects substitutions to have happened, which haven't yet performed, but we check first for `needs_subst` to ensure we're dealing with a monomorphic type.

Thank you to ```@davidtwco,``` ```@Aaron1011,``` and ```@wesleywiser``` for helping me at various points through out this PR ❤️.
2021-03-05 10:57:14 +01:00
Ryan Levick
25637b228d Warn in doc test 2021-03-03 11:23:33 +01:00
Ryan Levick
1999a3147f Fix borrow and deref 2021-03-03 11:23:29 +01:00
Ryan Levick
da3995f0ec Remove lint pass on borrow and deref 2021-03-03 11:23:14 +01:00
Esteban Küber
055db16479 Clean up code rightward drift 2021-03-03 11:22:57 +01:00