-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Refactor panic_unwind/seh.rs
pointer use
#123490
Conversation
The CI failure gives no information except @rustbot label +O-windows +A-panic |
56870fd
to
3d0ed4a
Compare
@bors r+ |
…manieu Refactor `panic_unwind/seh.rs` pointer use * `x86` now conforms to strict-provenance * `x86_64` now uses the expose API (instead of `as` casts) * changed `ptr_t` from a type alias to a `repr(transparent)` struct for some extra type-safety * replaced the `ptr!` macro by methods on `ptr_t`, as there is now no reason (as far as I can see) anymore to use a macro On `x86_64` pointers in SEH are represented by 32-bit offsets from `__ImageBase`, so we can't use a pointer type. It might be possible to leak the provenance into the FFI by using a `MaybeUninit<u32>` instead of a `u32`, but that is a bit more involved than using expose, and I'm not sure that would be worth it.
…iaskrgr Rollup of 3 pull requests Successful merges: - rust-lang#123490 (Refactor `panic_unwind/seh.rs` pointer use) - rust-lang#123704 (Tweak value suggestions in `borrowck` and `hir_analysis`) - rust-lang#123753 (compiletest: error when finding a trailing directive) r? `@ghost` `@rustbot` modify labels: rollup
…nieu Refactor `panic_unwind/seh.rs` pointer use * `x86` now conforms to strict-provenance * `x86_64` now uses the expose API (instead of `as` casts) * changed `ptr_t` from a type alias to a `repr(transparent)` struct for some extra type-safety * replaced the `ptr!` macro by methods on `ptr_t`, as there is now no reason (as far as I can see) anymore to use a macro On `x86_64` pointers in SEH are represented by 32-bit offsets from `__ImageBase`, so we can't use a pointer type. It might be possible to leak the provenance into the FFI by using a `MaybeUninit<u32>` instead of a `u32`, but that is a bit more involved than using expose, and I'm not sure that would be worth it.
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
@bors r+ |
Ai, only I can rebase/squash the commits into one before merge? |
Sure, just rebase and I will approve it again. @bors r- |
52b5868
to
f63d5d1
Compare
push hook took a while, but here it is. |
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (6bc9dcd): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 676.134s -> 676.794s (0.10%) |
x86
now conforms to strict-provenancex86_64
now uses the expose API (instead ofas
casts)ptr_t
from a type alias to arepr(transparent)
struct for some extra type-safetyptr!
macro by methods onptr_t
, as there is now no reason (as far as I can see) anymore to use a macroOn
x86_64
pointers in SEH are represented by 32-bit offsets from__ImageBase
, so we can't use a pointer type. It might be possible to leak the provenance into the FFI by using aMaybeUninit<u32>
instead of au32
, but that is a bit more involved than using expose, and I'm not sure that would be worth it.