-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Finish stabilization of result_ffi_guarantees
#130628
Finish stabilization of result_ffi_guarantees
#130628
Conversation
Also cc @rust-lang/lang for your information, as y'all already FCPed this in rust-lang/rfcs#3391 (comment) |
This comment was marked as resolved.
This comment was marked as resolved.
@@ -1,3 +1,4 @@ | |||
//@ build-pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a test for your own custom result-like type here to ensure that it's not special cased to Result
?
additionally, do we have tests that guarantee that, you know, this guarantee actually holds for various examples? would be good to have them :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RFC does not actually extend beyond Result, actually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well then improper_ctypes is implemented incorrectly, because it allows all result-like enums. the comment above the feature declaration also says result-like
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to write more tests anyways, mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, we'd need to make sure what we actually want to guarantee before writing tests or changing the lint^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well then improper_ctypes is implemented incorrectly, because it allows all result-like enums. the comment above the feature declaration also says result-like
Hm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i have been informed and see in the code that it also allows all option-like enums so... yolo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The feature description should certainly at least be correct here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic about "Option-like types" is ooooold, it exists at least Since Rust 1.5 where it got moved in this PR.
(There's also a "FIXME: This duplicates code in trans" there, which still exists, and which I have no idea if it is still true -- it is unclear to me where that duplicate code would be and what it would do.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the original logic for recognizing Option-like types was added when the lint was originally implemented, in 25f9534. It was just always carried over since then.
So... I think for Result
we don't want this, we want to specifically recognize that type. And probably for Option
, too, but that's a different PR.
https://doc.rust-lang.org/stable/std/primitive.fn.html#abi-compatibility, our "most canonical" place to put ABI docs, isn't updated yet, it only mentions |
Oh, good catch! |
To repeat my answer in the issue, I think if std's Result docs are correct1, then that should be fine for now. The Reference docs are lagging and work is being done to catch up, but doesn't need to block anything here. Footnotes
|
current TODOs:
|
@rustbot author |
@rfcbot fcp merge This completes stabilization of RFC 3391, which guarantees the layout of These semantics were already documented prematurely without lang FCP in #124870. The effect of this RFC appears to be to stop linting on such types in This FCP serves as signoff that we are fine with fully stabilizing the RFC. @rustbot label I-lang-nominated |
Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
Ah, I now have a separate PR for that before I saw you had this on your list: #130653. Feel free to cherry-pick that commit into your PR an close mine. |
I'm happy-enough to just let that land. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me with comment nit
fn result_transparent_struct_t(x: Result<TransparentStruct<num::NonZero<u8>>, ()>); | ||
fn result_transparent_enum_t(x: Result<TransparentEnum<num::NonZero<u8>>, ()>); | ||
fn result_phantom_t(x: Result<num::NonZero<u8>, std::marker::PhantomData<()>>); | ||
fn result_1zst_exhaustive_no_variant_t(x: Result<num::NonZero<u8>, Z>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, we allow this even if the "unit" variant is an empty enum? I didn't expect that... but I guess an empty enum is a 1-ZST so makes sense. For repr(transparent)
it may have been a mistake to treat uninhabited types as 1-ZST but this is not the right place or time to litigate that issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we would probably want to accept this code whether or not the other variant is uninhabited, because we allow NonNull<T> where T: Sized
in FFI in general. Right? But yes, a topic for discussion elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well that would require arguing that Result<T, !>
is kinda like a transparent newtype around T
. So far, we don't guarantee that.
But I agree the lint matches the FCP here. We'll have to extend the ABI compat tests (in tests/ui/abi/compatibility.rs
and in Miri) to ensure these actually have the ABI we want, but I am fairly sure they do so that can be a follow-up PR. Miri anyway currently hard-codes our Option
/Result
type and needs to be adjusted for the "Option-like" definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh lol I didn't even realize abi/compatibility.rs exists. nice, that's convenient
830ff7a
to
7baf066
Compare
Since I should rewrite the layout test to use the @bors r=RalfJung |
☀️ Test successful - checks-actions |
Finished benchmarking commit (3e33bda): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (secondary 3.7%)This 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.
CyclesResults (secondary 8.1%)This 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: 780.893s -> 782.557s (0.21%) |
…cross update ABI compatibility docs for new option-like rules Documents the rules decided [here](rust-lang#130628 (comment)) for our ABI compatibility rules. Long-term this should be moved to the reference, but for now this is what we got. Cc `@rust-lang/lang` `@rust-lang/opsem`
Rollup merge of rust-lang#132003 - RalfJung:abi-compat-docs, r=traviscross update ABI compatibility docs for new option-like rules Documents the rules decided [here](rust-lang#130628 (comment)) for our ABI compatibility rules. Long-term this should be moved to the reference, but for now this is what we got. Cc `@rust-lang/lang` `@rust-lang/opsem`
update ABI compatibility docs for new option-like rules Documents the rules decided [here](rust-lang/rust#130628 (comment)) for our ABI compatibility rules. Long-term this should be moved to the reference, but for now this is what we got. Cc `@rust-lang/lang` `@rust-lang/opsem`
…=compiler-errors abi/compatibility: also test Option-like types Adds tests for the decision [here](rust-lang#130628 (comment)). Cc `@workingjubilee`
…=compiler-errors abi/compatibility: also test Option-like types Adds tests for the decision [here](rust-lang#130628 (comment)). Cc ``@workingjubilee``
Rollup merge of rust-lang#132002 - RalfJung:abi-compat-option-like, r=compiler-errors abi/compatibility: also test Option-like types Adds tests for the decision [here](rust-lang#130628 (comment)). Cc ``@workingjubilee``
…wiser miri: update ABI compat checks to accept Option-like types This implements the t-lang decision described [here](rust-lang#130628 (comment)). Fixes rust-lang/miri#3983
Rollup merge of rust-lang#132057 - RalfJung:miri-abi-compat, r=wesleywiser miri: update ABI compat checks to accept Option-like types This implements the t-lang decision described [here](rust-lang#130628 (comment)). Fixes rust-lang/miri#3983
The internal linting has been changed, so all that is left is making sure we stabilize what we want to stabilize.
Closes #110503
cc @ehuss @Lokathor