Commit Graph

673 Commits

Author SHA1 Message Date
Michael Howell
6b7fcf720a fix(rustc_lint): better detect when parens are necessary
Fixes #90807
2021-12-15 00:00:17 -07:00
Nicholas Nethercote
056d48a2c9 Remove unnecessary sigils around Symbol::as_str() calls. 2021-12-15 17:32:14 +11:00
Nicholas Nethercote
8cddcd39ba Remove SymbolStr.
By changing `as_str()` to take `&self` instead of `self`, we can just
return `&str`. We're still lying about lifetimes, but it's a smaller lie
than before, where `SymbolStr` contained a (fake) `&'static str`!
2021-12-15 13:30:26 +11:00
Matthias Krüger
4e7497bda0
Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip, r=scottmcm
Stabilize `iter::zip`

Hello all!

As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised, I hereby submit this stabilization PR on the issue.

As the pull request that introduced the feature (#82917) states, the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement, it has been integrated into the codebase without any trouble, and has been
used in many places across the rust compiler and standard library since March without any issues.

For more details, I would refer to `@cuviper's` original PR, or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).
2021-12-15 01:28:08 +01:00
Matthias Krüger
272188eecd
Rollup merge of #90939 - estebank:wg-af-polish, r=tmandry
Tweak errors coming from `for`-loop, `?` and `.await` desugaring

 * Suggest removal of `.await` on non-`Future` expression
 * Keep track of obligations introduced by desugaring
 * Remove span pointing at method for obligation errors coming from desugaring
 * Point at called local sync `fn` and suggest making it `async`

```
error[E0277]: `()` is not a future
  --> $DIR/unnecessary-await.rs:9:10
   |
LL |     boo().await;
   |     -----^^^^^^ `()` is not a future
   |     |
   |     this call returns `()`
   |
   = help: the trait `Future` is not implemented for `()`
help: do not `.await` the expression
   |
LL -     boo().await;
LL +     boo();
   |
help: alternatively, consider making `fn boo` asynchronous
   |
LL | async fn boo () {}
   | +++++
```

Fix #66731.
2021-12-15 01:28:04 +01:00
PFPoitras
304ede6bcc Stabilize iter::zip. 2021-12-14 18:50:31 -04:00
Esteban Kuber
f640438b40 Keep info on pre-desugaring expression for better "incorrect .await" suggestion
Keep the `HirId` of `.await`ed expressions so in the case of a `fn` call
on on a sync `fn`, we can suggest maybe turning it into an `async fn`.
2021-12-13 17:09:16 +00:00
Amanieu d'Antras
1c48025685 Address review feedback 2021-12-12 11:26:59 +00:00
Amanieu d'Antras
44a3a66ee8 Stabilize asm! and global_asm!
They are also removed from the prelude as per the decision in
https://github.com/rust-lang/rust/issues/87228.

stdarch and compiler-builtins are updated to work with the new, stable
asm! and global_asm! macros.
2021-12-12 11:20:03 +00:00
Noah Lev
f53e489e6e Show the unused type for unused_results lint
I think it's helpful to know what type was unused when looking at these
warnings. The type will likely determine whether the result *should* be
used, or whether it should just be ignored.

Including the type also matches the behavior of the `must_use` lint:
unused `SomeType` that must be used.
2021-12-11 17:58:11 -08:00
Camille GILLOT
d9e997d9eb Remove useless variant. 2021-12-11 11:08:46 +01:00
est31
15de4cbc4b Remove redundant [..]s 2021-12-09 00:01:29 +01:00
Camille GILLOT
646f58a7e1 Lint bare traits in AstConv. 2021-12-04 23:13:58 +01:00
est31
bdc4b46221 Use let_else in some more places in rustc_lint 2021-12-03 03:51:47 +01:00
Matthias Krüger
d96ce3ea8e
Rollup merge of #91394 - Mark-Simulacrum:bump-stage0, r=pietroalbini
Bump stage0 compiler

r? `@pietroalbini` (or anyone else)
2021-12-02 15:52:03 +01:00
bors
f04a2f4b8e Auto merge of #91255 - b-naber:normalization-ice, r=jackh276
Implement version of normalize_erasing_regions that allows for normalization failure

Fixes https://github.com/rust-lang/rust/issues/59324
Fixes https://github.com/rust-lang/rust/issues/67684
Fixes https://github.com/rust-lang/rust/issues/69398
Fixes https://github.com/rust-lang/rust/issues/71113
Fixes https://github.com/rust-lang/rust/issues/82079
Fixes #85103
Fixes https://github.com/rust-lang/rust/issues/88856
Fixes #91231
Fixes https://github.com/rust-lang/rust/issues/91234

Previously we called `normalize_erasing_regions` inside `layout_of`. `normalize_erasing_regions` assumes that the normalization succeeds. Since some `layout_of` calls happen before typecheck has finished, we introduce a new variant that allows for returning an error.
2021-12-01 13:33:33 +00:00
b-naber
ff448cfcee implement version of normalize_erasing_regions that doesn't assume value is normalizable 2021-12-01 12:12:38 +01:00
Matthias Krüger
a4f46742c2
Rollup merge of #90985 - camsteffen:diag-name-usage, r=jackh726
Use `get_diagnostic_name` more
2021-12-01 10:50:18 +01:00
Joshua Nelson
bd894a0877 Emit a warning on generic parameters with doc comments 2021-11-30 18:49:55 +00:00
Mark Rousskov
b221c877e8 Apply cfg-bootstrap switch 2021-11-30 10:51:42 -05:00
Camille GILLOT
5fb4648757 Take a LocalDefId in expect_*item. 2021-11-28 21:09:45 +01:00
Cameron Steffen
dec40530f7 Use get_diagnostic_name more 2021-11-16 17:14:18 -06:00
Josh Triplett
8c9bfaa5f3 Stabilize format_args_capture
Works as expected, and there are widespread reports of success with it,
as well as interest in it.
2021-11-15 10:14:29 +01:00
Vadim Petrochenkov
6655727041 rustc_feature: Convert BuiltinAttribute from tuple to a struct 2021-11-12 20:15:14 +08:00
bors
46b8e7488e Auto merge of #90668 - matthiaskrgr:clippy_nov7, r=jyn514
more clippy fixes
2021-11-07 20:04:54 +00:00
Matthias Krüger
5c454551da more clippy fixes 2021-11-07 16:59:05 +01:00
Vadim Petrochenkov
2834f57c45 ast: Fix naming conventions in AST structures
TraitKind -> Trait
TyAliasKind -> TyAlias
ImplKind -> Impl
FnKind -> Fn

All `*Kind`s in AST are supposed to be enums.

Tuple structs are converted to braced structs for the types above, and fields are reordered in syntactic order.

Also, mutable AST visitor now correctly visit spans in defaultness, unsafety, impl polarity and constness.
2021-11-07 21:38:17 +08:00
pierwill
521b1ee974 Improve terminology around "after typeck" 2021-11-06 20:59:38 -05:00
Hans Kratz
7885233df0 Optimize literal, doc comment lint as well, extract function. 2021-11-04 23:31:42 +01:00
bors
e9b0d99259 Auto merge of #90463 - matthiaskrgr:rollup-eljk9vo, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #89826 (Feature gate + make must_not_suspend allow-by-default)
 - #89929 (Handling submodule update failures more gracefully from x.py)
 - #90333 (rustdoc: remove flicker during page load)
 - #90349 (Fix rare ICE during typeck in rustdoc scrape_examples)
 - #90398 (Document `doc(keyword)` unstable attribute)
 - #90441 (Test that promotion follows references when looking for drop)
 - #90450 (Remove `rustc_hir::hir_id::HirIdVec`)
 - #90452 (Remove unnecessary `Option` from `promote_candidate` return type)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-11-01 14:00:08 +00:00
Gus Wynn
185fa56256 Feature gate and make must_not_suspend allow-by-default
This lint is not yet ready for stable use, primarily due to false positives in edge
cases; we want to test it out more before stabilizing.
2021-10-31 21:22:17 -04:00
Esteban Küber
c0b134582a
Lint against RTL unicode codepoints in literals and comments
Address CVE-2021-42574.
2021-10-31 13:14:04 +01:00
Mark Rousskov
3215eeb99f
Revert "Add rustc lint, warning when iterating over hashmaps" 2021-10-28 11:01:42 -04:00
Matthias Krüger
87822b27ee
Rollup merge of #89558 - lcnr:query-stable-lint, r=estebank
Add rustc lint, warning when iterating over hashmaps

r? rust-lang/wg-incr-comp
2021-10-24 15:48:42 +02:00
Yuki Okushi
91fb223f59
Rollup merge of #89895 - camsteffen:for-loop-head-span, r=davidtwco
Don't mark for loop iter expression as desugared

We typically don't mark spans of lowered things as desugared. This helps Clippy rightly discern when code is (not) from expansion. This was discovered by ``@flip1995`` at https://github.com/rust-lang/rust-clippy/pull/7789#issuecomment-939289501.
2021-10-22 19:42:45 +09:00
lcnr
22e1798975 ignore potential_query_instability in rustdoc 2021-10-21 21:14:34 +02:00
Matthias Krüger
cd72393566
Rollup merge of #89987 - pierwill:fix-85526-docs-hidden-assoc, r=GuillaumeGomez
Check implementing type for `#[doc(hidden)]`

Closes #85526.
2021-10-18 08:13:28 +02:00
pierwill
d39a1bec81 Check implementing type for #[doc(hidden)]
Closes #85526.
2021-10-17 16:37:44 -05:00
r00ster91
3c1d55422a Some "parenthesis" and "parentheses" fixes 2021-10-17 12:04:01 +02:00
Cameron Steffen
bd1a1e4f0d Don't mark for loop head span with desugaring 2021-10-15 08:04:50 -05:00
lcnr
00e5abe9b6 allow potential_query_instability everywhere 2021-10-15 10:58:18 +02:00
lcnr
80fe0bb76e add a rustc::query_stability lint 2021-10-15 10:58:18 +02:00
Flying-Toast
59b186d99a
Add enum_intrinsics_non_enums lint 2021-10-11 09:46:27 +02:00
Guillaume Gomez
cda07c740c
Rollup merge of #89672 - klensy:unwrap-or-macro, r=jackh726
Remove unwrap_or! macro

Removes `unwrap_or!` macro and replaces it with `match`.

It's kinda cleanup, as rustc_ast not the best place for this macro and this is used only in 2 places anyway.
2021-10-08 22:30:43 +02:00
Matthias Krüger
e6f77a1787 clippy::complexity fixes 2021-10-08 20:07:44 +02:00
klensy
77fce75ba1 remove unwrap_or! macro 2021-10-08 19:32:16 +03:00
Cameron Steffen
b6cab80c18 Use get_diagnostic_name 2021-10-06 13:10:08 -05:00
Jubilee
c2bfe45e66
Rollup merge of #89473 - FabianWolff:issue-89469, r=joshtriplett
Fix extra `non_snake_case` warning for shorthand field bindings

Fixes #89469. The problem is the innermost `if` condition here:
d14731cb3c/compiler/rustc_lint/src/nonstandard_style.rs (L435-L452)

This code runs for every `PatKind::Binding`, so if a struct has multiple fields, say A and B, and both are bound in a pattern using shorthands, the call to `self.check_snake_case()` will indeed be skipped in the `check_pat()` call for `A`; but when `check_pat()` is called for `B`, the loop will still iterate over `A`, and `field.ident (= A) != ident (= B)` will be true. I have fixed this by only looking at non-shorthand bindings, and only the binding that `check_pat()` was actually called for.
2021-10-04 21:12:38 -07:00
Jubilee
5352e17df3
Rollup merge of #89483 - hkmatsumoto:patch-diagnostics-2, r=estebank
Practice diagnostic message convention

Detected by #89455.

r? ```@estebank```
2021-10-04 13:58:15 -07:00
Manish Goregaokar
5215b855b0
Rollup merge of #88481 - bjorn3:remove_feature_gates, r=cjgillot
Remove some feature gates

The first commit removes various feature gates that are unused. The second commit replaces some `Fn` implementations with `Iterator` implementations, which is much cleaner IMO. The third commit replaces an unboxed_closures feature gate with min_specialization. For some reason the unboxed_closures feature gate suppresses the min_specialization feature gate from triggering on an `TrustedStep` impl. The last comment just turns a regular comment into a doc comment as drive by cleanup. I can move it to a separate PR if preferred.
2021-10-03 23:13:20 -07:00
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