[pull] master from rust-lang:master #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
we get these declarations ``` ; opt level 0 declare x86_intrcc void @page_fault_handler(ptr byval([8 x i8]) align 8, i64) unnamed_addr #1 ; opt level > 0 declare x86_intrcc void @page_fault_handler(ptr noalias nocapture noundef byval([8 x i8]) align 8 dereferenceable(8), i64 noundef) unnamed_addr #1 ``` The space after `i64` in the original regex made the regex not match for opt level 0. Removing the space fixes the issue. ``` declare x86_intrcc void @page_fault_handler(ptr {{.*}}, i64 {{.*}}){{.*}}#[[ATTRS:[0-9]+]] ```
`rustc_mir_dataflow` has a typedef `AbstractElem` that is equal to `ProjectionElem<AbstractOperand, AbstractType>`. `AbstractOperand` and `AbstractType` are both unit types. There is also has a trait `Lift` to convert a `PlaceElem` to an `AbstractElem`. But `rustc_mir_middle` already has a typedef `ProjectionKind` that is equal to `ProjectionElem<(), ()>`, which is equivalent to `AbstractElem`. So this commit reuses `ProjectionKind` in `rustc_mir_dataflow`, removes `AbstractElem`, and simplifies the `Lift` trait.
Adding it did not cause any error. Most of this falls back on Unix already. See #127747
Rollup of 9 pull requests Successful merges: - #133583 (Fix type (exit → exist)) - #134042 (Add the `power8-crypto` target feature) - #134094 (Tweak wording of non-const traits used as const bounds) - #134100 (Remove rustc_const_stable attribute on const NOOP) - #134103 (Don't ICE when encountering never in range pattern) - #134113 (run-make: Fix `assert_stderr_not_contains_regex`) - #134115 (rustc_target: ppc64 target string fixes for LLVM 20) - #134116 (stabilize const_nonnull_new) - #134120 (Remove Felix from ping groups and review rotation) r? `@ghost` `@rustbot` modify labels: rollup
feat: preserve order of parameters in extract_functions
minor: Migrate `generate_enum_variant` to `SyntaxEditor`
Hash completion items to properly match them during /resolve
feat: Add diagnostic fix to remove unnecessary wrapper in type mismatch
Add a note saying that `{u8,i8}::from_{be,le,ne}_bytes` is meaningless
…eywiser Validate self in host predicates correctly `assert_only_contains_predicates_from` was added to make sure that we are computing predicates for the correct self type for a given `PredicateFilter`. That was not implemented correctly for `PredicateFilter::SelfOnly` when there are const predicates. Fixes #133526
…jieyouxu
Exercise const trait interaction with default fields
Add a test case for using the result of a fn call of an associated function of a `const` trait in a struct default field.
```rust
struct X;
trait Trait {
fn value() -> Self;
}
impl const Trait for X {
fn value() -> Self { X }
}
struct S<T: const Trait> {
a: T = T::value(),
}
```
[AIX] keep profile-rt symbol alive Clang passes `-u __llvm_profile_runtime` on AIX. https://reviews.llvm.org/D136192 We want to preserve the symbol in the case there are no instrumented object files.
Remove more traces of anonymous ADTs Anonymous ADTs were removed in #131045, but I forgot to remove this.
Rudimentary heuristic to insert parentheses when needed for RPIT overcaptures lint We don't have basically any preexisting machinery to detect when parentheses are needed for *types*. AFAICT, all of the diagnostics we have for opaques just... fail when they suggest `+ 'a` when that's ambiguous. Fixes #132853
Rename `projection_def_id` to `item_def_id` Renames `projection_def_id` to `item_def_id`, since `item_def_id` is what we call the analogous method for ~~`AliasTerm`/`AliasTy`~~ `PolyExistentialProjection`. I keep forgetting that this one is not called `item_def_id`.
Rollup of 6 pull requests Successful merges: - #133221 (Add external macros specific diagnostics for check-cfg) - #133386 (Update linux_musl base to dynamically link the crt by default) - #134191 (Make some types and methods related to Polonius + Miri public) - #134227 (Update wasi-sdk used to build WASI targets) - #134279 ((Re-)return adjustment target if adjust kind is never-to-any) - #134295 (Encode coroutine-closures in SMIR) r? `@ghost` `@rustbot` modify labels: rollup
Various types can be used as method receivers, such as Rc<>, Box<> and Arc<>. The arbitrary self types v2 work allows further types to be made method receivers by implementing the Receiver trait. With that in mind, it may come as a surprise to people when certain common types do not implement Receiver and thus cannot be used as a method receiver. The RFC for arbitrary self types v2 therefore proposes emitting specific lint hints for these cases: * NonNull * Weak * Raw pointers The code already emits a hint for this third case, in that it advises folks that the `arbitrary_self_types_pointers` feature may meet their need. This PR adds diagnostic hints for the Weak and NonNull cases.
I mixed it up with RUSTC_CURRENT_VERSION unfortunately. Also improve the formatting of the macro invocation slightly.
…idtwco,RalfJung Bounds-check with PtrMetadata instead of Len in MIR Rather than emitting `Len(*_n)` in array index bounds checks, emit `PtrMetadata(copy _n)` instead -- with some asterisks for arrays and `&mut` that need it to be done slightly differently. We're getting pretty close to removing `Len` entirely, actually. I think just one more PR after this (for slice drop shims). r? mir
Suggest using deref in patterns Fixes #132784 This changes the following code: ```rs use std::sync::Arc; fn main() { let mut x = Arc::new(Some(1)); match x { Some(_) => {} None => {} } } ``` to output ```rs error[E0308]: mismatched types --> src/main.rs:5:9 | LL | match x { | - this expression has type `Arc<Option<{integer}>>` ... LL | Some(_) => {} | ^^^^^^^ expected `Arc<Option<{integer}>>`, found `Option<_>` | = note: expected struct `Arc<Option<{integer}>>` found enum `Option<_>` help: consider dereferencing to access the inner value using the Deref trait | LL | match *x { | ~~ ``` instead of ```rs error[E0308]: mismatched types --> src/main.rs:5:9 | 4 | match x { | - this expression has type `Arc<Option<{integer}>>` 5 | Some(_) => {} | ^^^^^^^ expected `Arc<Option<{integer}>>`, found `Option<_>` | = note: expected struct `Arc<Option<{integer}>>` found enum `Option<_>` ``` This makes it more obvious that a Deref is available, and gives a suggestion on how to use it in order to fix the issue at hand.
…ee,jieyouxu,tgross35 Updates Solaris target information, adds Solaris maintainer
Fix ICE when multiple supertrait substitutions need assoc but only one is provided
Dyn traits must have all of their associated types constrained either by:
1. writing them in the dyn trait itself as an associated type bound, like `dyn Iterator<Item = u32>`,
2. A supertrait bound, like `trait ConstrainedIterator: Iterator<Item = u32> {}`, then you may write `dyn ConstrainedIterator` which doesn't need to mention `Item`.
However, the object type lowering code did not consider the fact that there may be multiple supertraits with different substitutions, so it just used the associated type's *def id* as a key for keeping track of which associated types are missing:
https://github.com/rust-lang/rust/blob/1fc691e6ddc24506b5234d586a5c084eb767f1ad/compiler/rustc_hir_analysis/src/hir_ty_lowering/dyn_compatibility.rs#L131
This means that we can have missing associated types when there are mutliple supertraits with different substitutions and only one of them is constrained, like:
```rust
trait Sup<T> {
type Assoc: Default;
}
impl<T: Default> Sup<T> for () {
type Assoc = T;
}
impl<T: Default, U: Default> Dyn<T, U> for () {}
trait Dyn<A, B>: Sup<A, Assoc = A> + Sup<B> {}
```
The above example allows you to name `<dyn Dyn<i32, u32> as Sup<u32>>::Assoc` even though it is not possible to project since it's neither constrained by a manually written projection bound or a supertrait bound. This successfully type-checks, but leads to a codegen ICE since we are not able to project the associated type.
This PR fixes the validation for checking that a dyn trait mentions all of its associated type bounds. This is theoretically a breaking change, since you could technically use that `dyn Dyn<A, B>` type mentionedin the example above without actually *projecting* to the bad associated type, but I don't expect it to ever be relevant to a user since it's almost certainly a bug. This is corroborated with the crater results[^crater], which show no failures[^unknown].
Crater: #133392 (comment)
Fixes #133388
[^crater]: I cratered this originally with #133397, which is a PR that is stacked on top, then re-ran crater with just the failures from that PR.
[^unknown]: If you look at the crater results, it shows all of the passes as "unknown". I believe this is a crater bug, since looking at the results manually shows them as passes.
…tion, r=tgross35 Add documentation for anonymous pipe module Tracking issue: #127154 `@NobodyXu` I've been using this feature lately and thought I might contribute with some documentation. I borrowed liberally from [os_pipe](https://docs.rs/os_pipe/latest/os_pipe/) so thanks to `@oconnor663.`
… r=tgross35 Doc: Extend for tuples to be stabilized in 1.85.0 I assumed the RUSTC_CURRENT_VERSION would be replaced automatically, but it doesn't look like it on the nightly docs page. Sorry!
Clean up `infer_return_ty_for_fn_sig` The code for lowering fn signatures from HIR currently is structured to prefer the recovery path (where users write `-> _`) over the good path. This PR pulls the recovery code out into a separate fn. Review w/o whitespace
Arbitrary self types v2: Weak & NonNull diagnostics This builds on top of #134262 which is more urgent to review and merge first. I'll likely rebase this PR once that lands. This is the first part of the diagnostic enhancements planned for Arbitrary Self Types v2. Various types can be used as method receivers, such as `Rc<>`, `Box<>` and `Arc<>`. The arbitrary self types v2 work allows further types to be made method receivers by implementing the Receiver trait. With that in mind, it may come as a surprise to people when certain common types do not implement Receiver and thus cannot be used as a method receiver. The RFC for arbitrary self types v2 therefore proposes emitting specific lint hints for these cases: * `NonNull` * `Weak` * Raw pointers The code already emits a hint for this third case, in that it advises folks that the `arbitrary_self_types_pointers` feature may meet their need. This PR adds diagnostic hints for the `Weak` and `NonNull` cases. Tracking issue #44874 r? `@wesleywiser`
Rollup of 7 pull requests Successful merges: - #132939 (Suggest using deref in patterns) - #133293 (Updates Solaris target information, adds Solaris maintainer) - #133392 (Fix ICE when multiple supertrait substitutions need assoc but only one is provided) - #133986 (Add documentation for anonymous pipe module) - #134022 (Doc: Extend for tuples to be stabilized in 1.85.0) - #134259 (Clean up `infer_return_ty_for_fn_sig`) - #134264 (Arbitrary self types v2: Weak & NonNull diagnostics) r? `@ghost` `@rustbot` modify labels: rollup
the linker arguments can be *very* long, especially for crates with many dependencies. some parts of them are not very useful. unless specifically requested: - omit object files specific to the current invocation - fold rlib files into a single braced argument (in shell expansion format) this shortens the output significantly without removing too much information.
Remove support for specializing ToString outside the standard library This is the only trait specializable outside of the standard library. Before stabilizing specialization we will probably want to remove support for this. It was originally made specializable to allow a more efficient ToString in libproc_macro back when this way the only way to get any data out of a TokenStream. We now support getting individual tokens, so proc macros no longer need to call it as often.
`UniqueRc` trait impls UniqueRc tracking Issue: #112566 Stable traits: (i.e. impls behind only the `unique_rc_arc` feature gate) * Support the same formatting as `Rc`: * `fmt::Debug` and `fmt::Display` delegate to the pointee. * `fmt::Pointer` prints the address of the pointee. * Add explicit `!Send` and `!Sync` impls, to mirror `Rc`. * Borrowing traits: `Borrow`, `BorrowMut`, `AsRef`, `AsMut` * `Rc` does not implement `BorrowMut` and `AsMut`, but `UniqueRc` can. * Unconditional `Unpin`, like other heap-allocated types. * Comparison traits `(Partial)Ord` and `(Partial)Eq` delegate to the pointees. * `PartialEq for UniqueRc` does not do `Rc`'s specialization shortcut for pointer equality when `T: Eq`, since by definition two `UniqueRc`s cannot share an allocation. * `Hash` delegates to the pointee. * `AsRawFd`, `AsFd`, `AsHandle`, `AsSocket` delegate to the pointee like `Rc`. * Sidenote: The bounds on `T` for the existing `Pointer<T>` impls for specifically `AsRawFd` and `AsSocket` do not allow `T: ?Sized`. For the added `UniqueRc` impls I allowed `T: ?Sized` for all four traits, but I did not change the existing (stable) impls. Unstable traits: * `DispatchFromDyn`, allows using `UniqueRc<Self>` as a method receiver under `feature(arbitrary_self_types)`. * Existing `PinCoerceUnsized for UniqueRc` is generalized to allow non-`Global` allocators, like `Rc`. * `DerefPure`, allows using `UniqueRc` in deref-patterns under `feature(deref_patterns)`, like `Rc`. For documentation, `Rc` only has documentation on the comparison traits' methods, so I copied/adapted the documentation for those, and left the rest without impl-specific docs. ~~Edit: Marked as draft while I figure out `UnwindSafe`.~~ Edit: Ignoring `UnwindSafe` for this PR
std::net: Solaris supports `SOCK_CLOEXEC` as well since 11.4. try-job: dist-various-2
Add value accessor methods to `Mutex` and `RwLock` - ACP: rust-lang/libs-team#485. - Tracking issue: #133407. This PR adds `get`, `set` and `replace` methods to the `Mutex` and `RwLock` types for quick access to their contained values. One possible optimization would be to check for poisoning first and return an error immediately, without attempting to acquire the lock. I didn’t implement this because I consider poisoning to be relatively rare, adding this extra check could slow down common use cases.
don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from #119286. fixes #109979. r? `@bjorn3` try-build: i686-mingw
Add some convenience helper methods on `hir::Safety` Makes a lot of call sites simpler and should make any refactorings needed for #134090 (comment) simpler, as fewer sites have to be touched in case we end up storing some information in the variants of `hir::Safety`
Add clarity to the examples of some `Vec` & `VecDeque` methods In some `Vec` and `VecDeque` examples where elements are `i32`, examples can seem a bit confusing at first glance if a parameter of the method is an `usize`. In this case, I think it's better to use `char` rather than `i32`. > [!NOTE] > It's already done in the implementation of `VecDeque::insert` #### Difference - `i32` ```rs let mut v = vec![1, 2, 3]; assert_eq!(v.remove(1), 2); assert_eq!(v, [1, 3]); ``` - `char` ```rs let mut v = vec!['a', 'b', 'c']; assert_eq!(v.remove(1), 'b'); assert_eq!(v, ['a', 'c']); ``` Even tho it's pretty minor, it's a nice to have.
Don't make a def id for `impl_trait_in_bindings`
The def collector is awkward, so for now just wrap let statements in a new `ImplTraitContext::InBinding` which tells `visit_ty` not to make a def id for the type. This will not generalize to other ITIB cases, like if we allow them in turbofishes (e.g. `foo::<impl Fn()>(|| {})`).
Fixes #134307
r? oli-obk
A couple of polonius fact generation cleanups This PR is extracted from #134268 for easier review and contains its first two commits. They have already been reviewed by `@jackh726.` r? `@jackh726`
Co-authored-by: Jubilee <workingjubilee@gmail.com>
Rollup of 7 pull requests Successful merges: - #130361 (std::net: Solaris supports `SOCK_CLOEXEC` as well since 11.4.) - #133406 (Add value accessor methods to `Mutex` and `RwLock`) - #133633 (don't show the full linker args unless `--verbose` is passed) - #134285 (Add some convenience helper methods on `hir::Safety`) - #134310 (Add clarity to the examples of some `Vec` & `VecDeque` methods) - #134313 (Don't make a def id for `impl_trait_in_bindings`) - #134315 (A couple of polonius fact generation cleanups) r? `@ghost` `@rustbot` modify labels: rollup
Modifies the index instruction from `gep [0 x %Type]` to `gep %Type` Fixes #133979. This PR modifies the index instruction from `gep [0 x %Type]` to `gep %Type`, which is the same with pointer offset calculation. This will help LLVM calculate various formats of GEP instructions. According to [[RFC] Replacing getelementptr with ptradd](https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699), we ultimately aim to canonicalize everything to `gep i8`. Based on the results from #134117 (comment), I think we still need to investigate some missing optimizations, so this PR is just a small step forward. r? compiler
reject aarch64 target feature toggling that would change the float ABI ~~Stacked on top of #133099. Only the last two commits are new.~~ The first new commit lays the groundwork for separately controlling whether a feature may be enabled or disabled. The second commit uses that to make it illegal to *disable* the `neon` feature (which is only possible via `-Ctarget-feature`, and so the new check just adds a warning). Enabling the `neon` feature remains allowed on targets that don't disable `neon` or `fp-armv8`, which is all our built-in targets. This way, the entire PR is not a breaking change. Fixes #131058 for hardfloat targets (together with #133102 which fixed it for softfloat targets). Part of #116344.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )