Consider confirming that the TypeIds used in a crate are unique
#17179
Comments
|
I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized. This issue has been moved to the RFCs repo: rust-lang/rfcs#664 |
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
May 19, 2024
Fix source_range for INT_NUMBER in completion fix rust-lang#17179. Previously r-a use `TextRange::empty(self.position.offset)` as `source_range` for `INT_NUMBER`, so the `text_edit` would always be an insertion, which results in rust-lang#17179. This PR changed it by using `text_range` of `original_token` (same as `IDENT`).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If two
TypeIds of different types collide, we can get unsoundness, sinceAnyrelies onTypeIdbeing unique for safe downcasts. We could have the compiler double check that anyTypeIds it computes haven't occured before from another type.The text was updated successfully, but these errors were encountered: