-
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
Implement std::marker::Tuple
, use it in extern "rust-call"
and Fn
-family traits
#99943
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
r? @thomcc (rust-highfive has picked a reviewer for you, use r? to override) |
r? compiler |
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #99948) made this pull request unmergeable. Please resolve the merge conflicts. |
This does need @rust-lang/libs-api and @rust-lang/lang review, but as long as all of it is still marked unstable, I don't think it needs an FCP. For my part, 👍 for lang and for libs-api, for the proposed surface area. Others should chime in as well if they have thoughts or concerns, though. |
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 we split this into parts? First part is just adding the Tuple trait and implementing it?
blocking on landing that other one |
Will this also fix the ICE in #57404? |
|
||
error: functions with the "rust-call" ABI must take a single non-self argument that is a tuple | ||
--> $DIR/issue-22565-rust-call.rs:9:5 | ||
| ^ `i32` is not a tuple |
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.
This span is weird.
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 we could probably pass the arg span into the obligation cause or something to make this better
| | ||
LL | extern "rust-call" fn a() {} | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| ^ |
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.
Could we keep the def_span
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.
yeah I think so
Yes, just checked. |
@cjgillot with this PR, that issue now reports:
instead of ICEing. |
…kh726 Implement `std::marker::Tuple` Split out from rust-lang#99943 (rust-lang#99943 (review)). Implements part of rust-lang/compiler-team#537 r? `@jackh726`
Now that #100251 has landed, seems this is now unblocked. |
Implement `std::marker::Tuple` Split out from #99943 (rust-lang/rust#99943 (review)). Implements part of rust-lang/compiler-team#537 r? `@jackh726`
0b4759e
to
52655b8
Compare
@bors try |
⌛ Trying commit 52655b8d45d36b35cf6b3bcc0174f7aa45406255 with merge 388b725dea7416978ab58ab1f908139d530308a7... |
@bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (7eef946): 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.
|
…mpls, r=compiler-errors Fix `const_fn_trait_ref_impl`, add test for it rust-lang#99943 broke `#[feature(const_fn_trait_ref_impl)]`, this PR fixes this and adds a test for it. r? `@fee1-dead`
Delta here appears to be noise (but is an improvement anyway). |
…mpls, r=compiler-errors Fix `const_fn_trait_ref_impl`, add test for it rust-lang#99943 broke `#[feature(const_fn_trait_ref_impl)]`, this PR fixes this and adds a test for it. r? ``@fee1-dead``
…mpls, r=compiler-errors Fix `const_fn_trait_ref_impl`, add test for it rust-lang#99943 broke `#[feature(const_fn_trait_ref_impl)]`, this PR fixes this and adds a test for it. r? ```@fee1-dead```
…mpls, r=compiler-errors Fix `const_fn_trait_ref_impl`, add test for it rust-lang#99943 broke `#[feature(const_fn_trait_ref_impl)]`, this PR fixes this and adds a test for it. r? ````@fee1-dead````
- Caused by `Fn` and related traits now requiring their arguments to impl `Tuple`. (PR: rust-lang/rust#99943) - This PR adds constraints where needed to also require `Tuple` to be implemented. - Also the feature gate `const_fn` no longer exists and was causing a compilation error, and this PR also removes its usage. - Not very familiar with the internals of this crate, so please let me know if this PR should fix anything differently!
Implement support for the `Tuple` trait Necessary to due to new trait bounds required by rust-lang/compiler-team#537 / rust-lang/rust#99943. r? `@jackh726`
Implement `std::marker::Tuple` Split out from #99943 (rust-lang/rust#99943 (review)). Implements part of rust-lang/compiler-team#537 r? `@jackh726`
Implement `std::marker::Tuple` Split out from #99943 (rust-lang/rust#99943 (review)). Implements part of rust-lang/compiler-team#537 r? `@jackh726`
Implements rust-lang/compiler-team#537
I made a few opinionated decisions in this implementation, specifically:
extern "rust-call"
on fn items during wfcheck,Tuple
marker trait behind its own feature, instead of grouping it into (e.g.)unboxed_closures
.Still needing to be done:
extern "rust-call"
fn
-ptrs are well-formed only if they have 1/2 args and the second one implementsTuple
. (Doing this would fix ICE in ICE when transmuting to extern "rust-call" fn() #66696.)impl
s of theTuple
trait, kinda likeSized
.Tuple
trait built-in impl for chalk, so that chalkification tests are un-broken.Open questions:
Fixes #99820