Automatic Rustup #4743
Merged
Automatic Rustup #4743
+29
−35
Conversation
This file contains hidden or 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
misc coercion cleanups and handle safety correctly r? lcnr ### "remove normalize call" Fixes rust-lang/rust#132765 If the normalization fails we would sometimes get a `TypeError` containing inference variables created inside of the probe used by coercion. These would then get leaked out causing ICEs in diagnostics logic ### "leak check and lub for closure<->closure coerce-lubs of same defids" Fixes rust-lang/trait-system-refactor-initiative#233 ```rust fn peculiar() -> impl Fn(u8) -> u8 { return |x| x + 1 } ``` the `|x| x + 1` expr has a type of `Closure(?31t)` which we wind up inferring the RPIT to. The `CoerceMany` `ret_coercion` for the whole `peculiar` typeck has an expected type of `RPIT` (unnormalized). When we type check the `return |x| x + 1` expr we go from the never type to `Closure(?31t)` which then participates in the `ret_coercion` giving us a `coerce-lub(RPIT, Closure(?31t))`. Normalizing `RPIT` gives us some `Closure(?50t)` where `?31t` and `?50t` have been unified with `?31t` as the root var. `resolve_vars_if_possible` doesn't resolve infer vars to their roots so these wind up with different structural identities so the fast path doesn't apply and we fall back to coercing to a `fn` ptr. cc rust-lang/rust#147193 which also fixes this New solver probably just gets more inference variables here because canonicalization + generally different approach to normalization of opaques. Idk :3 ### FCP worthy stuffy there are some other FCP worthy things but they're in my FCP comment which also contains some analysis of the breaking nature of the previously listed changes in this PR: rust-lang/rust#148602 (comment)
alloc: Document panics when allocations will exceed max Document panics in `String` and `Vec` due to capacity overflowing `isize::MAX`. Correct outdated claims of `usize::MAX` limit. Fixes rust-lang/rust#148598. Ping `@lolbinarycat`
…boet core docs: rewrite `panic::Location::caller` with visual line/column numbers no tracking issue hey, this is my first PR on rust-lang/rust, so hopefully everything goes well. i noticed the documentation for `core::panic::Location::caller` was kind of unintelligible (and maybe even wrong due to standalone_crate) and filled with magic numbers, so i provided line and column numbers as a visual guidance as to how it should be used. edit: uh oh, looks like i pushed changes from random commits unrelated to me, what's going on? edit2: reverted the unintended changes by this pr
Improve mutable-binding suggestion to include name resolve: rust-lang/rust#148467
float::maximum/minimum: make docs more streamlined This does with `maximum`/`minimum` what rust-lang/rust#149475 did with `max`/`min`: first a self-contained description of the semantics, then comparing with other operations. It also makes the wording consistent with those other functions. Previously we had some of the semantics below the examples for some reason, and we repeated "If one of the arguments is NaN, then NaN is returned"; that has been streamlined as well. r? `@tgross35`
library: Rename `IterRange*` to `Range*Iter` There is a weak convention in the ecosystem that `IterFoos` is an iterator yielding items of type `Foo` (e.g. `bitflags` `IterNames`, `hashbrown` `IterBuckets`), while `FooIter` is an iterator over `Foo` from an `.iter()` or `.into_iter()` method (e.g. `memchr` `OneIter`, `regex` `SetMatchesIter`). Rename `IterRange`, `IterRangeInclusive`, and `IterRangeFrom` to `RangeIter`, `RangeInclusiveIter`, and `RangeInclusiveIter` to match this. Tracking issue: rust-lang/rust#125687 (`new_range_api`)
Generate delegation error body when delegation is not resolved This PR relates to the delegation feature rust-lang/rust#118212, it fixes rust-lang/rust#144594 ICE. r? `@petrochenkov`
Check identifiers defined in macros when suggesting identifiers hidden by hygiene Fix rust-lang/rust#149604 r? `@JonathanBrouwer` (Since you reviewed the other one related to this)
Add regression test for 141845 close: rust-lang/rust#141845 I saw the `tests/ui/associated-inherent-types` directory, but I felt the current location was a better fit.
…viper Fix for LLVM22 making lowering decisions dependent on RuntimeLibraryInfo. LLVM added codegen decision making based on RuntimeLibraryInfo. Mirror the change in Rust's codegen. LLVM reference commit: llvm/llvm-project@04c81a9.
interpret: test SNaN handling of float min/max and update comments Also see rust-lang/rust#149563. I also renamed these enum variants so they are not almost identical.
Rollup of 11 pull requests Successful merges: - rust-lang/rust#148662 (alloc: Document panics when allocations will exceed max) - rust-lang/rust#148811 (core docs: rewrite `panic::Location::caller` with visual line/column numbers) - rust-lang/rust#149101 (Improve mutable-binding suggestion to include name) - rust-lang/rust#149477 (float::maximum/minimum: make docs more streamlined) - rust-lang/rust#149547 (library: Rename `IterRange*` to `Range*Iter`) - rust-lang/rust#149548 (Generate delegation error body when delegation is not resolved) - rust-lang/rust#149630 (Check identifiers defined in macros when suggesting identifiers hidden by hygiene) - rust-lang/rust#149647 (Add regression test for 141845) - rust-lang/rust#149661 (Fix for LLVM22 making lowering decisions dependent on RuntimeLibraryInfo.) - rust-lang/rust#149666 (Add perma-unstable `--print=backend-has-zstd` for use by compiletest) - rust-lang/rust#149671 (interpret: test SNaN handling of float min/max and update comments) r? `@ghost` `@rustbot` modify labels: rollup
`c_variadic`: make `VaList` abi-compatible with C tracking issue: rust-lang/rust#44930 related PR: rust-lang/rust#144529 On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly. In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy, In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang/rust#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct. Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (rust-lang/rust#141524 (comment)), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms). Previous discussion: rust-lang/rust#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI) Tracking issue: rust-lang/rust#44930 r? `@joshtriplett`
This updates the rust-version file to 36b2369c91d32c2659887ed6fe3d570640f44fd2.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 36b2369c91d32c2659887ed6fe3d570640f44fd2 Filtered ref: bfd8fa7 Upstream diff: rust-lang/rust@864339a...36b2369 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two. |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
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.
Merge ref '36b2369c91d3' from rust-lang/rust
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 36b2369c91d32c2659887ed6fe3d570640f44fd2
Filtered ref: bfd8fa7
Upstream diff: rust-lang/rust@864339a...36b2369
This merge was created using https://github.com/rust-lang/josh-sync.