bjoernager/rust
bjoernager/rust
1
Fork 0
Code 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

18
compiler/rustc_hir_analysis/src/check/wfcheck.rs
View file

@ -2,6 +2,7 @@ use crate::autoderef::Autoderef;
use crate::collect::CollectItemTypesVisitor;
use crate::constrained_generic_params::{identify_constrained_generic_params, Parameter};
use crate::errors;
use crate::fluent_generated as fluent;
use hir::intravisit::Visitor;
use rustc_ast as ast;
@ -1636,10 +1637,6 @@ fn check_fn_or_method<'tcx>(
}
}
const HELP_FOR_SELF_TYPE: &str = "consider changing to `self`, `&self`, `&mut self`, `self: Box<Self>`, \
`self: Rc<Self>`, `self: Arc<Self>`, or `self: Pin<P>` (where P is one \
of the previous types except `Self`)";
#[instrument(level = "debug", skip(wfcx))]
fn check_method_receiver<'tcx>(
wfcx: &WfCheckingCtxt<'_, 'tcx>,
@ -1675,7 +1672,7 @@ fn check_method_receiver<'tcx>(
if tcx.features().arbitrary_self_types {
if !receiver_is_valid(wfcx, span, receiver_ty, self_ty, true) {
// Report error; `arbitrary_self_types` was enabled.
return Err(e0307(tcx, span, receiver_ty));
return Err(tcx.dcx().emit_err(errors::InvalidReceiverTy { span, receiver_ty }));
}
} else {
if !receiver_is_valid(wfcx, span, receiver_ty, self_ty, false) {
@ -1690,24 +1687,17 @@ fn check_method_receiver<'tcx>(
the `arbitrary_self_types` feature",
),
)
.with_help(HELP_FOR_SELF_TYPE)
.with_help(fluent::hir_analysis_invalid_receiver_ty_help)
.emit()
} else {
// Report error; would not have worked with `arbitrary_self_types`.
e0307(tcx, span, receiver_ty)
tcx.dcx().emit_err(errors::InvalidReceiverTy { span, receiver_ty })
});
}
}
Ok(())
}
fn e0307(tcx: TyCtxt<'_>, span: Span, receiver_ty: Ty<'_>) -> ErrorGuaranteed {
struct_span_code_err!(tcx.dcx(), span, E0307, "invalid `self` parameter type: {receiver_ty}")
.with_note("type of `self` must be `Self` or a type that dereferences to it")
.with_help(HELP_FOR_SELF_TYPE)
.emit()
}
/// Returns whether `receiver_ty` would be considered a valid receiver type for `self_ty`. If
/// `arbitrary_self_types` is enabled, `receiver_ty` must transitively deref to `self_ty`, possibly
/// through a `*const/mut T` raw pointer. If the feature is not enabled, the requirements are more

10
compiler/rustc_hir_analysis/src/errors.rs
View file

@ -1666,3 +1666,13 @@ pub struct NonConstRange {
#[primary_span]
pub span: Span,
}
#[derive(Diagnostic)]
#[diag(hir_analysis_invalid_receiver_ty, code = E0307)]
#[note]
#[help(hir_analysis_invalid_receiver_ty_help)]
pub struct InvalidReceiverTy<'tcx> {
#[primary_span]
pub span: Span,
pub receiver_ty: Ty<'tcx>,
}