-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #101225
Rollup of 8 pull requests #101225
Conversation
… on OpenBSD) - add platform-support documentation - add riscv64gc-unknown-openbsd spec - do not try to link with -latomic on openbsd
Co-authored-by: Esteban Kuber <[email protected]>
…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
@bors r+ rollup=never p=8 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 7f442f8ba1 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (12e4fd0): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
Successful merges:
std::sys::windows
#101171 (Fix UB from misalignment and provenance widening instd::sys::windows
)WellFormedLoc
s a bit #101185 (TweakWellFormedLoc
s a bit)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup