Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
This commit builds on the fix from #58161 (which fixed miscompilation
caused by the introduction of `AscribeUserType` patterns for associated
constants) to start checking these patterns are well-formed for ranges
(previous fix just ignored them so that miscompilation wouldn't occur).
Require a list of features in `#[allow_internal_unstable]`
The blanket-permission slip is not great and will likely give us trouble some point down the road.
Fix span for closure return type when annotated.
Fixes#58053.
This PR 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.
r? @pnkfelix
This commit modifies name resolution error reporting so that if a name
is in scope and has been imported then we do not suggest importing it.
This can occur when we add a label about constructors not being visible
due to private fields. In these cases, we know that the struct/variant
has been imported and we should silence any suggestions to import the
struct/variant.
Deduplicate mismatched delimiter errors
Delay unmatched delimiter errors until after the parser has run to deduplicate them when parsing and attempt recovering intelligently.
Second attempt at #54029, follow up to #53949. Fix#31528.
Avoid committing to autoderef in object method probing
This fixes the "leak" introduced in #57835 (see test for details, also apparently #54252 had no tests for the "leaks" that were fixed in it, so go ahead and add one).
Maybe beta-nominating because regression, but I'm against landing things on beta we don't have to.
r? @nikomatsakis
Error on duplicate matcher bindings
fix #57593
This should not be merged without a crater run and maybe an FCP. Discussion is ongoing at #57593.
TODO:
- [x] write tests
- [x] crater run
- [x] ~maybe need edition gating?~ not for 1 regression /centril
r? @petrochenkov
Lower constant patterns with ascribed types.
Fixes#57960.
This PR 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 PR unwraps that to
access the constant pattern inside and behaves as before.
r? @pnkfelix
- Point at the body expression of the match arm with the type error.
- Point at the prior match arms explicitely stating the evaluated type.
- Point at the entire match expr in a secondary span, instead of primary.
- For type errors in the first match arm, the cause is outside of the
match, treat as implicit block error to give a more appropriate error.
Allow #[repr(align(x))] on enums (#57996)
Tracking issue: #57996
Implements an extension of [RFC 1358](https://github.com/rust-lang/rfcs/blob/master/text/1358-repr-align.md) behind a feature flag (`repr_align_enum`). Originally introduced here for structs: #39999.
It seems like only HIR-level changes are required, since enums are already aware of their alignment (due to alignment of their limbs).
cc @bitshifter
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
Add information to higher-ranked lifetimes conflicts error messages
Make these errors go through the new "placeholder error" code path, to have self tys displayed and make them hopefully less confusing.
Should fix#57362.
r? @nikomatsakis — so we can iterate on the specific wording you wanted.
add typo suggestion to unknown attribute error
Provides a suggestion using Levenshtein distance to suggest built-in attributes and attribute macros.
Fixes#49270.
Use pinning for generators to make trait safe
I'm unsure whether there needs to be any changes to the actual generator transform. Tests are passing so the fact that `Pin<&mut T>` is fundamentally the same as `&mut T` seems to allow it to still work, but maybe there's something subtle here that could go wrong.
This is specified in [RFC 2349 § Immovable generators](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md#immovable-generators) (although, since that RFC it has become safe to create an immovable generator, and instead it's unsafe to resume any generator; with these changes both are now safe and instead the unsafety is moved to creating a `Pin<&mut [static generator]>` which there are safe APIs for).
CC #43122
This commit extends existing suggestions to prefix unused variable
bindings in match arms with an underscore so that it applies to all
patterns in a match arm.
When mentioning lifetimes, only invert wording between the expected trait and the self type when the self type has the vid.
This way, the lifetimes always stay close to the self type or trait ref that actually contains them.
Suggest removing leading left angle brackets.
Fixes#57819.
This PR adds errors and accompanying suggestions as below:
```
bar::<<<<<T as Foo>::Output>();
^^^ help: remove extra angle brackets
```
r? @estebank
Implement optimize(size) and optimize(speed) attributes
This PR implements both `optimize(size)` and `optimize(speed)` attributes.
While the functionality itself works fine now, this PR is not yet complete: the code might be messy in places and, most importantly, the compiletest must be improved with functionality to run tests with custom optimization levels. Otherwise the new attribute cannot be tested properly. Oh, and not all of the RFC is implemented – attribute propagation is not implemented for example.
# TODO
* [x] Improve compiletest so that tests can be written;
* [x] Assign a proper error number (E9999 currently, no idea how to allocate a number properly);
* [ ] Perhaps reduce the duplication in LLVM attribute assignment code…
Rollup of 5 pull requests
Successful merges:
- #56233 (Miri and miri-related code contains repetitions of `(n << amt) >> amt`)
- #57645 (distinguish "no data" from "heterogeneous" in ABI)
- #57734 (Fix evaluating trivial drop glue in constants)
- #57886 (Add suggestion for moving type declaration before associated type bindings in generic arguments.)
- #57890 (Fix wording in diagnostics page)
Failed merges:
r? @ghost
Fix evaluating trivial drop glue in constants
```rust
struct A;
impl Drop for A {
fn drop(&mut self) {}
}
const FOO: Option<A> = None;
const BAR: () = (FOO, ()).1;
```
was erroring with
```
error: any use of this value will cause an error
--> src/lib.rs:9:1
|
9 | const BAR: () = (FOO, ()).1;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^-^
| |
| calling non-const function `std::ptr::real_drop_in_place::<(std::option::Option<A>, ())> - shim(Some((std::option::Option<A>, ())))`
|
= note: #[deny(const_err)] on by default
error: aborting due to previous error
```
before this PR. According to godbolt this last compiled successfully in 1.27
distinguish "no data" from "heterogeneous" in ABI
Ignore zero-sized types when computing whether something is a homogeneous aggregate, except be careful of VLA.
cc #56877
r? @arielb1
cc @eddyb
[NLL] Clean up handling of type annotations
* Renames (Canonical)?UserTypeAnnotation -> (Canonical)?UserType so that the name CanonicalUserTypeAnnotation is free.
* Keep the inferred type associated to user type annotations in the MIR, so that it can be compared against the annotated type, even when the annotated expression gets removed from the MIR. (#54943)
* Use the inferred type to allow infallible handling of user type projections (#57531)
* Uses revisions for the tests in #56993
* Check the types of `Unevaluated` constants with no annotations (#46702)
* Some drive-by cleanup
Closes#46702Closes#54943Closes#57531Closes#57731
cc #56993 leaving this open to track the underlying issue: we are not running tests with full NLL enabled on CI at the moment
r? @nikomatsakis
This commit extends existing suggestions to move lifetimes before types
in generic arguments to also suggest moving types behind associated type
bindings.
Print visible name for types as well as modules.
Fixes#56943 and fixes#57713.
This commit extends previous work in #55007 where the name from the
visible parent was used for modules. Now, we also print the name from
the visible parent for types.
r? @estebank
When using value after move, point at span of local
When trying to use a value after move, instead of using a note, point
at the local declaration that has a type that doesn't implement `Copy`
trait.
```
error[E0382]: use of moved value: `x`
--> $DIR/issue-34721.rs:27:9
|
LL | pub fn baz<T: Foo>(x: T) -> T {
| - - move occurs because `x` has type `T`, which does not implement the `Copy` trait
| |
| consider adding a `Copy` constraint to this type argument
LL | if 0 == 1 {
LL | bar::bar(x.zero())
| - value moved here
LL | } else {
LL | x.zero()
| - value moved here
LL | };
LL | x.zero()
| ^ value used here after move
```
Fix#34721.
