Emit dropck normalization errors in borrowck
Borrowck generally assumes that any queries it runs for type checking will succeed, thinking that HIR typeck will have errored first if there was a problem. However as of #98641, dropck isn't run on HIR, so there's no direct guarantee that it doesn't error. While a type being well-formed might be expected to ensure that its fields are well-formed, this is not the case for types containing a type projection:
```rust
pub trait AuthUser {
type Id;
}
pub trait AuthnBackend {
type User: AuthUser;
}
pub struct AuthSession<Backend: AuthnBackend> {
data: Option<<<Backend as AuthnBackend>::User as AuthUser>::Id>,
}
pub trait Authz: Sized {
type AuthnBackend: AuthnBackend<User = Self>;
}
pub fn run_query<User: Authz>(auth: AuthSession<User::AuthnBackend>) {}
// ^ No User: AuthUser bound is required or inferred.
```
While improvements to trait solving might fix this in the future, for now we go for a pragmatic solution of emitting an error from borrowck (by rerunning dropck outside of a query) and making drop elaboration check if an error has been emitted previously before panicking for a failed normalization.
Closes#103899Closes#135039
r? `@compiler-errors` (feel free to re-assign)
improve cold_path()
#120370 added a new instrinsic `cold_path()` and used it to fix `likely` and `unlikely`
However, in order to limit scope, the information about cold code paths is only used in 2-target switch instructions. This is sufficient for `likely` and `unlikely`, but limits usefulness of `cold_path` for idiomatic rust. For example, code like this:
```
if let Some(x) = y { ... }
```
may generate 3-target switch:
```
switch y.discriminator:
0 => true branch
1 = > false branch
_ => unreachable
```
and therefore marking a branch as cold will have no effect.
This PR improves `cold_path()` to work with arbitrary switch instructions.
Note that for 2-target switches, we can use `llvm.expect`, but for multiple targets we need to manually emit branch weights. I checked Clang and it also emits weights in this situation. The Clang's weight calculation is more complex that this PR, which I believe is mainly because `switch` in `C/C++` can have multiple cases going to the same target.
Move methods from `Map` to `TyCtxt`, part 2.
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already have a `par_` or `try_par_` prefix I added the `hir_` after that.
r? Zalathar
Allow configuring jemalloc per target
In Ferrocene we're trying to switch from `./configure` to a predefined `config.toml` file. One of the limitations of doing that is the `rust.jemalloc` configuration option, which we need to conditionally disable based on the target. This PR adds a `target.$tuple.jemalloc` option to override `rust.jemalloc` to make that possible.
CI: rfl: move job forward to Linux v6.14-rc3
Linux v6.14-rc3 contains commit 6273a058383e ("x86: rust: set rustc-abi=x86-softfloat on rustc>=1.86.0"), which resolves the error from https://github.com/rust-lang/rust/pull/136146.
r? `@lqd` `@Kobzol`
try-job: x86_64-rust-for-linux
`@rustbot` label A-rust-for-linux
`@bors` try
Use `tell` for `<File as Seek>::stream_position`
Some platforms have a more efficient way to get the current offset of the file than by seeking. For example, Wasi has `fd_tell` and SOLID has `SOLID_FS_Ftell`. Implement `<File as Seek>::stream_position()` in terms of those.
I do not use any APIs that were not already used in `std`. Although, the `libc` crate has [`ftell`](https://docs.rs/libc/latest/libc/fn.ftell.html), [`ftello`](https://docs.rs/libc/latest/libc/fn.ftello.html), and [`ftello64`](https://docs.rs/libc/latest/libc/fn.ftello64.html), I do not know platform coverage. It appears that Windows has no `tell`-like API.
I have checked that it builds on each relevant platform.
boostrap: skip no_std targets in Std doc step
This fixes a bug that currently prevents us from adding no_std library targets to rustc in nixpkgs (https://github.com/NixOS/nixpkgs/pull/382166).
When running `./x.py doc`, the `Std` doc step generally fails for no_std targets, logs: https://gist.github.com/niklaskorz/fb83f9503ce19b75e8b1af02cdebd592
Skipping no_std targets in this step will allow using no_std targets such as `bpfel-unknown-none` together with other targets in the same config without blocking the doc generator for them, e.g.
```
./configure --release-channel=stable --tools=rustc,rustdoc,rust-analyzer-proc-macro-srv --build=aarch64-apple-darwin --host=aarch64-apple-darwin --target=aarch64-apple-darwin,bpfel-unknown-none
./x.py doc
```
Logs with this fix applied: https://gist.github.com/niklaskorz/cdd50aaea33ede579f737434286d800b
Pass vendored sources from bootstrap to generate-copyright
In addition to doing the vendoring in bootstrap, this PR also loads the list of manifests to parse from bootstrap (instead of hardcoding a smaller list in generate-copyright). This is best reviewed commit-by-commit.
Fixes https://github.com/rust-lang/rust/issues/136955
Rollup of 7 pull requests
Successful merges:
- #137095 (Replace some u64 hashes with Hash64)
- #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses)
- #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.)
- #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows)
- #137125 (Re-add missing empty lines in the releases notes)
- #137145 (use add-core-stubs / minicore for a few more tests)
- #137149 (Remove SSE ABI from i586-pc-windows-msvc)
r? `@ghost`
`@rustbot` modify labels: rollup
I was wrong on #19127, I thought hir-def resolver is enough for them, but it turns out not because of paths like `<Enum>::Variant` and `Type::AssocThatIsEnum::Variant`.
Remove SSE ABI from i586-pc-windows-msvc
As an i586 target, it should not have SSE. This caused the following warning to be emitted:
```
warning: target feature `sse2` must be enabled to ensure that the ABI of the current target can be implemented correctly
|
= note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
warning: 1 warning emitted
```
see #116344.
r? RalfJung
use add-core-stubs / minicore for a few more tests
See https://github.com/rust-lang/rust/issues/131485 for context. These are some tests I worked on in the past so I figured I'd see if `minicore` works for them. :)
Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows
The problem with the error message on Windows is:
- The path separators are different
- The OS error message string is different
Normalizing those two things makes the test pass on Windows.
Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.
Fixes#136046
`feature(deref_patterns)` tracking issue: https://github.com/rust-lang/rust/issues/87121
`Cow<'_, T>` should only implement `DerefPure` if its `Deref` impl is pure, which requires `<T::Owned as Borrow<T>>::borrow` to be pure. This PR restricts `impl DerefPure for Cow<'_, T>` to `T: Sized + Clone`, `T = [U: Clone]`, and `T = str` (for all of whom `<T::Owned as Borrow<T>>::borrow` is implemented in the stdlib and is pure).
cc ``@Nadrieril``
------
An alternate approach would be to introduce a new `unsafe trait BorrowPure<T>` analogous to `DerefPure` that could be implemented for `T: Sized`, `&T`, `&mut T`, `String`, `Vec`, `Box`, `PathBuf`, `OsString`, etc. https://github.com/rust-lang/rust/compare/master...zachs18:borrow-pure-trait
