LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
Insert alignment checks for pointer dereferences when debug assertions are enabled
Closes https://github.com/rust-lang/rust/issues/54915
- [x] Jake tells me this sounds like a place to use `MirPatch`, but I can't figure out how to insert a new basic block with a new terminator in the middle of an existing basic block, using `MirPatch`. (if nobody else backs up this point I'm checking this as "not actually a good idea" because the code looks pretty clean to me after rearranging it a bit)
- [x] Using `CastKind::PointerExposeAddress` is definitely wrong, we don't want to expose. Calling a function to get the pointer address seems quite excessive. ~I'll see if I can add a new `CastKind`.~ `CastKind::Transmute` to the rescue!
- [x] Implement a more helpful panic message like slice bounds checking.
r? `@oli-obk`
Closures always implement `FnOnce` in new solver
We should process `[closure]: FnOnce(Tys...) -> Ty` obligations *before* fallback and closure analysis. We can do this by taking advantage of the fact that `FnOnce` is always implemented by closures, even before we definitely know the closure kind.
Fixescompiler-errors/next-solver-hir-issues#15
r? ``@oli-obk`` (trying to spread the reviewer load for new trait solver prs, and this one is pretty self-contained, though feel free to reassign 😸)
Don't ICE on placeholder consts in deep reject
Since we canonicalize const params into placeholder consts, we need to be able to handle them during deep reject.
r? `@lcnr` (though maybe `@oli-obk` can look at this one too, if he wants 😸)
Fixescompiler-errors/next-solver-hir-issues#10
rustdoc: run more HIR validation to mirror rustc
# Explanation
While investigating these issues: https://github.com/rust-lang/rust/issues/107093, https://github.com/rust-lang/rust/issues/106079
I thought it maybe would be useful to test running `rustdoc` on all rust files under `tests/ui` grepping for files that causes any ICEs.
And these are the files I found would cause ICEs.
```
// These are handled by this fix.
tests/ui/late-bound-lifetimes/mismatched_arg_count.rs
tests/ui/associated-consts/issue-102335-const.rs
tests/ui/const-generics/generic_const_exprs/issue-102768.rs
tests/ui/const-generics/const-arg-type-arg-misordered.rs
tests/ui/generic-associated-types/parse/trait-path-type-error-once-implemented.rs
tests/ui/typeck/issue-88643.rs
tests/ui/typeck/issue-75889.rs
tests/ui/typeck/issue-83621-placeholder-static-in-extern.rs
// These are not they will still produce a ICE after this change
tests/ui/limits/issue-56762.rs
tests/ui/union/projection-as-union-type-error-2.rs
tests/ui/union/projection-as-union-type-error.rs
```
I reduces the issues handled by this PR down to the tests added in the PR. That includes the linked issues.
But the 3 files that are not handled I will leave for a future PR.
This PR adds the `type_collecting` step from `hir_analysis::check_crate` to the rustdoc typechecks.
It had the following comment on it.
```
// this ensures that later parts of type checking can assume that items
// have valid types and not error
```
Adding the check report the same errors as rustc does for these input.
And not ICE when the lint checker walks the HIR or when in the `rustdoc::clean` pass.
This PR updates the expected errors of some existing rustdoc-ui tests (some now report less errors).
These new reported errors does mirror the errors reported by rustc.
# Performance
It does more checking so it will probably regress. We should run ``@bors` try `@rust-timer` queue` and see.
# Discussion
Maybe instead of calling a subset of the checks in `hir_analysis::check_crate` and having comments that say they should be kept in sync. We could instead call `check_crate` directly and pass in some flag. Maybe `check_toplevel_signatures_only` or something like that. That flag would have to skip most of the checks in that function tough.
Rollup of 7 pull requests
Successful merges:
- #106985 (Enhanced doucmentation of binary search methods for `slice` and `VecDeque` for unsorted instances)
- #109509 (compiletest: Don't allow tests with overlapping prefix names)
- #109719 (RELEASES: Add "Only support Android NDK 25 or newer" to 1.68.0)
- #109748 (Don't ICE on `DiscriminantKind` projection in new solver)
- #109749 (Canonicalize float var as float in new solver)
- #109761 (Drop binutils on powerpc-unknown-freebsd)
- #109766 (Fix title for openharmony.md)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Canonicalize float var as float in new solver
Typo in new canonicalizer -- we should be canonicalizing float vars as `CanonicalTyVarKind::Float`, not `CanonicalTyVarKind::Int`.
Fixescompiler-errors/next-solver-hir-issues#9
Don't ICE on `DiscriminantKind` projection in new solver
As title says, since we now actually call `Ty::discriminant_kind` on placeholder types 😃
Also drive-by simplify `Pointee::Metadata` projection logic, and fix the UI test because the `<T as Pointee>::Metadata` tests weren't actually exercising the new projection logic, since we still eagerly normalize (which hits `project.rs` in the old solver) in HIR typeck.
r? `@lcnr` tho feel free to re-roll, this pr is very low-priority and not super specific to the new trait solver.
Fixescompiler-errors/next-solver-hir-issues#14
compiletest: Don't allow tests with overlapping prefix names
Some tests will delete their output directory before starting. The output directory is based on the test names. If one test is the prefix of another test, then when that test starts, it could try to delete the output directory of the other test with the longer path, or otherwise clash with it while the two tests are trying to create/delete/modify the same directory.
In practice, this manifested as a random error on macOS where two tests were trying to create/delete/create `rustdoc/primitive` and `rustdoc/primitive/no_std`, which resulted in an EINVAL (InvalidInput) error.
This renames some of the offending tests, adds `compiletest-ignore-dir` to prevent compiletest from processing some files, and adds a check to prevent this from happening in the future.
Fixes#109397
Partial stabilization of `once_cell`
This PR aims to stabilize a portion of the `once_cell` feature:
- `core::cell::OnceCell`
- `std::cell::OnceCell` (re-export of the above)
- `std::sync::OnceLock`
This will leave `LazyCell` and `LazyLock` unstabilized, which have been moved to the `lazy_cell` feature flag.
Tracking issue: https://github.com/rust-lang/rust/issues/74465 (does not fully close, but it may make sense to move to a new issue)
Future steps for separate PRs:
- ~~Add `#[inline]` to many methods~~ #105651
- Update cranelift usage of the `once_cell` crate
- Update rust-analyzer usage of the `once_cell` crate
- Update error messages discussing once_cell
## To be stabilized API summary
```rust
// core::cell (in core/cell/once.rs)
pub struct OnceCell<T> { .. }
impl<T> OnceCell<T> {
pub const fn new() -> OnceCell<T>;
pub fn get(&self) -> Option<&T>;
pub fn get_mut(&mut self) -> Option<&mut T>;
pub fn set(&self, value: T) -> Result<(), T>;
pub fn get_or_init<F>(&self, f: F) -> &T where F: FnOnce() -> T;
pub fn into_inner(self) -> Option<T>;
pub fn take(&mut self) -> Option<T>;
}
impl<T: Clone> Clone for OnceCell<T>;
impl<T: Debug> Debug for OnceCell<T>
impl<T> Default for OnceCell<T>;
impl<T> From<T> for OnceCell<T>;
impl<T: PartialEq> PartialEq for OnceCell<T>;
impl<T: Eq> Eq for OnceCell<T>;
```
```rust
// std::sync (in std/sync/once_lock.rs)
impl<T> OnceLock<T> {
pub const fn new() -> OnceLock<T>;
pub fn get(&self) -> Option<&T>;
pub fn get_mut(&mut self) -> Option<&mut T>;
pub fn set(&self, value: T) -> Result<(), T>;
pub fn get_or_init<F>(&self, f: F) -> &T where F: FnOnce() -> T;
pub fn into_inner(self) -> Option<T>;
pub fn take(&mut self) -> Option<T>;
}
impl<T: Clone> Clone for OnceLock<T>;
impl<T: Debug> Debug for OnceLock<T>;
impl<T> Default for OnceLock<T>;
impl<#[may_dangle] T> Drop for OnceLock<T>;
impl<T> From<T> for OnceLock<T>;
impl<T: PartialEq> PartialEq for OnceLock<T>
impl<T: Eq> Eq for OnceLock<T>;
impl<T: RefUnwindSafe + UnwindSafe> RefUnwindSafe for OnceLock<T>;
unsafe impl<T: Send> Send for OnceLock<T>;
unsafe impl<T: Sync + Send> Sync for OnceLock<T>;
impl<T: UnwindSafe> UnwindSafe for OnceLock<T>;
```
No longer planned as part of this PR, and moved to the `rust_cell_try` feature gate:
```rust
impl<T> OnceCell<T> {
pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E> where F: FnOnce() -> Result<T, E>;
}
impl<T> OnceLock<T> {
pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E> where F: FnOnce() -> Result<T, E>;
}
```
I am new to this process so would appreciate mentorship wherever needed.
Give return-position impl traits in trait a (synthetic) name to avoid name collisions with new lowering strategy
The only needed commit from this PR is the last one.
r? `@compiler-errors`
Needs #109455.
rustdoc: Don't strip crate module
Until we decide something for https://github.com/rust-lang/rust/issues/109695, rustdoc won't crash anymore because the crate folder doesn't exist.
r? `@notriddle`
Lint against escape sequences in Fluent files
Fixes#109686 by checking for `\n`, `\"` and `\'` in Fluent files. It might be useful to have a way to opt out of this check, but all messages with violations currently do seem to be incorrect.
Do not consider elaborated projection predicates for objects in new solver
Object types have projection bounds which are elaborated during astconv. There's no need to do it again for projection goals, since that'll give us duplicate projection candidatesd that are distinct up to regions due to the fact that we canonicalize every region to a separate variable. See quick example below the break for a better explanation.
Discussed this with lcnr, and adding a stop-gap until we get something like intersection region constraints (or modify canonicalization to canonicalize identical regions to the same canonical regions) -- after which, this will hopefully not matter and may be removed.
r? `@lcnr`
---
See `tests/ui/traits/new-solver/more-object-bound.rs`:
Consider a goal: `<dyn Iter<'a, ()> as Iterator>::Item = &'a ()`.
After canonicalization: `<dyn Iter<'!0r, (), Item = '!1r ()> as Iterator>::Item == &!'2r ()`
* First object candidate comes from the item bound in the dyn's bounds itself, giving us `<dyn Iter<'!0r, (), Item = '?!r ()> as Iterator>::Item == &!'1r ()`. This gives us one region constraint: `!'1r == !'2r`.
* Second object candidate comes from elaborating the principal trait ref, gives us `<dyn Iter<'!0r, (), Item = '!1r ()> as Iterator>::Item == &!'0r ()`. This gives us one region constraint: `!'0r == !'2r`.
* Oops! Ambiguity!
Support TLS access into dylibs on Windows
This allows access to `#[thread_local]` in upstream dylibs on Windows by introducing a MIR shim to return the address of the thread local. Accesses that go into an upstream dylib will call the MIR shim to get the address of it.
`convert_tls_rvalues` is introduced in `rustc_codegen_ssa` which rewrites MIR TLS accesses to dummy calls which are replaced with calls to the MIR shims when the dummy calls are lowered to backend calls.
A new `dll_tls_export` target option enables this behavior with a `false` value which is set for Windows platforms.
This fixes https://github.com/rust-lang/rust/issues/84933.
Make init mask lazy for fully initialized/uninitialized const allocations
There are a few optimization opportunities in the `InitMask` and related const `Allocation`s (e.g. by taking advantage of the fact that it's a bitset that represents initialization, which is often entirely initialized or uninitialized in a single call, or gradually built up, etc).
There's a few overwrites to the same state, multiple writes in a row to the same indices, the RLE scheme for `memcpy` doesn't always compress, etc.
Here, we start with:
- avoiding materializing the bitset's blocks if the allocation is fully initialized/uninitialized
- dealloc blocks when fully overwriting, including when participating in `memcpy`s
- take care of the fixme about allocating blocks of 0s before overwriting them to the expected value
- expanding unit test coverage of the init mask
This should be most visible on benchmarks and crates where const allocations dominate the runtime (like `ctfe-stress-5` of course), but I was especially looking at the worst cases from #93215.
This first change allows the majority of `set_range` calls to stay with a lazy init mask when bootstrapping rustc (not that the init mask is a big part of the process in cpu time or memory usage).
r? `@oli-obk`
I have another in-progress branch where I'll switch the singular initialized/uninitialized value to a watermark, recording the point after which everything is uninitialized. That will take care of cases where full initialization is monotonic and done in multiple steps (e.g. an array of a type without padding), which should then allow the vast majority of const allocations' init masks to stay lazy during bootstrapping (though interestingly I've seen such gradual initialization in both left-to-right and right-to-left directions, and I don't think a single watermark can handle both).
Check for overflow in `assemble_candidates_after_normalizing_self_ty`
Prevents a stack overflow (⚠️❗) in the new solver when we have param-env candidates that look like: `T: Trait<Assoc = <T as Trait>::Assoc>`
The current error message looks bad, but that's because we don't distinguish overflow and other ambiguity errors. I'll break that out into a separate PR since the fix may be controversial.
r? `@lcnr`
Use span of placeholders in format_args!() expansion.
`format_args!("{}", x)` expands to something that contains `Argument::new_display(&x)`. That entire expression was generated with the span of `x`.
After this PR, `&x` uses the span of `x`, but the `new_display` call uses the span of the `{}` placeholder within the format string. If an implicitly captured argument was used like in `format_args!("{x}")`, both use the span of the `{x}` placeholder.
This fixes https://github.com/rust-lang/rust/issues/109576, and also allows for more improvements to similar diagnostics in the future, since the usage of `x` can now be traced to the exact `{}` placeholder that required it to be `Display` (or `Debug` etc.)
rustdoc: Unsupport importing `doc(primitive)` and `doc(keyword)` modules
These are internal features used for a specific purpose, and modules without imports are enough for that purpose.
rustdoc + rustdoc-json support for `feature(non_lifetime_binders)`
Makes `for<T> T: Trait` and `for<const N: usize> ..` in where clause operate correctly.
Fixes#108158
Rollup of 6 pull requests
Successful merges:
- #109149 (Improve error message when writer is forgotten in write and writeln macro)
- #109367 (Streamline fast rejection)
- #109548 (AnnotationColumn struct to fix hard tab column numbers in errors)
- #109694 (do not panic on failure to acquire jobserver token)
- #109705 (new solver: check for intercrate mode when accessing the cache)
- #109708 (Specialization involving RPITITs is broken so ignore the diagnostic differences)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Specialization involving RPITITs is broken so ignore the diagnostic differences
Just bless the corresponding test for `-Zlower-impl-trait-in-trait-to-assoc-ty`
r? `@compiler-errors`
do not panic on failure to acquire jobserver token
Purpose: remove `panic`.
Rust fails to acquire token if an error in build system occurs - environment variable contains incorrect `jobserver-auth`. It isn't ice so compiler shouldn't panic on such error.
Related issue: #46981
Scott McMurray