Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

@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%)

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking Issue for result_ffi_guarantees (RFC 3391)