Unify terminology used in unwind action and terminator, and reflect
the fact that a nounwind panic is triggered instead of an immediate
abort is triggered for this terminator.
Rollup of 7 pull requests
Successful merges:
- #109909 (Deny `use`ing tool paths)
- #109921 (Don't ICE when encountering `dyn*` in statics or consts)
- #109922 (Disable `has_thread_local` on OpenHarmony)
- #109926 (write threads info into log only when debugging)
- #109968 (Add regression test for #80409)
- #109969 (Add regression test for #86351)
- #109973 (rustdoc: Improve logo display very small screen)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
write threads info into log only when debugging
The current tracing log will unconditionally write thread information during parallel compilation, which sometimes confuses some normal output log information
This fixes the UI test failure of:
```
[ui] tests/ui/consts/const_in_pattern/issue-73431.rs
```
Updates #75760
Disable `has_thread_local` on OpenHarmony
OpenHarmony uses emulated TLS, which doesn't link properly when using thread-local variables across crate boundaries with `-C prefer-dynamic`. This PR makes thread_local! use pthreads directly instead.
Don't ICE when encountering `dyn*` in statics or consts
Since we have properly implemented `dyn*` support in CTFE (#107728), let's not ICE here anymore.
Fixes#105777
r? `@eholk`
Use SipHash-1-3 instead of SipHash-2-4 for StableHasher
Noticed this, and it seems easy and likely a perf win. IIUC we don't need DDOS resistance (just collision) so we ideally would have an even faster hash, but it's hard to beat this SipHash impl here, since it's been so highly tuned for the interface.
It wouldn't surprise me if there's some subtle reason changing this sucks, as it's so obvious it seems likely to have been done. Still, SipHash-1-3 seems to still have the guarantees StableHasher should need (and seemingly more), and is clearly less work. So it's worth a shot.
Not fully tested locally.
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons
This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them.
Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene.
The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days.
r? `@ehuss`
Turns out
- `owning_ref` is unsound due to `Box` aliasing stuff
- `rustc` doesn't need 99% of the `owning_ref` API
- `rustc` can use a far simpler abstraction that is `OwnedSlice`
Tweak debug outputs to make debugging new solver easier
1. Move the fields that are "most important" (I know this is subjective) to the beginning of the structs.
For goals, I typically care more about the predicate than the param-env (which is significantly longer in debug output).
For canonicalized things, I typically care more about what is *being* canonicalized.
For a canonical response, I typically care about the response -- or at least, it's typically useful to put it first since it's short and affects the whether the solver recurses or not...
2. Add some more debug and instrument calls to functions to add more structure to tracing lines.
r? `@oli-obk` or `@BoxyUwU` (since I think `@lcnr` is on holiday)
Avoid a few locks
We can use atomics or datastructures tuned for specific access patterns instead of locks. This may be an improvement for parallel rustc, but it's mostly a cleanup making various datastructures only usable in the way they are used right now (append data, never mutate), instead of having a general purpose lock.
Disable path trimming during graphviz output
Fixes#109943
We can end up pretty-printing a path for the graphviz file without emitting a diagnostic, so disable path trimming at this point.
Allow `transmute`s to produce `OperandValue`s instead of needing `alloca`s
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.
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.
Do not suppress temporary_cstring_as_ptr in macros.
There isn't really a reason to skip the lint when part of the expression comes from an expansion.
Fixes https://github.com/rust-lang/rust/issues/94694
Move a const-prop-lint specific hack from mir interpret to const-prop-lint and make it fallible
fixes#109743
This hack didn't need to live in the mir interpreter. For const-prop-lint it is entirely correct to avoid doing any const prop if normalization fails at this stage. Most likely we couldn't const propagate anything anyway, and if revealing was needed (so opaque types were involved), we wouldn't want to be too smart and leak the hidden type anyway.
Emit feature error for parenthesized generics in associated type bounds
We don't actually do AST->HIR lowering with some `-Zunpretty` flags, so it's not correct to just delay a bug instead of emitting a feature error.
Some diagnostics regressed because of the new errors, but oh well. 🤷Fixes#109898
Fix `non_exhaustive_omitted_patterns` lint span
Fixes#109837
`DUMMY_SP` was being passed as the span in many cases where we have a span available to use. This meant that the location of the violating pattern wasn't shown, or the list of un-covered variants
r? `@Nilstrieb`
Pull some tuple variant fields out into their own struct
This is groundwork for adding more fields to those new structs, but I believe the change to be useful on its own.
r? `@Nilstrieb` but feel free to reroll for `compiler`
Remove `intercrate` and `mark_ambiguous` from `TypeRelation`
Fixes#109863
Pulls this logic into `super_combine_tys`, which has access to `InferCtxt` and takes a `ObligationEmittingRelation` -- both of which simplify the logic here.
r? `@oli-obk` `@aliemjay`
Previously if the expression contained generic consts and did not have a directly equivalent
type, transmuting the type in this way was forbidden, despite the two sizes being identical.
Instead, we should be able to lazily tell if the two consts are identical, and if so allow them
to be transmuted.
OpenHarmony uses emulated TLS, which doesn't link properly when using
thread-local variables across crate boundaries with `-C prefer-dynamic`.
This PR makes thread_local! use pthreads directly instead.
Never consider int and float vars for `FnPtr` candidates
This solves a regression where `0.0.cmp()` was ambiguous when a custom trait with a `cmp` method was in scope.
For integers it shouldn't be a problem in practice so I wasn't able to add a test.
I'm not sure whether there could be more issues hidden in the shadows as mentioned in the issue, but this should at least fix the problematic regression immediately.
fixes#109892
r? oli-obk
Use `&IndexSlice` instead of `&IndexVec` where possible
All the same reasons as for `[T]`: more general, less pointer chasing, and `&mut IndexSlice` emphasizes that it doesn't change *length*.
r? `@ghost`
This solves a regression where `0.0.cmp()` was ambiguous when a custom
trait with a `cmp` method was in scope.
FOr integers it shouldn't be a problem in practice so I wasn't able to
add a test.
Drop array patterns using subslices
Fixes#109004
Drops contiguous subslices of an array when moving elements out with a pattern, which improves perf for large arrays
r? `@compiler-errors`
Switch to LLD as default linker for {arm,thumb}v4t-none-eabi
The LLVM 16 update brought ARMv4t support to LLD. We should use it by default so users don't need to install an external linker.
cc `@Lokathor`
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`
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`
Something similar was previously removed as a part of #104602, but after this PR all table changes should also be "locally correct" after every update.
`-Cdebuginfo=1` was never line tables only and
can't be due to backwards compatibility issues.
This was clarified and an option for line tables only
was added. Additionally an option for line info
directives only was added, which is well needed for
some targets. The debug info options should now
behave the same as clang's debug info options.
Add `IndexSlice` to go with `IndexVec`
Moves the methods that don't need full `IndexVec`-ness over to `IndexSlice`, and have `IndexVec` deref to `IndexSlice` so everything keeps working.
Doing this for later use in https://github.com/rust-lang/compiler-team/issues/606, where I'm hitting a bunch of things that are just slices and thus there's no way to index with the `FieldIdx`.
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`
Rename `with_source_map` as `set_source_map`. Because `with` functions
(e.g. `with_session_globals`, `scoped_tls::ScopedKey::with`) are for
*getting* a value for the duration of a closure, and `set` functions
(e.g. `set_session_globals_then` `scoped_tls::ScopedKey::with`) are for
*setting* a value for the duration of a closure.
Also fix up the comment, which is wrong:
- The bit about `TyCtxt` is wrong.
- `span_debug1` doesn't exist any more.
- There's only one level of fallback, not two.
(This is effectively a follow-up to the changes in #93936.)
Also add a comment explaining that `SessionGlobals::source_map` should
only be used when absolutely necessary.
Update `ty::VariantDef` to use `IndexVec<FieldIdx, FieldDef>`
And while doing the updates for that, also uses `FieldIdx` in `ProjectionKind::Field` and `TypeckResults::field_indices`.
There's more places that could use it (like `rustc_const_eval` and `LayoutS`), but I tried to keep this PR from exploding to *even more* places.
Part 2/? of https://github.com/rust-lang/compiler-team/issues/606
numeric vars can only be unified with numerical types in deep reject
Don't consider numeric vars (int and float vars) to unify with non-numeric types during deep reject. This helps us reject incompatible impls sooner.
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 😸)
Freshen normalizes-to hack goal RHS in the evaluate loop
Ensure that we repeatedly equate the unconstrained RHS of the normalizes-to hack goal with the *actual* RHS of the goal, even if the normalizes-to goal loops several times and thus we replace the unconstrained RHS var repeatedly.
Alternative to #109583.
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
And while doing the updates for that, also uses `FieldIdx` in `ProjectionKind::Field` and `TypeckResults::field_indices`.
There's more places that could use it (like `rustc_const_eval` and `LayoutS`), but I tried to keep this PR from exploding to *even more* places.
Part 2/? of https://github.com/rust-lang/compiler-team/issues/606
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
Also, `MTRef<'a, T>` is a typedef for a reference to a `T`, but in
practice it's only used (and useful) in combination with `MTLock`, i.e.
`MTRef<'a, MTLock<T>>`. So this commit changes it to be a typedef for a
reference to an `MTLock<T>`, and renames it as `MTLockRef`. I think this
clarifies things, because I found `MTRef` quite puzzling at first.
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.
Move `mir::Field` → `abi::FieldIdx`
The first PR for https://github.com/rust-lang/compiler-team/issues/606
This is just the move-and-rename, because it's plenty big already. Future PRs will start using `FieldIdx` more broadly, and concomitantly removing `FieldIdx::new`s.
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).
Rename `IndexVec::last` → `last_index`
As I've been trying to replace a `Vec` with an `IndexVec`, having `last` exist on both but returning very different types makes the transition a bit awkward -- the errors are later, where you get things like "there's no `ty` method on `mir::Field`" rather than a more localized error like "hey, there's no `last` on `IndexVec`".
So I propose renaming `last` to `last_index` to help distinguish `Vec::last`, which returns an element, and `IndexVec::last_index`, which returns an index.
(Similarly, `Iterator::last` also returns an element, not an index.)
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.)
As I've been trying to replace a `Vec` with an `IndexVec`, having `last` exist on both but returning very different types makes the transition a bit awkward -- the errors are later, where you get things like "there's no `ty` method on `mir::Field`" rather than a more localized error like "hey, there's no `last` on `IndexVec`".
So I propose renaming `last` to `last_index` to help distinguish `Vec::last`, which returns an element, and `IndexVec::last_index`, which returns an index.
(Similarly, `Iterator::last` also returns an element, not an index.)
The first PR for https://github.com/rust-lang/compiler-team/issues/606
This is just the move-and-rename, because it's plenty big-and-bitrotty already. Future PRs will start using `FieldIdx` more broadly, and concomitantly removing `FieldIdx::new`s.
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
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
Improve error message when writer is forgotten in write and writeln macro
Modified write! macro error message when writer is forgotten as in issue #108713Fixes#108713
r? ``@WaffleLapkin``
Thanks to the combination of #108246 and #108442 it could already remove identity transmutes.
With this PR, it can also simplify them to `IntToInt` casts, `Discriminant` reads, or `Field` projections.
Rollup of 8 pull requests
Successful merges:
- #91793 (socket ancillary data implementation for FreeBSD (from 13 and above).)
- #92284 (Change advance(_back)_by to return the remainder instead of the number of processed elements)
- #102472 (stop special-casing `'static` in evaluation)
- #108480 (Use Rayon's TLV directly)
- #109321 (Erase impl regions when checking for impossible to eagerly monomorphize items)
- #109470 (Correctly substitute GAT's type used in `normalize_param_env` in `check_type_bounds`)
- #109562 (Update ar_archive_writer to 0.1.3)
- #109629 (remove obsolete `givens` from regionck)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add a builtin `FnPtr` trait that is implemented for all function pointers
r? `@ghost`
Rebased version of https://github.com/rust-lang/rust/pull/99531 (plus adjustments mentioned in the PR).
If perf is happy with this version, I would like to land it, even if the diagnostics fix in 9df8e1befb5031a5bf9d8dfe25170620642d3c59 only works for `FnPtr` specifically, and does not generally improve blanket impls.
Update ar_archive_writer to 0.1.3
This updates object to 0.30 and fixes a bug where the symbol table would be omitted for archives where there are object files yet none that export any symbol. This bug could lead to linker errors for crates like rustc_std_workspace_core which don't contain any code of their own but exist solely for their dependencies. This is likely the cause of the linker issues I was experiencing on Webassembly. It has been shown to cause issues on other platforms too.
cc rust-lang/ar_archive_writer#5
Correctly substitute GAT's type used in `normalize_param_env` in `check_type_bounds`
Given:
```rust
trait Foo {
type Assoc<T>: PartialEq<Self::Assoc<i32>>;
}
impl Foo for () {
type Assoc<T> = Wrapper<T>;
}
struct Wrapper<T>(T);
impl<T> PartialEq<Wrapper<i32>> for Wrapper<T> { }
```
We add an additional predicate in the `normalize_param_env` in `check_type_bounds` that is used to normalize the GAT's bounds to check them in the impl. Problematically, though, that predicate is constructed to be `for<^0> <() as Foo>::Assoc<^0> => Wrapper<T>`, instead of `for<^0> <() as Foo>::Assoc<^0> => Wrapper<^0>`.
That means `Self::Assoc<i32>` in the bounds that we're checking normalizes to `Wrapper<T>`, instead of `Wrapper<i32>`, and so the bound `Self::Assoc<T>: PartialEq<Self::Assoc<i32>>` normalizes to `Wrapper<T>: PartialEq<Wrapper<T>>`, which does not hold.
Fixes this by properly substituting the RHS of that normalizes predicate that we add to the `normalize_param_env`. That means the bound is properly normalized to `Wrapper<T>: PartialEq<Wrapper<i32>>`, which *does* hold.
---
The second commit in this PR just cleans up some substs stuff and some naming.
r? `@jackh726` cc #87900
Erase impl regions when checking for impossible to eagerly monomorphize items
We were inserting `ReErased` for method substs, but not for impl substs, leading to the call for `subst_and_check_impossible_predicates` being a bit weaker than it should be (since it ignores predicates that need substitution -- incl early-bound regions).
Fixes#109297
Use Rayon's TLV directly
This accesses Rayon's `TLV` thread local directly avoiding wrapper functions. This makes rustc work with https://github.com/rust-lang/rustc-rayon/pull/10.
r? `@cuviper`
stop special-casing `'static` in evaluation
fixes#102360
I have no idea whether this actually removed all places where `'static` matters. Without canonicalization it's very easy to accidentally rely on `'static` again. Blocked on changing the `order_dependent_trait_objects` future-compat lint to a hard error
r? `@nikomatsakis`
Move const trait bounds checks to MIR constck
Fixes#109543. When checking paths in HIR typeck, we don't want to check for const predicates since all we want might just be a function pointer. Therefore we move this to MIR constck and check that bounds are met during MIR constck.
r? `@oli-obk`
Fixes#109543. When checking paths in HIR typeck, we don't want to check
for const predicates since all we want might just be a function pointer.
Therefore we move this to MIR constck and check that bounds are met
during MIR constck.
Make doc comment a little bit more accurate
It queries not LLVM in particular but the codegen backend *in general*. While cranelift does not provide target features, other codegen backends do.
Found while looking for [this answer](https://github.com/rust-lang/rust/issues/108680#issuecomment-1484324690).
Don't shadow the `dep_node` var in `incremental_verify_ich_failed`
It's better to debug print `DepNode` instead of `ErrorGuaranteed` one line below :^)
fixes#109676
Clarify the 'use a constant in a pattern' error message
```rs
use std::borrow::Cow;
const ERROR_CODE: Cow<'_, str> = Cow::Borrowed("23505");
fn main() {
let x = Cow::from("23505");
match x {
ERROR_CODE => {}
}
}
```
```
error: to use a constant of type `Cow` in a pattern, `Cow` must be annotated with `#[derive(PartialEq, Eq)]`
--> src/main.rs:9:9
|
9 | ERROR_CODE => {}
| ^^^^^^^^^^
error: could not compile `playground` due to previous error
```
It seems helpful to link to StructuralEq in this message. I was a little confused, because `Cow<'_, str>` implements PartialEq and Eq, but they're not derived, which I learned is necessary for structural equality and using constants in patterns (thanks to the Rust community Discord server)
For tests, should I update every occurrence of this message? I see tests where this is still a warning and I'm not sure if I should update those.
Don't skip all directories when tidy-checking
This fixes a regression from https://github.com/rust-lang/rust/pull/108772 which basically made it that tidy style checks only `README.md` and `COMPILER_TESTS.md`.
Remove the `NodeId` of `ast::ExprKind::Async`
This is a followup to https://github.com/rust-lang/rust/pull/104833#pullrequestreview-1314537416.
In my original attempt, I was using `LoweringContext::expr`, which was not correct as it creates a fresh `DefId`.
It now uses the correct `DefId` for the wrapping `Expr`, and also makes forwarding `#[track_caller]` attributes more explicit.
Avoid materializing bits in the InitMask bitset when a single value
would be enough: when the mask represents a fully initialized or fully
uninitialized const allocation.
Refactor: Separate `LocalRef` variant for not-evaluated-yet operands
As I was reading through this, I noticed that almost every place that was using this needed to distinguish between Some vs None in the match arm anyway, so thought that separating the cases at the variant level might be clearer instead.
I like how it ended up; let me know what you think!
Rollup of 8 pull requests
Successful merges:
- #97506 (Stabilize `nonnull_slice_from_raw_parts`)
- #98651 (Follow C-RW-VALUE in std::io::Cursor example)
- #102742 (Remove unnecessary raw pointer in __rust_start_panic arg)
- #109587 (Use an IndexVec to debug fingerprints.)
- #109613 (fix type suggestions in match arms)
- #109633 (Fix "Directly go to item in search if there is only one result" setting)
- #109635 (debuginfo: Get pointer size/align from tcx.data_layout instead of layout_of)
- #109641 (Don't elaborate non-obligations into obligations)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't elaborate non-obligations into obligations
It's suspicious to elaborate a `PolyTraitRef` or `Predicate` into an `Obligation`, since the former does not have a param-env associated with it, but the latter does. This is a footgun that, while not being misused *currently* in the compiler, easily could be misused by someone less familiar with the elaborator's inner workings.
This PR just changes the API -- ideally, the elaborator wouldn't even have to deal with obligations if we're not elaborating obligations, but that would require a bit more abstraction than I could be bothered with today.
debuginfo: Get pointer size/align from tcx.data_layout instead of layout_of
This avoids some type interning and a query execution. It also just makes the code simpler.
Cleanup `codegen_fn_attrs`
The `match` control flow construct has been stable since 1.0, we should use it here.
Sorry for the hard to review diff, I did try to at least split it into two commits. But looking at before-after side-by-side (instead of whatever github is doing) is probably the easiest way to make sure that I didn't forget about anything.
On top of #109088, you can wait for that
Refactor: `VariantIdx::from_u32(0)` -> `FIRST_VARIANT`
Since structs are always `VariantIdx(0)`, there's a bunch of files where the only reason they had `VariantIdx` or `vec::Idx` imported at all was to get the first variant.
So this uses a constant for that, and adds some doc-comments to `VariantIdx` while I'm there, since [it doesn't have any today](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_target/abi/struct.VariantIdx.html).
Still-further-specializable projections are ambiguous in new solver
Fixes https://github.com/rust-lang/rust/pull/108896/files#r1148450781
r? ``@BoxyUwU`` (though feel free to re-roll)
---
This can be used to create an unsound transmute function with the new solver:
```rust
#![feature(specialization)]
trait Default {
type Id;
fn intu(&self) -> &Self::Id;
}
impl<T> Default for T {
default type Id = T;
fn intu(&self) -> &Self::Id {
self
}
}
fn transmute<T: Default<Id = U>, U: Copy>(t: T) -> U {
*t.intu()
}
use std::num::NonZeroU8;
fn main() {
let s = transmute::<u8, Option<NonZeroU8>>(0);
assert_eq!(s, None);
}
```
Permit the MIR inliner to inline diverging functions
This heuristic prevents inlining of `hint::unreachable_unchecked`, which in turn makes `Option/Result::unwrap_unchecked` a bad inlining candidate. I looked through the changes to `core`, `alloc`, `std`, and `hashbrown` by hand and they all seem reasonable. Let's see how this looks in perf...
---
Based on rustc-perf it looks like this regresses ctfe-stress, and the cachegrind diff indicates that this regression is in `InterpCx::statement`. I don't know how to do any deeper analysis because that function is _enormous_ in the try toolchain, which has no debuginfo in it. And a local build produces significantly different codegen for that function, even with LTO.
Since structs are always `VariantIdx(0)`, there's a bunch of files where the only reason they had `VariantIdx` or `vec::Idx` imported at all was to get the first variant.
So this uses a constant for that, and adds some doc-comments to `VariantIdx` while I'm there, since it doesn't have any today.
Refactor `try_execute_query`
This merges `JobOwner::try_start` into `try_execute_query`, removing `TryGetJob` in the processes. 3 new functions are extracted from `try_execute_query`: `execute_job`, `cycle_error` and `wait_for_query`. This makes the control flow a bit clearer and improves performance.
Based on https://github.com/rust-lang/rust/pull/109046.
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.7134s</td><td align="right">1.7061s</td><td align="right"> -0.43%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2519s</td><td align="right">0.2510s</td><td align="right"> -0.35%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9517s</td><td align="right">0.9481s</td><td align="right"> -0.38%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.5389s</td><td align="right">1.5338s</td><td align="right"> -0.33%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">5.9488s</td><td align="right">5.9258s</td><td align="right"> -0.39%</td></tr><tr><td>Total</td><td align="right">10.4048s</td><td align="right">10.3647s</td><td align="right"> -0.38%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9962s</td><td align="right"> -0.38%</td></tr></table>
r? `@cjgillot`
Use poison instead of undef
In cases where it is legal, we should prefer poison values over undef values.
This replaces undef with poison for aggregate construction and for uninhabited types. There are more places where we can likely use poison, but I wanted to stay conservative to start with.
In particular the aggregate case is important for newer LLVM versions, which are not able to handle an undef base value during early optimization due to poison-propagation concerns.
r? `@cuviper`
This updates object to 0.30 and fixes a bug where the symbol table
would be omitted for archives where there are object files yet none
that export any symbol. This bug could lead to linker errors for crates
like rustc_std_workspace_core which don't contain any code of their own
but exist solely for their dependencies. This is likely the cause of
the linker issues I was experiencing on Webassembly. It has been shown
to cause issues on other platforms too.
cc rust-lang/ar_archive_writer#5
Make helper functions private in fn_ctxt/adjust_fulfillment_errors
Two helper functions in `rustc_hir_typeck/src/fn_ctxt/adjust_fulfillment_errors.rs` were previously made `pub` impl members, because they were also used in `rustc_hir_typeck/src/fn_ctxt/check.rs` (see #107746).
However, that's no longer the case, so the FIXME suggesting they be made private can now be implemented.
Implement non-const `Destruct` trait in new solver
Makes it so that we can call stdlib methods like `Option::map` in **non-const** environments, since *many* stdlib methods have `Destruct` bounds 😅
This doesn't bother to implement `const Destruct` yet, but it shouldn't be too hard to do so. Just didn't bother since we already don't have much support for const traits in the new solver anyways. I'd be happy to add skeleton support for `const Destruct`, though, if the reviewer desires.
Rollup of 9 pull requests
Successful merges:
- #108629 (rustdoc: add support for type filters in arguments and generics)
- #108924 (panic_immediate_abort requires abort as a panic strategy)
- #108961 (Refine error spans for const args in hir typeck)
- #108986 (sync LVI tests)
- #109142 (Add block-based mutex unlocking example)
- #109368 (fix typo in the creation of OpenOption for RustyHermit)
- #109493 (Return nested obligations from canonical response var unification)
- #109515 (Add AixLinker to support linking on AIX)
- #109536 (resolve: Rename some cstore methods to match queries and add comments)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
resolve: Rename some cstore methods to match queries and add comments
about costs associated with replacing them with query calls.
Supersedes https://github.com/rust-lang/rust/pull/108346.
r? `@cjgillot`
Return nested obligations from canonical response var unification
Handle alias-eq obligations being emitted from `instantiate_and_apply_query_response` in:
* `EvalCtxt` - by processing the nested obligations in the next loop by `new_goals`
* `FulfillCtxt` - by adding the nested obligations to the fulfillment's pending obligations
* `InferCtxt::evaluate_obligation` - ~~by returning `EvaluationResult::EvaluatedToAmbig` (boo 👎, see the FIXME)~~ same behavior as above, since we use fulfillment and `select_where_possible`
The only one that's truly sketchy is `evaluate_obligation`, but it's not hard to modify this behavior moving forward.
From #109037, I think a smaller repro could be crafted if I were smarter, but I am not, so I just took this from #105878.
r? `@lcnr` cc `@BoxyUwU`
Refine error spans for const args in hir typeck
Improve just a couple of error messages having to do with mismatched consts.
r? `@ghost` i'll put this up when the dependent commits are merged
Move useless_anynous_reexport lint into unused_imports
As mentioned in https://github.com/rust-lang/rust/pull/109003, this check should have been merged with `unused_imports` in the start.
r? `@petrochenkov`
Add `try_canonicalize` to `rustc_fs_util` and use it over `fs::canonicalize`
This adds `try_canonicalize` which tries to call `fs::canonicalize`, but falls back to `std::path::absolute` if it fails. Existing `canonicalize` calls are replaced with it. `fs::canonicalize` is not guaranteed to work on Windows.
Fix the ffi_unwind_calls lint documentation
This fixes the [`ffi_unwind_calls`](https://doc.rust-lang.org/nightly/rustc/lints/listing/allowed-by-default.html#ffi-unwind-calls) documentation to show its output correctly. Currently it is showing the text `{{produces}}` which is not how it should look.
This fixes it by not ignoring the example. I'm not sure why it was ignored, as the way the lint currently works it doesn't seem to require external linkage. This also fixes several mistakes in the example:
* There is no `ffi_unwind_calls` feature.
* Denies the lint (which is otherwise allow be default).
* Removes the `mod impl` which is not valid Rust syntax, and doesn't appear to be needed anyways.
The output now looks like:
```
warning: call to foreign function with FFI-unwind ABI
--> lint_example.rs:10:14
|
10 | unsafe { foo(); }
| ^^^^^ call to foreign function with FFI-unwind ABI
|
note: the lint level is defined here
--> lint_example.rs:2:9
|
2 | #![warn(ffi_unwind_calls)]
| ^^^^^^^^^^^^^^^^
warning: call to function pointer with FFI-unwind ABI
--> lint_example.rs:12:14
|
12 | unsafe { ptr(); }
| ^^^^^ call to function pointer with FFI-unwind ABI
```
This also includes some updates to the lint-docs tool to help with this issue:
* Adds a check if a lint documentation has `{{produces}}` with an ignored example, and generates an error.
* All instances of a lint are now displayed. Previously it only showed the first time the lint fires. Some examples may trigger a lint multiple times, and they are all now displayed.
Lint ambiguous glob re-exports
Attempts to fix#107563.
We currently already emit errors for ambiguous re-exports when two names are re-exported *specifically*, i.e. not from glob exports. This PR attempts to emit deny-by-default lints for ambiguous glob re-exports.
Add `-Z time-passes-format` to allow specifying a JSON output for `-Z time-passes`
This adds back the `-Z time` option as that is useful for [my rustc benchmark tool](https://github.com/Zoxc/rcb), reverting https://github.com/rust-lang/rust/pull/102725. It now uses nanoseconds and bytes as the units so it is renamed to `time-precise`.
rustc_interface: Add a new query `pre_configure`
It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early.
Crate-level cfg attributes on the crate itself are then expanded normally during the main expansion pass, like attributes on any other nodes.
This is a continuation of https://github.com/rust-lang/rust/pull/92473 and one more step to very unstable crate-level proc macro attributes maybe actually working.
Previously crate attributes were pre-configured simultaneously with feature extraction, and then written directly into `ast::Crate`.
Rollup of 7 pull requests
Successful merges:
- #108541 (Suppress `opaque_hidden_inferred_bound` for nested RPITs)
- #109137 (resolve: Querify most cstore access methods (subset 2))
- #109380 (add `known-bug` test for unsoundness issue)
- #109462 (Make alias-eq have a relation direction (and rename it to alias-relate))
- #109475 (Simpler checked shifts in MIR building)
- #109504 (Stabilize `arc_into_inner` and `rc_into_inner`.)
- #109506 (make param bound vars visibly bound vars with -Zverbose)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early.
Crate-level cfg attributes are then expanded normally during the main expansion pass, like attributes on any other nodes.
Fix cross-compiling with dlltool for raw-dylib
Fix for #103939
Issue Details:
When attempting to cross-compile using the `raw-dylib` feature and the GNU toolchain, rustc would attempt to find a cross-compiling version of dlltool (e.g., `i686-w64-mingw32-dlltool`). The has two issues 1) on Windows dlltool is always `dlltool` (no cross-compiling named versions exist) and 2) it only supported compiling to i686 and x86_64 resulting in ARM 32 and 64 compiling as x86_64.
Fix Details:
* On Windows always use the normal `dlltool` binary.
* Add the ARM64 cross-compiling dlltool name (support for this is coming: https://sourceware.org/bugzilla/show_bug.cgi?id=29964)
* Provide the `-m` argument to dlltool to indicate the target machine type.
(This is the first of two PRs to fix the remaining issues for the `raw-dylib` feature (#58713) that is blocking stabilization (#104218))
make param bound vars visibly bound vars with -Zverbose
I was trying to debug some type/const bound var stuff and it was shockingly tricky due to the fact that even with `-Zverbose` enabled the `T` in `for<T> T: Trait` prints as `T` making it seem like its `TyKind::Param` when it is infact `TyKind::Bound`. This PR "fixes" this when `-Zverbose` is set to allow rendering it as `^T` or `^1_T` depending on binder depth.
r? ```@compiler-errors```
Simpler checked shifts in MIR building
Doing masking to check unsigned shift amounts is overcomplicated; just comparing the shift directly saves a statement and a temporary, as well as is much easier to read as a human. And shifting by unsigned is the canonical case -- notably, all the library shifting methods (that don't support every type) take shift RHSs as `u32` -- so we might as well make that simpler since it's easy to do so.
This PR also changes *signed* shift amounts to `IntToInt` casts and then uses the same check as for unsigned. The bit-masking is a nice trick, but for example LLVM actually canonicalizes it to an unsigned comparison anyway <https://rust.godbolt.org/z/8h59fMGT4> so I don't think it's worth the effort and the extra `Constant`. (If MIR's `assert` was `assert_nz` then the masking might make sense, but when the `!=` uses another statement I think the comparison is better.)
To review, I suggest looking at 2ee0468c49 first -- that's the interesting code change and has a MIR diff.
My favourite part of the diff:
```diff
- _20 = BitAnd(_19, const 340282366920938463463374607431768211448_u128); // scope 0 at $DIR/shifts.rs:+2:34: +2:44
- _21 = Ne(move _20, const 0_u128); // scope 0 at $DIR/shifts.rs:+2:34: +2:44
- assert(!move _21, "attempt to shift right by `{}`, which would overflow", _19) -> [success: bb3, unwind: bb7]; // scope 0 at $DIR/shifts.rs:+2:34: +2:44
+ _18 = Lt(_17, const 8_u128); // scope 0 at $DIR/shifts.rs:+2:34: +2:44
+ assert(move _18, "attempt to shift right by `{}`, which would overflow", _17) -> [success: bb3, unwind: bb7]; // scope 0 at $DIR/shifts.rs:+2:34: +2:44
```
Make alias-eq have a relation direction (and rename it to alias-relate)
Emitting an "alias-eq" is too strict in some situations, since we don't always want strict equality between a projection and rigid ty. Adds a relation direction.
* I could probably just reuse this [`RelationDir`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/combine/enum.RelationDir.html) -- happy to uplift that struct into middle and use that instead, but I didn't feel compelled to... 🤷
* Some of the matching in `compute_alias_relate_goal` is a bit verbose -- I guess I could simplify it by using [`At::relate`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/at/struct.At.html#method.relate) and mapping the relation-dir to a variance.
* Alternatively, I coulld simplify things by making more helper functions on `EvalCtxt` (e.g. `EvalCtxt::relate_with_direction(T, T)` that also does the nested goal registration). No preference.
r? ```@lcnr``` cc ```@BoxyUwU``` though boxy can claim it if she wants
NOTE: first commit is all the changes, the second is just renaming stuff
Make NLL Type Relating Eager
We previously instantiated bound regions in nll type relating lazily. Making this eager is more consistent with how we handle type relating in [`higher_ranked_sub`](0a3b557d52/compiler/rustc_infer/src/infer/higher_ranked/mod.rs (L28)) and should allow us to short circuit in case there's structural equality.
Updates `interpret`, `codegen_ssa`, and `codegen_cranelift` to consume the new cast instead of the intrinsic.
Includes `CastTransmute` for custom MIR building, to be able to test the extra UB.
new solver cleanup + implement coherence
the cleanup:
- change `Certainty::unify_and` to consider ambig + overflow to be ambig
- rename `trait_candidate_should_be_dropped_in_favor_of` to `candidate_should_be_dropped_in_favor_of`
- remove outdated fixme
For coherence I mostly just add an ambiguous candidate if the current trait ref is unknowable. I am doing the same for reservation impl where I also just add an ambiguous candidate.
Use region-erased self type during IAT selection
Split off from #109410 as discussed.
Fixes#109299.
Re UI test: I use a reproducer of #109299 that contains a name resolution error instead of reproducer [`regionck-2.rs`](fc7ed4af16/tests/ui/associated-inherent-types/regionck-2.rs) (as found in the `AliasKind::Inherent` PR) since it would (incorrectly) pass typeck in this PR due to the lack of regionck and I'd rather not make *that* a regression test (with or without `known-bug`).
``@rustbot`` label F-inherent_associated_types
r? ``@compiler-errors``
rustc: Remove unused `Session` argument from some attribute functions
(One auxiliary test file containing one of these functions was unused, so I removed it instead of updating.)
Eagerly intern and check CrateNum/StableCrateId collisions
r? ``@cjgillot``
It seems better to check things ahead of time than checking them afterwards.
The [previous version](https://github.com/rust-lang/rust/pull/108390) was a bit nonsensical, so this addresses the feedback
Do not feed param_env for RPITITs impl side
r? `@compiler-errors`
I don't think this needs more comments or things that we already have but please let me know if you want some comments or something else in this PR.
Detect uninhabited types early in const eval
r? `@RalfJung`
implements https://github.com/rust-lang/rust/pull/108442#discussion_r1143003840
this is a breaking change, as some UB during const eval is now detected instead of silently being ignored. Users can see this and other UB that may cause future breakage with `-Zextra-const-ub-checks` or just by running miri on their code, which sets that flag by default.
Do not consider synthesized RPITITs on missing items checks
Without this patch for `tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs` we get ...
```
warning: the feature `return_position_impl_trait_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs:4:12
|
4 | #![feature(return_position_impl_trait_in_trait)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error[E0046]: not all trait items implemented, missing: `foo`, ``
--> tests/ui/impl-trait/in-trait/dont-project-to-rpitit-with-no-value.rs:12:1
|
8 | fn foo(&self) -> impl Sized;
| ----------------------------
| | |
| | `` from trait
| `foo` from trait
...
12 | impl MyTrait for i32 {
| ^^^^^^^^^^^^^^^^^^^^ missing `foo`, `` in implementation
error: aborting due to previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0046`.
```
instead of ...
```
warning: the feature `return_position_impl_trait_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> $DIR/dont-project-to-rpitit-with-no-value.rs:4:12
|
LL | #![feature(return_position_impl_trait_in_trait)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error[E0046]: not all trait items implemented, missing: `foo`
--> $DIR/dont-project-to-rpitit-with-no-value.rs:12:1
|
LL | fn foo(&self) -> impl Sized;
| ---------------------------- `foo` from trait
...
LL | impl MyTrait for i32 {
| ^^^^^^^^^^^^^^^^^^^^ missing `foo` in implementation
error: aborting due to previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0046`.
```
r? `@compiler-errors`
Update links for custom discriminants.
The discriminant documentation was updated in https://github.com/rust-lang/reference/pull/1055 which changed the layout a bit. This updates the links to the updated locations.
rustdoc: Cleanup parent module tracking for doc links
Keep ids of the documented items themselves, not their parent modules. Parent modules can be retreived from those ids when necessary.
Fixes https://github.com/rust-lang/rust/issues/108501.
That issue could be fixed in a more local way, but this refactoring is something that I wanted to do since https://github.com/rust-lang/rust/pull/93805 anyway.
move Option::as_slice to intrinsic
````@scottmcm```` suggested on #109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation.
cc ````@nikic```` as this should hopefully unblock #107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
a general type system cleanup
removes the helper functions `traits::fully_solve_X` as they add more complexity then they are worth. It's confusing which of these helpers should be used in which context.
changes the way we deal with overflow to always add depth in `evaluate_predicates_recursively`. It may make sense to actually fully transition to not have `recursion_depth` on obligations but that's probably a bit too much for this PR.
also removes some other small - and imo unnecessary - helpers.
r? types
Only clear written-to locals in ConstProp
This aims to revert the regression in https://github.com/rust-lang/rust/pull/108872
Clearing all locals at the end of each bb is very costly.
This PR goes back to the original implementation of recording which locals are modified.
