Add hint for unresolved associated trait items if the trait has a single item
This PR introduces a special-cased hint for unresolved trait items paths. It is shown if:
- the path was not resolved to any existing trait item
- and no existing trait item's name was reasonably close with regard to edit distance
- and the trait only has a single item in the corresponding namespace
I didn't know where I should put tests, therefore so far I just managed to bless two existing tests. I would be glad for hints where should tests for a hint like this be created, how should they be named (with reference to the original issue?) and what tests should I create (is it enough to test it just for types? or create separate tests also for functions and constants?).
It could also be turned into a machine applicable suggestion I suppose.
This is my first `rustc` PR, so please go easy on me :)
Fixes: https://github.com/rust-lang/rust/issues/87638
Rollup of 9 pull requests
Successful merges:
- #87561 (thread set_name haiku implementation.)
- #87715 (Add long error explanation for E0625)
- #87727 (explicit_generic_args_with_impl_trait: fix min expected number of generics)
- #87742 (Validate FFI-safety warnings on naked functions)
- #87756 (Add back -Zno-profiler-runtime)
- #87759 (Re-use std::sealed::Sealed in os/linux/process.)
- #87760 (Promote `aarch64-apple-ios-sim` to Tier 2)
- #87770 (permit drop impls with generic constants in where clauses)
- #87780 (alloc: Use intra doc links for the reserve function)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
permit drop impls with generic constants in where clauses
Fixes#79248
`==` is not sufficient to check for equality between unevaluated consts which causes the above issue because the const in `[(); N - 1]:` on the impl and the const in `[(); N - 1]:` on the struct def are not seen as equal. Any predicate that can contain an unevaluated const cant use `==` here as it will cause us to incorrectly emit an error.
I dont know much about chalk but it seems like we ought to be relating the `TypeWellFormedFromEnv` instead of `==` as it contains a `Ty` so I added that too...
r? ``````@lcnr``````
Promote `aarch64-apple-ios-sim` to Tier 2
As per https://github.com/rust-lang/compiler-team/issues/428 this target becomes Tier 2.
---
I tested that the latest nightly has the target and I'm already building my project with that on CI and locally.
Validate FFI-safety warnings on naked functions
Test that FFI-safety warnings don't get accidentally dropped on naked
functions. The big picture is that if you implement a naked function
with the Rust ABI you'll get a warning. Further, if you implement a
naked function with a standardized ABI, but use non-FFI-safe types you
will still get a warning.
rust-lang/rfcs#2774rust-lang/rfcs#2972
cc ``````@joshtriplett`````` ``````@Amanieu`````` ``````@haraldh``````
explicit_generic_args_with_impl_trait: fix min expected number of generics
Fixes#87718
The problem was that `synth_type_param_count` was already subtracted from `named_type_param_count`, so this ended up being subtracted again. This caused `expected_min` to overflow, and ultimately resulting in weird and wrong behaviour.
I've also added another test not present in the original issue but caused by the same bug.
Disable unused variable lint for naked functions
In most calling conventions, accessing function parameters may require
stack access. However, naked functions have no assembly prelude to set
up stack access. This is why naked functions may only contain a single
`asm!()` block. All parameter access is done inside the `asm!()` block,
so we cannot validate the liveness of the input parameters. Therefore,
we should disable the lint for naked functions.
rust-lang/rfcs#2774rust-lang/rfcs#2972
`@joshtriplett` `@Amanieu` `@haraldh`
bootstrap.py: use `git rev-list` for robustness
Use `git rev-list` instead of `git log` to be more robust against
UI changes in git. Also, use the full email address for bors,
because `--author` uses a substring match.
Based on #87513, but is separate because it's less minimal and may require additional manual testing.
~Open questions:~
* ~Should the `merge_base` search also use `--first-parent`?~
* ~Do we exclude non-merge commits from bors? There are a few, and I'm not sure what they have in common. Some of them look like squashes, and some look like they're in rollup branches.~
r? `@jyn514`
`@rustbot` label +A-rustbuild +C-cleanup
rustc: Fill out remaining parts of C-unwind ABI
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:
* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
unwind". This fixes a longstanding soundness issue where if you
`panic!()` in an `extern "C"` function defined in Rust that's actually
UB because the LLVM representation for the function has the `nounwind`
attribute, but then you unwind.
* Whether or not a function unwinds now mainly considers the ABI of the
function instead of first checking the panic strategy. This fixes a
miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
can still unwind.
* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
reimplemented. Previously this was done as a small tweak during MIR
generation, but this has been moved to a separate and dedicated MIR
pass. This new pass will, for appropriate functions and function
calls, insert a `cleanup` landing pad for any function call that may
unwind within a function that is itself not allowed to unwind. Note
that this subtly changes some behavior from before where previously on
an unwind which was caught-to-abort it would run active destructors in
the function, and now it simply immediately aborts the process.
* The `#[unwind]` attribute has been removed and all users in tests and
such are now using `C-unwind` and `#![feature(c_unwind)]`.
I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
In most calling conventions, accessing function parameters may require
stack access. However, naked functions have no assembly prelude to set
up stack access. This is why naked functions may only contain a single
`asm!()` block. All parameter access is done inside the `asm!()` block,
so we cannot validate the liveness of the input parameters. Therefore,
we should disable the lint for naked functions.
rust-lang/rfcs#2774rust-lang/rfcs#2972
This test proves that naked functions are treated the same as regular
functions regarding unused function parameters. We will change this
behavior in the next patch.
Remove unnecessary trailing whitespace from error messages
Some error messages currently contain unnecessary trailing whitespace. There are some legitimate reasons for having trailing whitespace in the output, such as for uniform indentation of possibly-empty input lines, but the whitespace I have addressed here occurs in a line used only for spacing, and I see no reason why that should have trailing whitespace (spacing lines inserted in other places also don't have trailing whitespace).
I have also removed a superfluous call to `buffer.putc()`, which has no effect because the same character is already placed there by `draw_col_separator()`.
Use `git diff --ignore-space-at-eol` to see my changes; otherwise the diff is quite large due to the whitespace removed from expected outputs in `src/test/ui/`.
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.
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)
Test dropping union fields more
Now that #87403 is merged, a few more tests can be added for reads/writes to dropping union fields.
r? ``@LeSeulArtichaut``
Rustdoc accessibility: use an icon for the [-]/[+] controls
This is a reopening of #87207 with improvement for the way of generating the `background-image` CSS property.
I quote from the original PR:
> This way, we can show the plus and minus buttons on screens, while voice
> control will read off actual words "Collapse" and "Expand" instead of reading
> "open brace minus close brace" and "open brace plus close brace".
Part of #87059
r? ``@notriddle``
Remove space after negative sign in Literal to_string
Negative proc macro literal tokens used to be printed with a space between the minus sign and the magnitude. That's because `impl ToString for Literal` used to convert the Literal into a TokenStream, which splits the minus sign into a separate Punct token.
```rust
Literal::isize_unsuffixed(-10).to_string() // "- 10"
```
This PR updates the ToString impl to directly use `rustc_ast::token::Lit`'s ToString, which matches the way Rust negative numbers are idiomatically written without a space.
```rust
Literal::isize_unsuffixed(-10).to_string() // "-10"
```
Yuki Okushi