| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rustdoc: Report Layout of enum variants
Followup of #83501, Fixes #86253.
cc `@camelid`
`@rustbot` label A-rustdoc
|
|
|
|
Suggest deriving traits if possible
This only applies to builtin derives as I don't think there is a
clean way to get the available derives in typeck.
Closes #85851
|
|
Remove `hir::GenericBound::Unsized`
Rather than "moving" the `?Sized` bounds to the param bounds, just also check where clauses in `astconv`. I also did some related cleanup here, but that's not strictly neccesary. Also going to do a perf run here.
r? `@estebank`
|
|
2229: Don't move out of drop type
Fixes #88476
r? `@nikomatsakis`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Detect likely `struct` literal using parentheses as delimiters and emit
targeted suggestion instead of type ascription parse error.
Fix #61326.
|
|
r=petrochenkov
Fix handling of +whole-archive native link modifier.
This PR fixes a bug in `add_upstream_native_libraries` that led to the `+whole-archive` modifier being ignored when linking in native libs.
~~Note that the PR does not address the situation when `+whole-archive` is combined with `+bundle`.~~
`@wesleywiser's` commit adds validation code that turns combining `+whole-archive` with `+bundle` into an error.
Fixes https://github.com/rust-lang/rust/issues/88085.
r? `@petrochenkov`
cc `@wesleywiser` `@gcoakes`
|
|
|
|
Note that this incorrectly suggests a shared borrow,
but at least we know it's happening.
|
|
Fixes #88701
|
|
This fixes #88609.
Previously, the return type of `fn main()` would not have any associated
type projections within normalized before checking if it implements the
standard library trait `std::process::Termination`. This commit appears
to fix it.
This feels vaguely symptomatic of a problem in the underlying trait
solving engine, but I am not sure how I would solve that. I am unsure
why the example in #88609 with `assert_impl_termination` and `fn foo()`
work, but simply `fn main()` doesn't. The way that I solved this is also
probably not the best way to do this, so please let me know if there is
a better way to do this.
I have added a build-pass regression test for this issue.
|
|
this also renders them as `_`, which rustdoc previously did not.
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #88602 (Add tests for some const generics issues)
- #88647 (Document when to use Windows' `symlink_dir` vs. `symlink_file`)
- #88659 (Remove SmallVector mention)
- #88661 (Correct typo)
- #88673 (Fix typo: needede -> needed)
- #88685 (:arrow_up: rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This only applies to builtin derives as I don't think there is a
clean way to get the available derives in typeck.
Closes #85851
|
|
Change scope of temporaries in match guards
Each pattern in a match arm has its own copy of the match guard in MIR, with its own temporary, so it has to be dropped before the the guards are joined to the single copy of the arm. This PR changes `then_else_break` to allow it to put the temporary in the innermost scope possible. This change isn't done for `if` expressions because that affects a large number of mir-opt tests and could more significantly affect performance.
closes #88649
r? `@oli-obk`
|
|
Correct typo
found while addressing reviewer remarks for #88316
|
|
Add tests for some const generics issues
closes #82956
closes #84659
closes #86530
closes #86535
there is also a random test in here about array repeat expressions that I already had on this branch but it seems to fit the theme of this PR so kept it...
r? `@lcnr`
|
|
Improve structured tuple struct suggestion
Previously, the span was just for the constructor name, which meant it
would result in syntactically-invalid code when applied. Now, the span
is for the entire expression.
I also changed it to use `span_suggestion_verbose`, for two reasons:
1. Now that the suggestion span has been corrected, the output is a bit
cluttered and hard to read. Putting the suggestion its own window
creates more space.
2. It's easier to see what's being suggested, since now the version
after the suggestion is applied is shown.
r? `@davidtwco`
|
|
|
|
Add tests for issues fixed by #85499
Closes #80706
Closes #80956
Closes #81809
Closes #85455
|
|
Fix #88256 remove duplicated diagnostics
Fix #88256
|
|
|
|
Avoid invoking the hir_crate query to traverse the HIR
Walking the HIR tree is done using the `hir_crate` query. However, this is unnecessary, since `hir_owner(CRATE_DEF_ID)` provides the same information. Since depending on `hir_crate` forces dependents to always be executed, this leads to unnecessary work.
By splitting HIR and attributes visits, we can avoid an edge to `hir_crate` when trying to visit the HIR tree.
|
|
Stop allocating vtable entries for non-object-safe methods
Current a vtable entry is allocated for all associated fns, even if the method is not object-safe: https://godbolt.org/z/h7vx6f35T
As a result, each vtable for `Iterator`' currently consumes 74 `usize`s. This PR stops allocating vtable entries for those methods, reducing vtable size of each `Iterator` vtable to 7 `usize`s.
Note that this PR introduces will cause more invocations of `is_vtable_safe_method`. So a perf run might be needed. If result isn't favorable then we might need to query-ify `is_vtable_safe_method`.
|
|
Each pattern in a match arm has its own copy of the match guard in MIR,
with its own temporary, so it has to be dropped before the the guards
are joined to the single copy of the arm.
|
|
|
|
rustdoc: Clean up handling of lifetime bounds
Previously, rustdoc recorded lifetime bounds by rendering them into the
name of the lifetime parameter. Now, it leaves the name as the actual
name and instead records lifetime bounds in an `outlives` list, similar
to how type parameter bounds are recorded.
Also, higher-ranked lifetimes cannot currently have bounds, so I simplified
the code to reflect that.
r? `@GuillaumeGomez`
|
|
|
|
Fix 2021 `dyn` suggestion that used code as label
The arguments to `span_suggestion` were in the wrong order, so the error
looked like this:
error[E0783]: trait objects without an explicit `dyn` are deprecated
--> src/test/ui/editions/dyn-trait-sugg-2021.rs:10:5
|
10 | Foo::hi(123);
| ^^^ help: <dyn Foo>: `use `dyn``
Now the error looks like this, as expected:
error[E0783]: trait objects without an explicit `dyn` are deprecated
--> src/test/ui/editions/dyn-trait-sugg-2021.rs:10:5
|
10 | Foo::hi(123);
| ^^^ help: use `dyn`: `<dyn Foo>`
This issue was only present in the 2021 error; the 2018 lint was
correct.
r? `@m-ou-se`
|
|
Provide more context on incorrect inner attribute
Suggest changing an inner attribute into an outer attribute if followed by an item.
|
|
|
|
|
|
The arguments to `span_suggestion` were in the wrong order, so the error
looked like this:
error[E0783]: trait objects without an explicit `dyn` are deprecated
--> src/test/ui/editions/dyn-trait-sugg-2021.rs:10:5
|
10 | Foo::hi(123);
| ^^^ help: <dyn Foo>: `use `dyn``
Now the error looks like this, as expected:
error[E0783]: trait objects without an explicit `dyn` are deprecated
--> src/test/ui/editions/dyn-trait-sugg-2021.rs:10:5
|
10 | Foo::hi(123);
| ^^^ help: use `dyn`: `<dyn Foo>`
This issue was only present in the 2021 error; the 2018 lint was
correct.
|
|
|
|
|
|
fix(rustc_lint): better detect when parens are necessary
Fixes #88519
|
|
Detect bare blocks with type ascription that were meant to be a `struct` literal
Address part of #34255.
Potential improvement: silence the other knock down errors in `issue-34255-1.rs`.
|
|
Add regression test for a spurious import
This PR adds a test that verifies that the bug described in the linked issue does not creep back into the code. In essence it checks that compiling some specific code (that uses 128 bit multiplication) with a specific set of compiler options does not lead to a spurious import of a panic function.
I noticed that other wasm tests use `# only-wasm32-bare` in their `Makefile`. This will skip the test for me. I did not find out how to run this test locally. Maybe someone can help.
closes #78744
r? `@jyn514`
|
|
Fix drop handling for `if let` expressions
MIR lowering for `if let` expressions is now more complicated now that
`if let` exists in HIR. This PR adds a scope for the variables bound in
an `if let` expression and then uses an approach similar to how we
handle loops to ensure that we reliably drop the correct variables.
Closes #88307
cc `@flip1995` `@richkadel` `@c410-f3r`
|
|
|
|
Move global analyses from lowering to resolution
Split off https://github.com/rust-lang/rust/pull/87234
r? `@petrochenkov`
|
|
Address part of #34255.
Potential improvement: silence the other knock down errors in
`issue-34255-1.rs`.
|
