bjoernager/rust
bjoernager/rust
1
Fork 0
Code Issues Pull requests Activity

Auto merge of #124356 - fmease:fewer-magic-numbers-in-names, r=lcnr

Browse source 
Cleanup: Replace item names referencing GitHub issues or error codes with something more meaningful

**lcnr** in https://github.com/rust-lang/rust/pull/117164#pullrequestreview-1969935387:

> […] while I know that there's precendent to name things `Issue69420`, I really dislike this as it requires looking up the issue to figure out the purpose of such a variant. Actually referring to the underlying issue, e.g. `AliasMayNormToUncovered` or whatever and then linking to the issue in a doc comment feels a lot more desirable to me. We should ideally rename all the functions and enums which currently use issue numbers.

I've grepped through `compiler/` like crazy and think that I've found all instances of this pattern.
However, I haven't renamed `compute_2229_migrations_*`. Should I?

The first commit introduces an abhorrent and super long name for an item because naming is hard but also scary looking / unwelcoming names are good for things related to temporary-ish backcompat hacks. I'll let you discover it by yourself.

Contains a bit of drive-by cleanup and a diag migration bc that was the simplest option.

r? lcnr or compiler
This commit is contained in:
bors 2024-05-01 00:04:36 +00:00
commit f5355b93ba
27 changed files with 112 additions and 106 deletions
Download patch file Download diff file Expand all files Collapse all files

2
compiler/rustc_trait_selection/src/traits/select/mod.rs
View file

@ -2001,7 +2001,7 @@ impl<'tcx> SelectionContext<'_, 'tcx> {
// any associated items and there are no where-clauses.
//
// We can just arbitrarily drop one of the impls.
Some(ty::ImplOverlapKind::Issue33140) => {
Some(ty::ImplOverlapKind::FutureCompatOrderDepTraitObjects) => {
assert_eq!(other.evaluation, victim.evaluation);
DropVictim::Yes
}

4
compiler/rustc_trait_selection/src/traits/specialize/mod.rs
View file

@ -453,7 +453,7 @@ fn report_conflicting_impls<'tcx>(
overlap.trait_ref.print_trait_sugared(),
overlap.self_ty.map_or_else(String::new, |ty| format!(" for type `{ty}`")),
match used_to_be_allowed {
Some(FutureCompatOverlapErrorKind::Issue33140) => ": (E0119)",
Some(FutureCompatOverlapErrorKind::OrderDepTraitObjects) => ": (E0119)",
_ => "",
}
)
@ -480,7 +480,7 @@ fn report_conflicting_impls<'tcx>(
}
Some(kind) => {
let lint = match kind {
FutureCompatOverlapErrorKind::Issue33140 => ORDER_DEPENDENT_TRAIT_OBJECTS,
FutureCompatOverlapErrorKind::OrderDepTraitObjects => ORDER_DEPENDENT_TRAIT_OBJECTS,
FutureCompatOverlapErrorKind::LeakCheck => COHERENCE_LEAK_CHECK,
};
tcx.node_span_lint(

6
compiler/rustc_trait_selection/src/traits/specialize/specialization_graph.rs
View file

@ -11,7 +11,7 @@ pub use rustc_middle::traits::specialization_graph::*;
#[derive(Copy, Clone, Debug)]
pub enum FutureCompatOverlapErrorKind {
Issue33140,
OrderDepTraitObjects,
LeakCheck,
}
@ -150,10 +150,10 @@ impl<'tcx> Children {
{
match overlap_kind {
ty::ImplOverlapKind::Permitted { marker: _ } => {}
ty::ImplOverlapKind::Issue33140 => {
ty::ImplOverlapKind::FutureCompatOrderDepTraitObjects => {
*last_lint_mut = Some(FutureCompatOverlapError {
error: create_overlap_error(overlap),
kind: FutureCompatOverlapErrorKind::Issue33140,
kind: FutureCompatOverlapErrorKind::OrderDepTraitObjects,
});
}
}