Skip to content
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

Merged
merged 5 commits into from
Oct 21, 2024

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Sep 20, 2024

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

@rustbot
Copy link
Collaborator

rustbot commented Sep 20, 2024

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 20, 2024
@workingjubilee
Copy link
Member Author

workingjubilee commented Sep 20, 2024

Also cc @rust-lang/lang for your information, as y'all already FCPed this in rust-lang/rfcs#3391 (comment)

@workingjubilee workingjubilee added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 20, 2024
@workingjubilee

This comment was marked as resolved.

@@ -1,3 +1,4 @@
//@ build-pass
Copy link
Member

@Noratrieb Noratrieb Sep 20, 2024

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 :)

Copy link
Member Author

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.

Copy link
Member

@Noratrieb Noratrieb Sep 20, 2024

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

Copy link
Member Author

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.

Copy link
Member

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^^

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.)

Copy link
Member

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.

@Noratrieb
Copy link
Member

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 Option<T>

@workingjubilee
Copy link
Member Author

Oh, good catch!

@ehuss
Copy link
Contributor

ehuss commented Sep 20, 2024

@ehuss has raised the concern that the documentation updates are unfinished.

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

  1. Though it seems like those docs were missing a caveat that the ABI was not guaranteed for FFI, which I would expect this PR to then remove.

@workingjubilee
Copy link
Member Author

workingjubilee commented Sep 20, 2024

current TODOs:

@workingjubilee
Copy link
Member Author

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. labels Sep 20, 2024
@tmandry tmandry added T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 20, 2024
@tmandry
Copy link
Member

tmandry commented Sep 20, 2024

@rfcbot fcp merge

This completes stabilization of RFC 3391, which guarantees the layout of Option<T>, Result<T, ()>, and Result<(), T> where T is a nonzero type like Nonnull, function pointer, etc. to be the same as the underlying type.

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 extern "C" fn declarations as not being FFI safe.

This FCP serves as signoff that we are fine with fully stabilizing the RFC.

@rustbot label I-lang-nominated

@rfcbot
Copy link

rfcbot commented Sep 20, 2024

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.
See this document for info about what commands tagged team members can give me.

@rustbot rustbot added the I-lang-nominated Nominated for discussion during a lang team meeting. label Sep 20, 2024
@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Sep 20, 2024
@RalfJung
Copy link
Member

Update std docs for fn(...T) -> R: https://doc.rust-lang.org/stable/std/primitive.fn.html#abi-compatibility

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.

@workingjubilee
Copy link
Member Author

I'm happy-enough to just let that land.

@chorman0773
Copy link
Contributor

The RFC'd behaviour is PR'd to the reference in rust-lang/reference#1654

@rust-log-analyzer

This comment has been minimized.

@workingjubilee
Copy link
Member Author

workingjubilee commented Oct 19, 2024

Update to this, I

I have a draft for the actual layout test. This can land as-is and that test can be a followup, or this PR can wait for that.

Copy link
Member

@RalfJung RalfJung left a 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>);
Copy link
Member

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.

Copy link
Member Author

@workingjubilee workingjubilee Oct 21, 2024

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.

Copy link
Member

@RalfJung RalfJung Oct 21, 2024

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.

Copy link
Member Author

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

@workingjubilee workingjubilee force-pushed the clean-up-result-ffi-guarantees branch 2 times, most recently from 830ff7a to 7baf066 Compare October 21, 2024 07:45
@workingjubilee
Copy link
Member Author

Since I should rewrite the layout test to use the rustc_abi dump attribute anyways:

@bors r=RalfJung

@bors
Copy link
Contributor

bors commented Oct 21, 2024

📌 Commit 7baf066 has been approved by RalfJung

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 21, 2024
@bors
Copy link
Contributor

bors commented Oct 21, 2024

⌛ Testing commit 7baf066 with merge 3e33bda...

@BoxyUwU BoxyUwU assigned RalfJung and unassigned BoxyUwU Oct 21, 2024
@bors
Copy link
Contributor

bors commented Oct 21, 2024

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 3e33bda to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 21, 2024
@bors bors merged commit 3e33bda into rust-lang:master Oct 21, 2024
7 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Oct 21, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (3e33bda): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This 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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.5% [-0.5%, -0.5%] 2
All ❌✅ (primary) - - 0

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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.7% [3.7%, 3.7%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Cycles

Results (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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
8.1% [8.1%, 8.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 780.893s -> 782.557s (0.21%)
Artifact size: 333.66 MiB -> 333.66 MiB (0.00%)

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 21, 2024
…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`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 21, 2024
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`
@workingjubilee workingjubilee deleted the clean-up-result-ffi-guarantees branch October 21, 2024 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue. to-announce Announce this issue on triage meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking Issue for result_ffi_guarantees (RFC 3391)