rustc: Include semicolon when removing `extern crate`
Currently the lint for removing `extern crate` suggests removing `extern crate`
most of the time, but the rest of the time it suggest replacing it with `use
crate_name`. Unfortunately though when spliced into the original code you're
replacing
extern crate foo;
with
use foo
which is syntactically invalid! This commit ensure that the trailing semicolon
is included in rustc's suggestion to ensure that the code continues to compile
afterwards.
Better error reporting in Copy derive
In Copy derive, report all fulfillment erros when present and do not report errors for types tainted with `TyErr`. Also report all fields which are not Copy rather than just the first.
Also refactored `fn fully_normalize`, removing the not very useful helper function along with a FIXME to the closed issue #26721 that looks out of context now.
Fixes#50480
r? @estebank
In Copy derive, report all fulfillment erros when present and do not
report errors for types tainted with `TyErr`. Also report all fields
which are not Copy rather than just the first.
Also refactored `fn fully_normalize`, removing the not very useful
helper function along with a FIXME to the closed issue #26721 that's
looks out of context now.
This commit updates one of the edition lints to only suggest deleting `extern
crate` if it actually works. Otherwise this can yield some confusing behavior
with rustfix specifically where if you accidentally deny the `rust_2018_idioms`
lint in the 2015 edition it's suggesting features that don't work!
Currently the lint for removing `extern crate` suggests removing `extern crate`
most of the time, but the rest of the time it suggest replacing it with `use
crate_name`. Unfortunately though when spliced into the original code you're
replacing
extern crate foo;
with
use foo
which is syntactically invalid! This commit ensure that the trailing semicolon
is included in rustc's suggestion to ensure that the code continues to compile
afterwards.
The Higher Intermediate Representation doesn't have spans for visibility
keywords, so we were assuming that the first whitespace-delimited token
in the item span was the `pub` to be weakened. This doesn't work for
brace-grouped `use`s, which get lowered as if they were several
individual `use` statements, but with spans that only cover the braced
path-segments. Constructing a correct suggestion here presents some
challenges—until someone works those out, we can at least protect the
dignity of our compiler marking the suggestion for `use` items as
potentially incorrect.
This resolves#50455 (but again, it would be desirable in the future to
make a correct suggestion instead of copping out like this).
idiom lints for removing `extern crate`
Based off of https://github.com/rust-lang/rust/pull/49789
This contains two lints:
- One that suggests replacing pub extern crates with pub use, and removing non-pub extern crates entirely
- One that suggests rewriting `use modulename::...::cratename::foo` as `cratename::foo`
The latter is a bit tricky to emit suggestions for; for one this involves splicing spans (never a good idea), and it also won't be able to correctly
handle `use module::{cratename, foo}` and use-trees. I'm not sure how to proceed here. Currently it doesn't suggest anything at all.
Perhaps we can go the other way and suggest removal of all extern crates _except_ those used through modules (stash node ids somewhere) and suggest replacing those with `<visibility> use`?
r? @nikomatsakis
fixes https://github.com/rust-lang/rust/issues/48719
In issue #49588, Michael Lamparski pointed out a scenario in which the
non-shorthand-field-patterns lint could be triggered by a macro-expanded
pattern, in a way which was direly unwieldy for the macro author to guard
against and unreasonable to expect the macro user to take into account. We can
avoid this by not linting patterns that come from macro-expansions. Although
this entails accepting "false negatives" where the lint could genuinely improve
macro-templated code, avoiding the reported "true-but-super-annoying positive"
may be worth the trade? (Some precedent for these relative priorities exists as
no. 47775 (5985b0b0).)
Resolves#49588.
Improve lint for type alias bounds
First of all, I learned just today that I was wrong assuming that the bounds in type aliases are entirely ignored: It turns out they are used to resolve associated types in type aliases. So:
```rust
type T1<U: Bound> = U::Assoc; // compiles
type T2<U> = U::Assoc; // fails
type T3<U> = <U as Bound>::Assoc; // "correct" way to write this, maybe?
```
I am sorry for creating this mess.
This PR changes the wording of the lint accordingly. Moreover, since just removing the bound is no longer always a possible fix, I tried to detect cases like `T1` above and show a helpful message to the user:
```
warning: bounds on generic parameters are not enforced in type aliases
--> $DIR/type-alias-bounds.rs:57:12
|
LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases
| ^^^^^
|
= help: the bound will not be checked when the type alias is used, and should be removed
help: use absolute paths (i.e., <T as Trait>::Assoc) to refer to associated types in type aliases
--> $DIR/type-alias-bounds.rs:57:21
|
LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases
| ^^^^^^^^
```
I am not sure if I got this entirely right. Ideally, we could provide a suggestion involving the correct trait and type name -- however, while I have access to the HIR in the lint, I do not know how to get access to the resolved name information, like which trait `Assoc` belongs to above. The lint does not even run if that resolution fails, so I assume that information is available *somewhere*...
This is a follow-up for (parts of) https://github.com/rust-lang/rust/pull/48326. Also see https://github.com/rust-lang/rust/issues/21903.
This changes the name of a lint, but that lint was just merged to master yesterday and has never even been on beta.
- `ParamEnv::empty()` -- does not reveal all, good for typeck
- `ParamEnv::reveal_all()` -- does, good for trans
- `param_env.with_reveal_all()` -- converts an existing parameter environment
First of all, the lint is specific for type aliases. Second, it turns out the
bounds are not entirely ignored but actually used when accessing associated
types. So change the wording of the lint, and adapt its name to reality.
The lint has never been on stable or beta, so renaming is safe.
Warn about ignored generic bounds in `for`
This adds a new lint to fix#42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.
Questions to the reviewer:
* Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!).
* Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`).
* For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in https://github.com/rust-lang/rust/issues/42181#issuecomment-306924389, but I feel that can only happen in a new epoch -- right?
Cc @eddyb
Also move the check for not having type parameters into ast_validation.
I was not sure what to do with compile-fail/issue-23046.rs: The issue looks like
maybe the bounds actually played a role in triggering the ICE, but that seems
unlikely given that the compiler seems to entirely ignore them. However, I
couldn't find a testcase without the bounds, so I figured the best I could do is
to just remove the bounds and make sure at least that keeps working.
