-
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
Constify TypeId
ordering impls
#101698
Constify TypeId
ordering impls
#101698
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @scottmcm (or someone else) soon. Please see the contribution instructions for more information. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
note: impl defined here, but it is not `const` | ||
--> $SRC_DIR/core/src/any.rs:LL:COL | ||
| | ||
LL | impl const PartialEq for TypeId { |
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.
Isn't this a bit weird? “impl defined here but it is not const” but it is const as shown?
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.
Yes that is because this test doesn't use the const_trait_impl
feature flag.
That always leads to this error if used this way.
The same error happens in src/test/ui/consts/const_cmp_type_id.rs
if #![feature(const_trait_impl)]
is removed, this is probably more of an issue in const_trait_impl
than here.
TypeId
ordering implsTypeId
ordering impls
Makes public stable implementations of Ordering traits unstably const, so @rustbot label +T-libs-api -T-libs |
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.
Diff LGTM.
Nominating for team discussions. The ordering of |
Some additional background that may help in the discussion: I have created a crate called trait_cast_rs. It provides a custom Internally it has a const slice of function pointers with their associated This has the advantage that the array must not be sorted on every program launch and the lookup slice can be a constant. I currently use |
library/core/src/any.rs
Outdated
#[stable(feature = "rust1", since = "1.0.0")] | ||
pub struct TypeId { | ||
t: u64, | ||
} | ||
|
||
#[stable(feature = "rust1", since = "1.0.0")] | ||
impl StructuralPartialEq for TypeId {} |
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.
Per T-libs (see #102371 (comment)) we're going to wait on derive_const
(or similar) before accepting more changes like this to library.
@rustbot label +S-Blocked
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.
Please do not make TypeId
"structural match" - instead, that needs to be removed - as per e.g. #77125 (comment) - sadly the one PR trying to do it was rejected and I'm not seeing a replacement just removing "structural match":
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 impl StructualPartialEq
was added because the test for issue-73976 failed as it used matches!
.
It could be changed to a normal ==
though, but removing the structural match would be a breaking change (nightly only since const_type_id
isn't stable yet).
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've added a commit that does those changes.
We discussed this in the lang meeting this week. It didn't result in anything that needs to block this for nightly, but I've added a note to the tracking issue that this precludes some possible implementations, and thus stabilizing it would need to be considered very carefully. |
Nominating this for the compiler team for input, since the compiler is the one generating the type ids. So question for the compiler team: will this get in the way of any future plans there might be with future typeid implementations? (And if so, is that a problem?) |
Issue was discussed in T-compiler meeting, I'm leaving here some notes; more will probably follow-up in this issue to reach a wider audience. Leaving I-compiler-nominated for the moment. |
If you want the hash, you should have never You can do this on stable Rust, and it should work all the way back to 1.0 AFAIK, so it's a good option to consider. |
Why did the CI not run? |
Hmm, I'll try to re-kick it. @bors r- |
@bors r=scottmcm |
📌 Commit 73f8dc788b0e63d3ed4fd88fbbfd9ffa70c8acb9 has been approved by It is now in the queue for this repository. |
Should probably r- untill CI passes |
@bors r- |
@scottmcm can you r+? |
@bors r=scottmcm |
Rollup of 5 pull requests Successful merges: - rust-lang#101698 (Constify `TypeId` ordering impls) - rust-lang#106148 (Fix unused_parens issue for higher ranked function pointers) - rust-lang#106922 (Avoid unsafe code in `to_ascii_[lower/upper]case()`) - rust-lang#106951 (Remove ineffective run of SimplifyConstCondition) - rust-lang#106962 (Fix use suggestion span) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
`core::any::TypeId` implements `const PartialEq` as of [rust-lang/rust#101698][1]. [1]: rust-lang/rust#101698
…atch, r=dtolnay Remove structural match from `TypeId` As per rust-lang#99189 (comment). > Removing the structural equality might make sense, but is a breaking change that'd require a libs-api FCP. rust-lang#99189 (comment) > Landing this PR now (well, mainly the "remove structural equality" part) would unblock `const fn` `TypeId::of`, since we only postponed that because we were guaranteeing too much. See also rust-lang#99189, rust-lang#101698
…ch, r=dtolnay Remove structural match from `TypeId` As per rust-lang#99189 (comment). > Removing the structural equality might make sense, but is a breaking change that'd require a libs-api FCP. rust-lang#99189 (comment) > Landing this PR now (well, mainly the "remove structural equality" part) would unblock `const fn` `TypeId::of`, since we only postponed that because we were guaranteeing too much. See also rust-lang#99189, rust-lang#101698
Tracking issue: #101871
Adding const ordering to
TypeId
allows rtti crates to optimize some casting scenarios (without transmuting tou64
). This would also prevent these crates from breaking if the underlying type is changed fromu64
to something different.Feature gate:
#![feature(const_cmp_type_id)]