-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Use wide pointers consistenly across the compiler #131202
Conversation
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred in compiler/rustc_codegen_gcc This PR changes Stable MIR cc @oli-obk, @celinval, @ouz-a Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri |
@Urgau is there any kind of meeting or decision we can look at that shows T-lang preferred "wide pointers" over "fat pointers"? |
A part from the indirect usage described in the PR description, I don't think so (at least I haven't found one). I think it just sort of happened. cc @traviscross |
Yeah personally I'm fine with sticking with one of "wide pointers" or "fat pointers" instead of mixing both terms, but I think we want this to be an explicit T-lang decision of migrating over to "wide pointers" with a clear definition in the reference that users can look at if they want clarity of what that concretely means. For T-langDo we want to use "wide pointers" terminology over "fat pointers"? Is this term documented in the Reference? Note that the Reference seems to use "wide pointers" in at least https://doc.rust-lang.org/reference/expressions/operator-expr.html?highlight=wide#semantics. @rustbot label +I-lang-nominated +I-lang-easy-decision If @traviscross knows that T-lang already prefers "wide pointers" over "fat pointers" then this is fine. |
25a1bd3
to
2de4f21
Compare
@jieyouxu actually, T-lang explicitly discussed |
Ok great, in that case this seems fine. |
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.
LGTM with some nits, incl. consts and enums that still refers to FAT_PTR
.
@rustbot author |
2de4f21
to
c2f8071
Compare
@rustbot ready |
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.
Thanks!
@bors r+ rollup |
@bors rollup=maybe |
Ah yeah. |
c2f8071
to
018ba05
Compare
…llaumeGomez Rollup of 4 pull requests Successful merges: - rust-lang#131034 (Implement RFC3695 Allow boolean literals as cfg predicates) - rust-lang#131202 (Use wide pointers consistenly across the compiler) - rust-lang#131230 (Enable `--no-sandbox` option by default for rustdoc GUI tests) - rust-lang#131232 (Week off of reviews to focus on docs) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#131202 - Urgau:wide-ptrs-compiler, r=jieyouxu Use wide pointers consistenly across the compiler This PR replace every use of "fat pointer" for the more recent "wide pointer" terminology. Since some time T-lang as preferred the "wide pointer" terminology, as can be seen on [the last RFCs](https://github.com/search?q=repo%3Arust-lang%2Frfcs+%22wide+pointer%22&type=code), on some [lints](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#ambiguous-wide-pointer-comparisons), but also in [the reference](https://doc.rust-lang.org/stable/reference/expressions/operator-expr.html?highlight=wide%20pointer#pointer-to-pointer-cast). Currently we have a [mix of both](https://github.com/search?q=repo%3Arust-lang%2Frust+%22wide+pointer%22&type=code) (including in error messages), which isn't great, but with this PR no more. r? `@jieyouxu` (feel free to re-roll)
This PR replace every use of "fat pointer" for the more recent "wide pointer" terminology.
As T-lang as preferred the "wide pointer" terminology, as can be seen on the last RFCs, on some lints, but also in the reference.
Currently we have a mix of both (including in error messages), which isn't great, but with this PR no more.
r? @jieyouxu (feel free to re-roll)