Uh oh!
There was an error while loading. Please reload this page.
Use wide pointers consistenly across the compiler - #131202
Conversation
rustbot
commented
Oct 3, 2024
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 |
jieyouxu
commented
Oct 3, 2024
@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. |
Urgau
commented
Oct 3, 2024
@jieyouxu actually, T-lang explicitly discussed |
jieyouxu
commented
Oct 3, 2024
Ok great, in that case this seems fine. |
jieyouxu
left a comment
There was a problem hiding this comment.
LGTM with some nits, incl. consts and enums that still refers to FAT_PTR.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
jieyouxu
commented
Oct 3, 2024
@rustbot author |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Urgau
commented
Oct 4, 2024
@rustbot ready |
jieyouxu
commented
Oct 4, 2024
@bors r+ rollup |
bors
commented
Oct 4, 2024
jieyouxu
commented
Oct 4, 2024
@bors rollup=maybe |
Uh oh!
There was an error while loading. Please reload this page.
jieyouxu
commented
Oct 4, 2024
Ah yeah. |
Urgau
commented
Oct 4, 2024
bors
commented
Oct 4, 2024
…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)