Rollup of 9 pull requests #101223
Closed
Rollup of 9 pull requests #101223
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
… on OpenBSD) - add platform-support documentation - add riscv64gc-unknown-openbsd spec - do not try to link with -latomic on openbsd
This avoids a `force_allocation`
Co-authored-by: Esteban Kuber <[email protected]>
interpret: use new OpTy::len for Len rvalue This avoids a `force_allocation`.
…n, r=davidtwco Allow deriving multipart suggestions This turned into a bit more of a rewrite than I was initially hoping for... Still, I think the `SessionSubdiagnostic` derive is a little cleaner overall now, and closer to the `SessionDiagnostic` derive to make future code sharing easier. r? `@davidtwco`
…-Simulacrum Reinstate preloading of some dll imports I've now come around to the conclusion that there is a justification for pre-loading the synchronization functions `WaitOnAddress` and `WakeByAddressSingle`. I've found this to have a particularly impact in testing frameworks that may have short lived processes which immediately spawn lots of threads. Also, because pre-main initializers imply a single-threaded environment, we can switch back to using relaxed atomics which might be a minor perf improvement on some platforms (though I doubt it's particularly notable). r? `@Mark-Simulacrum` and sorry for the churn here. For convenience I'll summarise previous issues with preloading and the solutions that are included in this PR (if any): **Issue:** User pre-main initializers may be run before std's **Solution:** The std now uses initializers that are guaranteed to run earlier than the old initializers. A note is also added that users should not copy std's behaviour if they want to ensure they run their initializers after std. **Issue:** Miri does not understand pre-main initializers. **Solution:** For miri only, run the function loading lazily instead. **Issue:** We should ideally use `LoadLibrary` to get "api-ms-win-core-synch-l1-2-0". Only "ntdll" and "kernel32" are guaranteed to always be loaded. **Solution:** None. We can't use `LoadLibrary` pre-main. However, in the past `GetModuleHandle` has always worked in practice so this should hopefully not be a problem. If/when Windows 7 support is dropped, we can finally remove all this for good and just use normal imports.
…ents, r=thomcc Use getentropy when possible on all Apple platforms As the current code comments say, `SecRandomCopyBytes` is very heavyweight (regardless of purpose) compared to just asking the kernel directly for bytes from its own CSPRNG. We were not previously making an attempt to use the more efficient `getentropy` call on other Apple targets, instead solely using it on macOS. As the function is available on newer versions of Apple's different OSes, this changes the random filling to always attempt it first everywhere, only falling back to the less ideal alternatives after. This also cleans up the multiple Apple `imp` blocks into one. It also should give a perf improvement, even if its likely unnoticeably small. Refed XCode header for `getentropy` in the SDK: ```h int getentropy(void* buffer, size_t size) __OSX_AVAILABLE(10.12) __IOS_AVAILABLE(10.0) __TVOS_AVAILABLE(10.0) __WATCHOS_AVAILABLE(3.0); ``` r? `@thomcc`
Add tier-3 support for powerpc64 and riscv64 openbsd # powerpc64 - MCP for [powerpc64-unknown-openbsd tier-3 support](rust-lang/compiler-team#551) - only need to add spec definition in rustc_target # riscv64 - MCP for [riscv64-unknown-openbsd tier-3 support](rust-lang/compiler-team#552) - add spec definition in rustc_target - follow freebsd about avoiding linking with `libatomic`
…ast_lowering, r=davidtwco Remove span fatal from ast lowering Now the crate `rustc_ast_lowering` is fully migrated to `SessionDiagnostic`. r? `@davidtwco`
…ggestions, r=petrochenkov Make call suggestions more general and more accurate Cleans up some suggestions that have to do with adding `()` to make typeck happy. 1. Drive-by rename of `expr_t` to `base_ty` since it's the type of the `base_expr` 1. Autoderef until we get to a callable type in `suggest_fn_call`. 1. Don't erroneously suggest calling constructor when a method/field does not exist on it. 1. Suggest calling a method receiver if its function output has a method (e.g. `fn.method()` => `fn().method()`) 1. Extend call suggestions to type parameters, fn pointers, trait objects where possible 1. Suggest calling in operators too (fixes rust-lang#101054) 1. Use `/* {ty} */` as argument placeholder instead of just `_`, which is confusing and makes suggestions look less like `if let` syntax.
Fix UB from misalignment and provenance widening in `std::sys::windows` This fixes two types of UB: 1. Reading past the end of a reference in types like `&c::REPARSE_DATA_BUFFER` (see rust-lang/unsafe-code-guidelines#256). This is fixed by using `addr_of!`. I think there are probably a couple more cases where we do this for other structures, and will look into it in a bit. 2. Failing to ensure that a `[u8; N]` on the stack is sufficiently aligned to convert to a `REPARSE_DATA_BUFFER`. ~~This was done by introducing a new `AlignedAs` struct that allows aligning one type to the alignment of another type. I expect there are other places where we have this issue too, or I wouldn't introduce this type, but will get to them after this lands.~~ ~~Worth noting, it *is* implemented in a way that can cause problems depending on how we fix rust-lang#81996, but this would be caught by the test I added (and presumably if we decide to fix that in a way that would break this code, we'd also introduce a `#[repr(simple)]` or `#[repr(linear)]` as a replacement for this usage of `#[repr(C)]`).~~ Edit: None of that is still in the code, I just went with a `Align8` since that's all we'll need for almost everything we want to call. These are more or less "potential UB" since it's likely at the moment everything works fine, although the alignment not causing issues might just be down to luck (and x86 being forgiving). ~~NB: I've only ensured this check builds, but will run tests soon.~~ All tests pass, including stage2 compiler tests. r? `@ChrisDenton`
…avidtwco Tweak `WellFormedLoc`s a bit Gives a bit tighter spans in returns and generic ty defaults
rustbot
added
T-bootstrap
|
@bors r+ rollup=never p=9 |
bors
added
the
S-waiting-on-bors
|
@matthiaskrgr Could you exclude #100085? I think it caused a failure on #101218 and I r-'ed it just now. |
|
Just in case, @bors r- |
bors
added
S-waiting-on-author
davidtwco
removed
the
A-translation
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.
Successful merges:
std::sys::windows#101171 (Fix UB from misalignment and provenance widening instd::sys::windows)WellFormedLocs a bit #101185 (TweakWellFormedLocs a bit)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup