Rename ProjectionPredicate and TraitPredicate - #161291
Conversation
|
HIR ty lowering was modified cc @fmease Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor changes to the core type system cc @lcnr changes to cc @lcnr Some changes occurred in compiler/rustc_sanitizers cc @rcvalle
cc @rust-lang/clippy Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt changes to the core type system cc @lcnr This PR changes rustc_public |
|
|
This comment has been minimized.
This comment has been minimized.
6fc9ceb to
169bd22
Compare
Rename `ProjectionPredicate` and `TraitPredicate` Part of rust-lang#107250 This deviates from the plan I described in rust-lang#107250 (comment). The reason is that I kept getting into the awkward situation where I would go into a function dealing with multiple predicate/clause kinds, and need to rename only the variables referring with the particular kind I was renaming. So now, the plan is to first rename only the types (this PR), and afterwards go into functions and rename all the variables in them at once. That would also allow splitting the work better, e.g. tackling one crate/subtree at a time. r? @oli-obk
…uwer Rollup of 8 pull requests Successful merges: - #154210 (fix: fix the capture behavior of `if let` in closures) - #156176 (Initial implementation of `FnPtr` trait) - #160767 (Unify E0117 foreign-trait label for ADT/primitive types with existing Slice/Array/Tuple handling) - #160489 (Adding diagnostic item markers for multiple fs functions and structs) - #161220 (bootstrap: Allow `./x fix --allow-dirty`) - #161291 (Rename `ProjectionPredicate` and `TraitPredicate`) - #161296 (Enable overflow checks in `rustc_thread_pool`) - #161304 (Rename test so it matches the issue)
Rename `ProjectionPredicate` and `TraitPredicate` Part of rust-lang#107250 This deviates from the plan I described in rust-lang#107250 (comment). The reason is that I kept getting into the awkward situation where I would go into a function dealing with multiple predicate/clause kinds, and need to rename only the variables referring with the particular kind I was renaming. So now, the plan is to first rename only the types (this PR), and afterwards go into functions and rename all the variables in them at once. That would also allow splitting the work better, e.g. tackling one crate/subtree at a time. r? @oli-obk
Rename `ProjectionPredicate` and `TraitPredicate` Part of rust-lang#107250 This deviates from the plan I described in rust-lang#107250 (comment). The reason is that I kept getting into the awkward situation where I would go into a function dealing with multiple predicate/clause kinds, and need to rename only the variables referring with the particular kind I was renaming. So now, the plan is to first rename only the types (this PR), and afterwards go into functions and rename all the variables in them at once. That would also allow splitting the work better, e.g. tackling one crate/subtree at a time. r? @oli-obk
|
|
This pull request was unapproved. This PR was contained in a rollup (#161337), which was unapproved. |
169bd22 to
7b5c709
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Fixed the issue, not sure what I should do now.. |
|
Yeah, if you only made trivial changes (which this diff seems to be), that's good :) |
Rename `ProjectionPredicate` and `TraitPredicate` Part of rust-lang#107250 This deviates from the plan I described in rust-lang#107250 (comment). The reason is that I kept getting into the awkward situation where I would go into a function dealing with multiple predicate/clause kinds, and need to rename only the variables referring with the particular kind I was renaming. So now, the plan is to first rename only the types (this PR), and afterwards go into functions and rename all the variables in them at once. That would also allow splitting the work better, e.g. tackling one crate/subtree at a time. r? @oli-obk
Rename `ProjectionPredicate` and `TraitPredicate` Part of rust-lang#107250 This deviates from the plan I described in rust-lang#107250 (comment). The reason is that I kept getting into the awkward situation where I would go into a function dealing with multiple predicate/clause kinds, and need to rename only the variables referring with the particular kind I was renaming. So now, the plan is to first rename only the types (this PR), and afterwards go into functions and rename all the variables in them at once. That would also allow splitting the work better, e.g. tackling one crate/subtree at a time. r? @oli-obk
…uwer Rollup of 16 pull requests Successful merges: - #159071 ([PAC] Encoder and hash (1/8)) - #161277 (bootstrap: Move all non-module items out of the crate root) - #161332 (Some `GlobalCtxt`/`Session` cleanups) - #161344 (Update the `rustc-perf` submodule) - #150931 (rustdoc: Always document `#[repr(transparent)]` if `#[rustc_pub_transparent]` is applied) - #160582 (Add `remove hidden_glob_reexports item breaks downstream` test) - #160876 (remove unwrap from write_mir_fn_graphviz) - #160927 (Enhance EII UI tests) - #161070 (fix arm homogeneous aggregate ABI) - #161236 (Download auto jobs in citool in parallel) - #161254 (Reserve capacity for 3% anon nodes) - #161283 (Tighten the language used for documenting `TargetOptions::llvm_abiname`) - #161291 (Rename `ProjectionPredicate` and `TraitPredicate`) - #161299 (Remove a bunch of unnecessary explicit lifetimes) - #161307 (make ARM maintainers pingable) - #161308 (Add regression test for rustc diagnostic to recognize variables in match guards)
Rename `ProjectionPredicate` and `TraitPredicate` Part of rust-lang#107250 This deviates from the plan I described in rust-lang#107250 (comment). The reason is that I kept getting into the awkward situation where I would go into a function dealing with multiple predicate/clause kinds, and need to rename only the variables referring with the particular kind I was renaming. So now, the plan is to first rename only the types (this PR), and afterwards go into functions and rename all the variables in them at once. That would also allow splitting the work better, e.g. tackling one crate/subtree at a time. r? @oli-obk
…uwer Rollup of 16 pull requests Successful merges: - #159071 ([PAC] Encoder and hash (1/8)) - #161068 (Ensure TLS accesses don't call the global allocator through panic (part 3) ) - #161332 (Some `GlobalCtxt`/`Session` cleanups) - #161344 (Update the `rustc-perf` submodule) - #150931 (rustdoc: Always document `#[repr(transparent)]` if `#[rustc_pub_transparent]` is applied) - #160582 (Add `remove hidden_glob_reexports item breaks downstream` test) - #160876 (remove unwrap from write_mir_fn_graphviz) - #160927 (Enhance EII UI tests) - #161070 (fix arm homogeneous aggregate ABI) - #161236 (Download auto jobs in citool in parallel) - #161254 (Reserve capacity for 3% anon nodes) - #161283 (Tighten the language used for documenting `TargetOptions::llvm_abiname`) - #161291 (Rename `ProjectionPredicate` and `TraitPredicate`) - #161299 (Remove a bunch of unnecessary explicit lifetimes) - #161307 (make ARM maintainers pingable) - #161308 (Add regression test for rustc diagnostic to recognize variables in match guards)
Part of #107250
This deviates from the plan I described in #107250 (comment). The reason is that I kept getting into the awkward situation where I would go into a function dealing with multiple predicate/clause kinds, and need to rename only the variables referring with the particular kind I was renaming. So now, the plan is to first rename only the types (this PR), and afterwards go into functions and rename all the variables in them at once. That would also allow splitting the work better, e.g. tackling one crate/subtree at a time.
r? @oli-obk