Fix subslice capture in closure
Fixes#109298 by refining captures in the same way for Subslices and Indexes. The comment `// we never capture this` seems to have been inaccurate, as changing it to an assert causes many test failures
`@rustbot` label +A-closures
Move `doc(primitive)` future incompat warning to `invalid_doc_attributes`
Fixes#88070.
It's been a while since this was turned into a "future incompatible lint" so I think we can now turn it into a hard error without problem.
r? `@jyn514`
rustdoc: Fix invalid suggestions on ambiguous intra doc links v2
Fixes https://github.com/rust-lang/rust/issues/108653.
This is another approach to fixing the same issue. This time, we keep the computed information around instead of re-computing it.
Strangely enough, the order for ambiguities seem to have been changed. Not an issue but it creates a lot of diff...
So which version do you prefer?
r? `@notriddle`
Initial support for return type notation (RTN)
See: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/
1. Only supports `T: Trait<method(): Send>` style bounds, not `<T as Trait>::method(): Send`. Checking validity and injecting an implicit binder for all of the late-bound method generics is harder to do for the latter.
* I'd add this in a follow-up.
3. ~Doesn't support RTN in general type position, i.e. no `let x: <T as Trait>::method() = ...`~
* I don't think we actually want this.
5. Doesn't add syntax for "eliding" the function args -- i.e. for now, we write `method(): Send` instead of `method(..): Send`.
* May be a hazard if we try to add it in the future. I'll probably add it in a follow-up later, with a structured suggestion to change `method()` to `method(..)` once we add it.
7. ~I'm not in love with the feature gate name 😺~
* I renamed it to `return_type_notation` ✔️
Follow-up PRs will probably add support for `where T::method(): Send` bounds. I'm not sure if we ever want to support return-type-notation in arbitrary type positions. I may also make the bounds require `..` in the args list later.
r? `@ghost`
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.
