Commit Graph

673 Commits

Author SHA1 Message Date
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
Esteban Küber
e48670c34a Increase accuracy of lint trigger 2021-03-03 11:22:56 +01:00
Ryan Levick
49f32e0c8e Improve error messages 2021-03-03 11:22:55 +01:00
Ryan Levick
95e330bd01 Update error message 2021-03-03 11:22:54 +01:00
Ryan Levick
217c88655b Improve warning 2021-03-03 11:22:52 +01:00
Ryan Levick
a6d926d80d Fix tests 2021-03-03 11:22:44 +01:00
Ryan Levick
f49ed7a6b7 Add tests and support two more noop methods 2021-03-03 11:22:17 +01:00
Ryan Levick
040735c110 First version of noop-lint 2021-03-03 11:22:16 +01:00
Joshua Nelson
c7535d1361 Update comments
Note that the FIXME was removed because this can't be fixed,
`register_renamed` calls LintId::of and there's no LintId for rustdoc
lints when rustc is running.
2021-03-01 19:29:15 -05:00
Joshua Nelson
0517ea7cdc Address review comments
- Move MISSING_CRATE_LEVEL_DOCS to rustdoc directly
- Update documentation

This also takes the opportunity to make the `no-crate-level-doc-lint`
test more specific.
2021-03-01 19:29:15 -05:00
Joshua Nelson
e8ddfda813 Improve error messages
- Use `register_renamed` when rustdoc is running so the lint will still
  be active and use a structured suggestion
- Test the behavior for rustc, not just for rustdoc (because it differs)
2021-03-01 19:29:15 -05:00
Joshua Nelson
cc62018e61 Rename rustdoc lints to be a tool lint instead of built-in.
- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links`
- Ensure that the old lint names still work and give deprecation errors
- Register lints even when running doctests

  Otherwise, all `rustdoc::` lints would be ignored.

- Register all existing lints as removed

  This unfortunately doesn't work with `register_renamed` because tool
  lints have not yet been registered when rustc is running. For similar
  reasons, `check_backwards_compat` doesn't work either. Call
  `register_removed` directly instead.

- Fix fallout

  + Rustdoc lints for compiler/
  + Rustdoc lints for library/

Note that this does *not* suggest `rustdoc::broken_intra_doc_links` for
`rustdoc::intra_doc_link_resolution_failure`, since there was no time
when the latter was valid.
2021-03-01 19:29:15 -05:00
Joshua Nelson
68088026ed
Rollup merge of #82620 - jyn514:apply-renamed-lints, r=Manishearth
Apply lint restrictions from renamed lints

Previously, if you denied the old name of a renamed lint, it would warn
about using the new name, but otherwise do nothing. Now, it will behave
the same as if you'd used the new name.

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

r? `@ehuss`
2021-03-01 11:25:08 -05:00
Joshua Nelson
df156c1958 Apply lint restrictions from renamed lints
Previously, if you denied the old name of a renamed lint, it would warn
about using the new name, but otherwise do nothing. Now, it will behave
the same as if you'd used the new name.
2021-02-28 01:04:34 -05:00
Aaron Hill
fb5fec017b
Combine HasAttrs and HasTokens into AstLike
When token-based attribute handling is implemeneted in #80689,
we will need to access tokens from `HasAttrs` (to perform
cfg-stripping), and we will to access attributes from `HasTokens` (to
construct a `PreexpTokenStream`).

This PR merges the `HasAttrs` and `HasTokens` traits into a new
`AstLike` trait. The previous `HasAttrs` impls from `Vec<Attribute>` and `AttrVec`
are removed - they aren't attribute targets, so the impls never really
made sense.
2021-02-27 00:14:13 -05:00
Guillaume Gomez
039b1b62ac
Rollup merge of #82456 - klensy:or-else, r=estebank
Replaced some unwrap_or and map_or with lazy variants

Replaced some `unwrap_or` and `map_or` with `unwrap_or_else` and `map_or_else`.
2021-02-26 15:52:31 +01:00
klensy
5ff1be197e replaced some unwrap_or with unwrap_or_else 2021-02-23 23:56:04 +03:00
Dylan DPC
547b3adfe4
Rollup merge of #82113 - m-ou-se:panic-format-lint, r=estebank
Improve non_fmt_panic lint.

This change:
- fixes the span used by this lint in the case the panic argument is a single macro expansion (e.g. `panic!(a!())`);
- adds a suggestion for `panic!(format!(..))` to remove `format!()` instead of adding `"{}", ` or using `panic_any` like it does now; and
- fixes the incorrect suggestion to replace `panic![123]` by `panic_any(123]`.

Fixes #82109.
Fixes #82110.
Fixes #82111.

Example output:
```
warning: panic message is not a string literal
 --> src/main.rs:8:12
  |
8 |     panic!(format!("error: {}", "oh no"));
  |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(non_fmt_panic)]` on by default
  = note: this is no longer accepted in Rust 2021
  = note: the panic!() macro supports formatting, so there's no need for the format!() macro here
help: remove the `format!(..)` macro call
  |
8 |     panic!("error: {}", "oh no");
  |           --                  --

```

r? `@estebank`
2021-02-23 16:10:21 +01:00
Vadim Petrochenkov
eb65f15c78 ast: Stop using Mod in Crate
Crate root is sufficiently different from `mod` items, at least at syntactic level.

Also remove customization point for "`mod` item or crate root" from AST visitors.
2021-02-18 13:07:49 +03:00
Guillaume Gomez
ec007845cf
Rollup merge of #79981 - camelid:overflowing_literals-inference-error, r=lcnr
Add 'consider using' message to overflowing_literals

Fixes #79744.

Ironically, the `overflowing_literals` handler for binary or hex already
had this message! You would think it would be the other way around :)

cc ```@scottmcm```
2021-02-17 20:37:48 +01:00
Mara Bos
ad93f48d77 Add comment about how we find the right span in non_fmt_panic. 2021-02-17 10:51:22 +01:00
Camille GILLOT
c4e7427081 Only store a LocalDefId in hir::MacroDef. 2021-02-15 19:35:55 +01:00
Camille GILLOT
ff14cac621 Index Modules using their LocalDefId. 2021-02-15 19:32:30 +01:00
Camille GILLOT
996dc8d5c5 Only store a LocalDefId in hir::ForeignItem. 2021-02-15 19:32:29 +01:00
Camille GILLOT
786a80e9ea Only store a LocalDefId in hir::ImplItem. 2021-02-15 19:32:29 +01:00
Camille GILLOT
a871a0f111 Only store a LocalDefId in hir::TraitItem. 2021-02-15 19:32:28 +01:00
Camille GILLOT
cebbba081e Only store a LocalDefId in hir::Item.
Items are guaranteed to be HIR owner.
2021-02-15 19:32:10 +01:00
Camille GILLOT
c676e358a5 Use ItemId as a strongly typed index. 2021-02-15 19:24:58 +01:00
Mara Bos
2a0c42450e Formatting. 2021-02-14 19:51:15 +01:00
Mara Bos
37c532c010 Suggest correct replacement for panic![123].
Before this change, the suggestion was `std::panic::panic_any(123]`,
changing the opening brace but not the closing one.
2021-02-14 19:44:48 +01:00
Mara Bos
a428ab17ab Improve suggestion for panic!(format!(..)). 2021-02-14 18:52:47 +01:00
Mara Bos
ef778e7965 Fix span in non_fmt_panic for panic!(some_macro!()). 2021-02-14 18:14:23 +01:00
Camelid
a9b16c6d71 Improve error and help messages 2021-02-13 21:42:32 -08:00
bors
07194ffcd2 Auto merge of #79804 - tmiasko:improper-ctypes-no-niche, r=pnkfelix
Types with a hidden niche are not known to be non-null

Fixes #79787.
2021-02-10 12:56:09 +00:00
Yuki Okushi
a58feb9282
Rollup merge of #81913 - osa1:rename_unop_variants, r=matthewjasper
Rename HIR UnOp variants

This renames the variants in HIR UnOp from

    enum UnOp {
        UnDeref,
        UnNot,
        UnNeg,
    }

to

    enum UnOp {
        Deref,
        Not,
        Neg,
    }

Motivations:

- This is more consistent with the rest of the code base where most enum
  variants don't have a prefix.

- These variants are never used without the `UnOp` prefix so the extra
  `Un` prefix doesn't help with readability. E.g. we don't have any
  `UnDeref`s in the code, we only have `UnOp::UnDeref`.

- MIR `UnOp` type variants don't have a prefix so this is more
  consistent with MIR types.

- "un" prefix reads like "inverse" or "reverse", so as a beginner in
  rustc code base when I see "UnDeref" what comes to my mind is
  something like `&*` instead of just `*`.
2021-02-10 12:24:28 +09:00
Ömer Sinan Ağacan
c4e3558b8c Rename HIR UnOp variants
This renames the variants in HIR UnOp from

    enum UnOp {
        UnDeref,
        UnNot,
        UnNeg,
    }

to

    enum UnOp {
        Deref,
        Not,
        Neg,
    }

Motivations:

- This is more consistent with the rest of the code base where most enum
  variants don't have a prefix.

- These variants are never used without the `UnOp` prefix so the extra
  `Un` prefix doesn't help with readability. E.g. we don't have any
  `UnDeref`s in the code, we only have `UnOp::UnDeref`.

- MIR `UnOp` type variants don't have a prefix so this is more
  consistent with MIR types.

- "un" prefix reads like "inverse" or "reverse", so as a beginner in
  rustc code base when I see "UnDeref" what comes to my mind is
  something like "&*" instead of just "*".
2021-02-09 11:39:20 +03:00
Dylan DPC
f8b330d9fb
Rollup merge of #72209 - Nemo157:lint-no-mangle-in-unsafe-code, r=nikomatsakis
Add checking for no_mangle to unsafe_code lint

fixes #72188

r? `@estebank`
2021-02-09 02:39:45 +01:00
Jeremy Fitzhardinge
82ccb6582a Add --extern-loc to augment unused crate dependency diagnostics
This allows a build system to indicate a location in its own dependency
specification files (eg Cargo's `Cargo.toml`) which can be reported
along side any unused crate dependency.

This supports several types of location:
 - 'json' - provide some json-structured data, which is included in the json diagnostics
     in a `tool_metadata` field
 - 'raw' - emit the provided string into the output. This also appears as a json string in
     `tool_metadata`.

If no `--extern-location` is explicitly provided then a default json entry of the form
`"tool_metadata":{"name":<cratename>,"path":<cratepath>}` is emitted.
2021-02-07 14:54:20 -08:00
Vadim Petrochenkov
dbdbd30bf2 expand/resolve: Turn #[derive] into a regular macro attribute 2021-02-07 20:08:45 +03:00
Mara Bos
87b269ab66
Rollup merge of #81645 - m-ou-se:panic-lint, r=estebank,flip1995
Add lint for `panic!(123)` which is not accepted in Rust 2021.

This extends the `panic_fmt` lint to warn for all cases where the first argument cannot be interpreted as a format string, as will happen in Rust 2021.

It suggests to add `"{}",` to format the message as a string. In the case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.

It renames the lint to `non_fmt_panic` to match the lint naming guidelines.

![image](https://user-images.githubusercontent.com/783247/106520928-675ea680-64d5-11eb-81f7-d8fa48b93a0b.png)

This is part of #80162.

r? ```@estebank```
2021-02-04 21:10:36 +01:00
Mara Bos
c5990dd8ad
Rollup merge of #81556 - nikomatsakis:forbidden-lint-groups-lint, r=pnkfelix
introduce future-compatibility warning for forbidden lint groups

We used to ignore `forbid(group)` scenarios completely. This changed in #78864, but that led to a number of regressions (#80988, #81218).

This PR introduces a future compatibility warning for the case where a group is forbidden but then an individual lint within that group is allowed. We now issue a FCW when we see the "allow", but permit it to take effect.

r? ``@Mark-Simulacrum``
2021-02-04 21:10:34 +01:00
Mara Bos
a616f8267e Add lint for panic!(123) which is not accepted in Rust 2021.
This extends the `panic_fmt` lint to warn for all cases where the first
argument cannot be interpreted as a format string, as will happen in
Rust 2021.

It suggests to add `"{}", ` to format the message as a string. In the
case of `std::panic!()`, it also suggests the recently stabilized
`std::panic::panic_any()` function as an alternative.

It renames the lint to `non_fmt_panic` to match the lint naming
guidelines.
2021-02-03 22:42:53 +01:00
Jethro Beekman
37cb9d30fa Really fix early lints inside an async desugaring 2021-02-03 10:05:58 +01:00
Niko Matsakis
b6b897b02c introduce future-compatibility warning for forbidden lint groups
We used to ignore `forbid(group)` scenarios completely. This changed
in #78864, but that led to a number of regressions (#80988, #81218).

This PR introduces a future compatibility warning for the case where
a group is forbidden but then an individual lint within that group
is allowed. We now issue a FCW when we see the "allow", but permit
it to take effect.
2021-02-02 18:21:37 -05:00
bors
368275062f Auto merge of #81541 - Aaron1011:early-lint-async-fn, r=petrochenkov
Fix early lints inside an async desugaring

Fixes #81531

When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the NodeId of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that NodeId does not actually exist in the AST.

This commit uses the parent of a desugared closure when computing
`lint_node_id`, which is something that actually exists in the AST (an
`async fn` or async closure).
2021-02-02 20:27:09 +00:00
Aaron Hill
a74b2fb946
Fix early lints inside an async desugaring
Fixes #81531

When we buffer an early lint for a macro invocation,
we need to determine which NodeId to take the lint level from.
Currently, we use the `NodeId` of the closest def parent. However, if
the macro invocation is inside the desugared closure from an `async fn`
or async closure, that `NodeId` does not actually exist in the AST.

This commit explicitly calls `check_lint` for the `NodeId`s of closures
desugared from async expressions, ensuring that we do not miss any
buffered lints.
2021-02-02 13:57:46 -05:00
bors
3182375e06 Auto merge of #81405 - bugadani:ast, r=cjgillot
Box the biggest ast::ItemKind variants

This PR is a different approach on https://github.com/rust-lang/rust/pull/81400, aiming to save memory in humongous ASTs.

The three affected item kind enums are:
 - `ast::ItemKind` (208 -> 112 bytes)
 - `ast::AssocItemKind` (176 -> 72 bytes)
 - `ast::ForeignItemKind` (176 -> 72 bytes)
2021-02-02 17:34:08 +00:00
Jonas Schievink
39ea34744b
Rollup merge of #81529 - estebank:case_lints, r=davidtwco
Fix invalid camel case suggestion involving unicode idents

Follow up to #77805.
2021-02-01 14:29:39 +01:00
bors
e0d9f79399 Auto merge of #80851 - m-ou-se:panic-2021, r=petrochenkov
Implement Rust 2021 panic

This implements the Rust 2021 versions of `panic!()`. See https://github.com/rust-lang/rust/issues/80162 and https://github.com/rust-lang/rfcs/pull/3007.

It does so by replacing `{std, core}::panic!()` by a bulitin macro that expands to either `$crate::panic::panic_2015!(..)` or `$crate::panic::panic_2021!(..)` depending on the edition of the caller.

This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: c5273bdfb2 That change is blocked on figuring out what to do with https://github.com/rust-lang/rust/issues/80846 first.
2021-02-01 10:25:31 +00:00
Dániel Buga
b87e1ecdf0 Box the biggest ast::ItemKind variants 2021-02-01 09:23:39 +01:00
Jonas Schievink
024848d013
Rollup merge of #81568 - osa1:remove_old_fixme, r=jonas-schievink
Fix an old FIXME in redundant paren lint

Referenced bug was fixed a while ago
2021-01-31 16:36:51 +01:00
Esteban Küber
fa9a99fefc review comments 2021-01-30 22:06:10 -08:00
Ömer Sinan Ağacan
8b5187f7ea Fix an old FIXME in redundant paren lint
Referenced bug was fixed a while ago
2021-01-30 22:39:56 +03:00
bors
fd20a8be0d Auto merge of #81453 - jumbatm:clashing-extern-decl-perf, r=nagisa
clashing_extern_declarations: Use symbol interning to avoid string alloc.

Use symbol interning as a hack to avoid allocating a string for every symbol name we store in the seen set. This hopefully addresses the minor perf regression described in https://github.com/rust-lang/rust/pull/80009#issuecomment-763526902.

r? `@nagisa`
2021-01-30 16:41:05 +00:00
Esteban Küber
d10ee0d07e Fix invalid camel case suggestion involving unicode idents
Follow up to #77805.
2021-01-29 11:07:14 -08:00
Yuki Okushi
0c5fccea22
Rollup merge of #81176 - camsteffen:qpath-res, r=oli-obk
Improve safety of `LateContext::qpath_res`

This is my first rustc code change, inspired by hacking on clippy!

The first change is to clear cached `TypeckResults` from `LateContext` when visiting a nested item. I took a hint from [here](5e91c4ecc0/compiler/rustc_privacy/src/lib.rs (L1300)).

Clippy has a `qpath_res` util function to avoid a possible ICE in `LateContext::qpath_res`. But the docs of `LateContext::qpath_res` promise no ICE. So this updates the `LateContext` method to keep its promises, and removes the util function.

Related: rust-lang/rust-clippy#4545

CC ````````````@eddyb```````````` since you've done related work
CC ````````````@flip1995```````````` FYI
2021-01-29 09:17:32 +09:00
Yuki Okushi
446edd1e1a
Rollup merge of #79951 - LeSeulArtichaut:ty-ir, r=nikomatsakis
Refractor a few more types to `rustc_type_ir`

In the continuation of #79169, ~~blocked on that PR~~.

This PR:
 - moves `IntVarValue`, `FloatVarValue`, `InferTy` (and friends) and `Variance`
 - creates the `IntTy`, `UintTy` and `FloatTy` enums in `rustc_type_ir`, based on their `ast` and `chalk_ir` equilavents, and uses them for types in the rest of the compiler.

~~I will split up that commit to make this easier to review and to have a better commit history.~~
EDIT: done, I split the PR in commits of 200-ish lines each

r? `````@nikomatsakis````` cc `````@jackh726`````
2021-01-28 15:09:02 +09:00
jumbatm
a1a7830465 Use symbol interning to avoid string alloc. 2021-01-28 08:03:36 +10:00
Mara Bos
d5414f9a9f Implement new panic!() behaviour for Rust 2021. 2021-01-25 13:48:11 +01:00
Jonas Schievink
81647c627a
Rollup merge of #81275 - jyn514:time-render, r=wesleywiser
Fix <unknown> queries and add more timing info to render_html

Closes https://github.com/rust-lang/rust/issues/81251.

##  Fix `<unknown>` queries

This happened because `alloc_query_strings` was never called.

##  Add more timing info to render_html

This still has some issues I'm not sure how to work out:

- `create_renderer` and `renderer_after_krate` aren't shown by default.
  I want something like `verbose_generic_activity_with_arg`, but it doesn't exist.

I'm also not sure how to show activities that aren't on by default - I
tried `-Z self-profile -Z self-profile-args=all`, but it didn't show up.

r? `@wesleywiser`
2021-01-23 20:16:10 +01:00
Joshua Nelson
0679a4cd93 Remove special casing of rustdoc in rustc_lint
This is no longer necessary now that rustdoc doesn't run
everybody_loops.
2021-01-22 14:50:21 -05:00
Mara Bos
3682a06dcf
Rollup merge of #81236 - estebank:everybody-loop-now, r=oli-obk
Gracefully handle loop labels missing leading `'` in different positions

Fix #81192.

* Account for labels when suggesting `loop` instead of `while true`
* Suggest `'a` when given `a` only when appropriate
* Add loop head span to hir
* Tweak error for invalid `break expr`
* Add more misspelled label tests
* Avoid emitting redundant "unused label" lint
* Parse loop labels missing a leading `'`

Each commit can be reviewed in isolation.
2021-01-22 14:30:19 +00:00
bors
25f39fe802 Auto merge of #81135 - jyn514:no-backticks, r=flip1995
Fix formatting for removed lints

- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility

I split this out of https://github.com/rust-lang/rust/pull/80527/ because it kept causing tests to fail, and it's a good change to have anyway.

r? `@flip1995`
2021-01-22 06:13:19 +00:00
Esteban Küber
707ce2b798 Account for labels when suggesting loop instead of while true 2021-01-21 21:41:46 -08:00
LeSeulArtichaut
50e1ae15e9 Use ty::{IntTy,UintTy,FloatTy} in rustc 2021-01-18 21:09:30 +01:00
Cameron Steffen
21fb586c0c Query for TypeckResults in LateContext::qpath_res
Actually fulfills the documented guarantees.
2021-01-18 13:38:14 -06:00
Cameron Steffen
63a1eeea23 Reset LateContext enclosing body in nested items
Prevents LateContext::maybe_typeck_results() from returning data in a
nested item without a body. Consequently, LateContext::qpath_res is less
likely to ICE when called in a nested item. Would have prevented
rust-lang/rust-clippy#4545, presumably.
2021-01-18 13:38:14 -06:00
Joshua Nelson
77b5ced3aa Fix formatting for removed lints
- Don't add backticks for the reason a lint was removed. This is almost
never a code block, and when it is the backticks should be in the reason
itself.
- Don't assume clippy is the only tool that needs to be checked for
backwards compatibility
2021-01-17 16:18:02 -05:00
bors
4253153db2 Auto merge of #80679 - jackh726:predicate-kind-take2, r=lcnr
Remove PredicateKind and instead only use Binder<PredicateAtom>

Originally brought up in https://github.com/rust-lang/rust/pull/76814#discussion_r546858171

r? `@lcnr`
2021-01-17 20:49:11 +00:00
Jack Huey
3dea68de1d Review changes 2021-01-16 18:56:37 -05:00
flip1995
5e3df4266a
More advanced unknown lint suggestion
This copies the unknown_lints code clippy uses for its
unknown_clippy_lints lint to rustc. The unknown_clippy_lints code is
more advanced, because it doesn't suggest renamed or removed lints and
correctly suggest lower casing lints.
2021-01-16 19:44:46 +01:00
Joshua Nelson
5053db7c00 Don't make tools responsible for checking unknown and renamed lints
Previously, clippy (and any other tool emitting lints) had to have their
own separate UNKNOWN_LINTS pass, because the compiler assumed any tool
lint could be valid. Now, as long as any lint starting with the tool
prefix exists, the compiler will warn when an unknown lint is present.
2021-01-15 16:08:28 -05:00
LingMan
a56bffb4f9 Use Option::map_or instead of .map(..).unwrap_or(..) 2021-01-14 19:23:59 +01:00
Mark Rousskov
c4a8d7f86a Introduce missing ABI lint on extern blocks 2021-01-13 07:49:16 -05:00
bors
fc93e4719c Auto merge of #80960 - Dylan-DPC:rollup-89tri8x, r=Dylan-DPC
Rollup of 10 pull requests

Successful merges:

 - #78901 (diagnostics: Note capturing closures can't be coerced to fns)
 - #79588 (Provide more information for HRTB lifetime errors involving closures)
 - #80232 (Remove redundant def_id lookups)
 - #80662 (Added support for i386-unknown-linux-gnu and i486-unknown-linux-gnu)
 - #80736 (use Once instead of Mutex to manage capture resolution)
 - #80796 (Update to LLVM 11.0.1)
 - #80859 (Fix --pretty=expanded with --remap-path-prefix)
 - #80922 (Revert "Auto merge of #76896 - spastorino:codegen-inline-fns2)
 - #80924 (Fix rustdoc --test-builder argument parsing)
 - #80935 (Rename `rustc_middle::lint::LevelSource` to `LevelAndSource`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2021-01-13 04:29:45 +00:00
Dylan DPC
5b90fe1c30
Rollup merge of #80935 - pierwill:rustc_middle-levelandsource, r=petrochenkov
Rename `rustc_middle::lint::LevelSource` to `LevelAndSource`

This continues work in https://github.com/rust-lang/rust/pull/80274 to improve code readability.

This naming follows a pattern seen elsewhere in the compiler (e.g. [`rustc_middle::ty::TypeAndMut`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TypeAndMut.html)).
2021-01-13 03:20:27 +01:00
bors
150d1fee04 Auto merge of #79322 - jyn514:refactor-impl, r=estebank
Separate out a `hir::Impl` struct

This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.

See `rustc_save_analysis::dump_visitor::process_impl` or `rustdoc::clean::clean_impl` for a good example of how this makes `impl`s easier to work with.

r? `@petrochenkov` maybe?
2021-01-13 01:40:41 +00:00
Joshua Nelson
a8ff647deb Separate out a hir::Impl struct
This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.
2021-01-12 20:32:33 -05:00
pierwill
2e3ab43f5c Rename rustc_middle::lint::LevelSource to LevelAndSource 2021-01-11 18:02:09 -08:00
jumbatm
4b740acea2 Add FIXME note about storing &'tcx str 2021-01-12 03:31:01 +10:00
jumbatm
7a46a4f219 Remove unnecessary allocation. 2021-01-12 03:31:01 +10:00
jumbatm
15c64a181b Use tcx.symbol_name to check for clashes. 2021-01-12 03:31:00 +10:00
bors
c97f11af7b Auto merge of #79414 - sasurau4:feature/add-suggestion-for-pattern-in-fns-without-body, r=matthewjasper
Add suggestion for PATTERNS_IN_FNS_WITHOUT_BODY

## Overview

Fix #78927
2021-01-10 20:48:27 +00:00
Guillaume Gomez
ff1f21a8fd
Rollup merge of #80628 - matthiaskrgr:match_ref_pats, r=varkor
reduce borrowing and (de)referencing around match patterns (clippy::match_ref_pats)
2021-01-03 17:09:11 +01:00
Matthias Krüger
8a90626a46 reduce borrowing and (de)referencing around match patterns (clippy::match_ref_pats) 2021-01-02 20:09:17 +01:00
Skynoodle
750c52af73 Add snake case lint note about keyword identifiers which cannot be raw 2021-01-02 15:46:41 +00:00
Skynoodle
91f436b456 Add suggestion to use raw identifiers when fixing snake-case lints 2021-01-01 18:38:30 +00:00
bors
923e3d2400 Auto merge of #80500 - jyn514:track-caller, r=nagisa
Add `#[track_caller]` to `bug!` and `register_renamed`

Before:

```
thread 'rustc' panicked at 'compiler/rustc_lint/src/context.rs:267:18: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:34:26
```

After:

```
thread 'rustc' panicked at 'src/librustdoc/core.rs:455:24: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:35:26
```

The reason I added it to `register_renamed` too is that any panic in
that function will be the caller's fault.
2020-12-31 03:17:50 +00:00
Mara Bos
9e8edc8c22
Rollup merge of #80495 - jyn514:rename-empty, r=petrochenkov
Rename kw::Invalid -> kw::Empty

See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.

r? `@petrochenkov`
2020-12-30 20:56:58 +00:00
Joshua Nelson
edeac1778c Rename kw::Invalid -> kw::Empty
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20there.20a.20symbol.20for.20the.20empty.20string.3F/near/220054471
for context.
2020-12-30 09:50:02 -05:00
Joshua Nelson
56ea926b1c Add #[track_caller] to bug! and register_renamed
Before:

```
thread 'rustc' panicked at 'compiler/rustc_lint/src/context.rs:267:18: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:34:26
```

After:

```
thread 'rustc' panicked at 'src/librustdoc/core.rs:455:24: invalid lint renaming of broken_intra_doc_links to rustdoc::broken_intra_doc_links', compiler/rustc_middle/src/util/bug.rs:35:26
```

The reason I added it to `register_renamed` too is that any panic in
that function will be the caller's fault.
2020-12-29 23:18:11 -05:00
Aaron Hill
c857cbeb06
Lint on redundant trailing semicolon after item
We now lint on code like this:

```rust
fn main() {
    fn foo() {};
    struct Bar {};
}
```

Previously, this caused warnings in Cargo, so it was disabled.
2020-12-29 16:30:02 -05:00
Bastian Kauschke
06cc9c26da stabilize min_const_generics 2020-12-26 18:24:10 +01:00
Dylan DPC
b295b8e67b
Rollup merge of #80274 - pierwill:lintlevelsource, r=petrochenkov
Rename rustc_middle::lint::LintSource

Rename [`rustc_middle::lint::LintSource`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/enum.LintSource.html) to `rustc_middle::lint::LintLevelSource`.

This enum represents the source of a *lint level*, not a lint. This should improve code readability.

Update: Also documents `rustc_middle::lint::LevelSource` to clarify.
2020-12-25 03:39:36 +01:00
bors
75e1acb63a Auto merge of #78242 - Nadrieril:rename-overlapping_endpoints-lint, r=varkor
Rename `overlapping_patterns` lint

As discussed in https://github.com/rust-lang/rust/issues/65477. I also tweaked a few things along the way.

r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
2020-12-22 10:32:03 +00:00
pierwill
d3900d3775 Document rustc_middle::lint::LevelSource
This is to clarify the difference between `LevelSource`
and `LintLevelSource`.

Appease x.py fmt.
2020-12-21 15:03:00 -08:00
pierwill
aec3575aa7 Rename rustc_middle::lint::LintSource
Rename rustc_middle::lint::LintSource to rustc_middle::lint::LintLevelSource.
2020-12-21 14:30:50 -08:00
Daiki Ihara
acbebd81d4 add suggest for PatternsInWithoutBody 2020-12-21 21:40:47 +09:00
Camelid
d00ca11202 Add 'consider using' message to overflowing_literals
Ironically, the overflowing_literals handler for binary or hex already
had this message! You would think it would be the other way around :)
2020-12-12 14:59:35 -08:00
Jack Huey
ed80815bf2 Move binder for dyn to each list item 2020-12-11 15:02:46 -05:00
Tomasz Miąsko
8fc246251f Types with a hidden niche are not known to be non-null 2020-12-10 00:00:00 +00:00