This commit fixes a bug introduced by #55937 which started checking user
type annotations for associated type patterns. Where lowering a
associated constant expression would previously return a
`PatternKind::Constant`, it now returns a `PatternKind::AscribeUserType`
with a `PatternKind::Constant` inside, this commit unwraps that to
access the constant pattern inside and behaves as before.
Add a forever unstable opt-out of const qualification checks
r? @eddyb
cc @RalfJung @Centril
basically a forever unstable way to screw with const things in horribly unsafe, unsound and incoherent ways.
Note that this does *not* affect miri except by maybe violating assumptions that miri makes. But there's no change in how miri evaluates things.
Overhaul `syntax::fold::Folder`.
This PR changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
This makes the code faster and more concise.
This commit changes `syntax::fold::Folder` from a functional style
(where most methods take a `T` and produce a new `T`) to a more
imperative style (where most methods take and modify a `&mut T`), and
renames it `syntax::mut_visit::MutVisitor`.
The first benefit is speed. The functional style does not require any
reallocations, due to the use of `P::map` and
`MoveMap::move_{,flat_}map`. However, every field in the AST must be
overwritten; even those fields that are unchanged are overwritten with
the same value. This causes a lot of unnecessary memory writes. The
imperative style reduces instruction counts by 1--3% across a wide range
of workloads, particularly incremental workloads.
The second benefit is conciseness; the imperative style is usually more
concise. E.g. compare the old functional style:
```
fn fold_abc(&mut self, abc: ABC) {
ABC {
a: fold_a(abc.a),
b: fold_b(abc.b),
c: abc.c,
}
}
```
with the imperative style:
```
fn visit_abc(&mut self, ABC { a, b, c: _ }: &mut ABC) {
visit_a(a);
visit_b(b);
}
```
(The reductions get larger in more complex examples.)
Overall, the patch removes over 200 lines of code -- even though the new
code has more comments -- and a lot of the remaining lines have fewer
characters.
Some notes:
- The old style used methods called `fold_*`. The new style mostly uses
methods called `visit_*`, but there are a few methods that map a `T`
to something other than a `T`, which are called `flat_map_*` (`T` maps
to multiple `T`s) or `filter_map_*` (`T` maps to 0 or 1 `T`s).
- `move_map.rs`/`MoveMap`/`move_map`/`move_flat_map` are renamed
`map_in_place.rs`/`MapInPlace`/`map_in_place`/`flat_map_in_place` to
reflect their slightly changed signatures.
- Although this commit renames the `fold` module as `mut_visit`, it
keeps it in the `fold.rs` file, so as not to confuse git. The next
commit will rename the file.
This commit adjusts the span used to label closure return types so that
if the user specifies the return type, i.e. `|_| -> X {}` instead of
`|_| {}`, we correctly highlight all of it and not just the last
character.
Add suggestion for duplicated import.
Fixes#52891.
This PR adds a suggestion when a import is duplicated (ie. the same name
is used twice trying to import the same thing) to remove the second
import.
Currently, the target of a use statement will be updated with
the visibility of the use statement itself (if the use statement was
visible).
This commit ensures that if the path to the target item is via another
use statement then that intermediate use statement will also have the
visibility updated like the target. This silences incorrect
`unreachable_pub` lints with inactionable suggestions.
Implement public/private dependency feature
Implements https://github.com/rust-lang/rust/issues/44663
The core implementation is done - however, there are a few issues that still need to be resolved:
- [x] The `EXTERNAL_PRIVATE_DEPENDENCY` lint currently does notthing when the `public_private_dependencies` is not enabled. Should mentioning the lint (in an `allow` or `deny` attribute) be an error if the feature is not enabled? (Resolved- the feature was removed)
- [x] Crates with the name `core` and `std` are always marked public, without the need to explcitily specify them on the command line. Is this what we want to do? Do we want to allow`no_std`/`no_core` crates to explicitly control this in some way? (Resolved - private crates are now explicitly specified)
- [x] Should I add additional UI tests? (Resolved - added more tests)
- [x] Does it make sense to be able to allow/deny the `EXTERNAL_PRIVATE_DEPENDENCY` on an individual item? (Resolved - this is implemented)
Add suggestions to deprecation lints
Clippy used to do this suggestion, but the clippy lints happen after the deprecation lints so we ended up never seeing the structured suggestions.
This commit adds a suggestion when a import is duplicated (ie. the same name
is used twice trying to import the same thing) to remove the second
import.
Add MOVBE x86 CPU feature
I have no idea if this is correct. I basically copied the ADX feature. I verified the feature is also called `movbe` in LLVM.
I marked this to become stable immediately, as part of the RFC 2045.
r? @alexcrichton
