Consistent `Handler` naming

[nnethercote]

Proposal

rustc diagnostics are issued through the Handler type. There are some problems.

• Handler isn't a good name. It's not descriptive, it could be used for almost anything.
• Fields/functions/arguments/locals of type Handler have many different names: span_diagnostic, diagnostic, sd, diag_handler, err_handler, and occasionally, handler. These names occur a lot. I suspect the heavy use of diagnostic/diag is for historical reasons, and made more sense in the past. But today, diag/diagnostic is heavily used for Diagnostics and DiagnosticBuilders, so is a poor choice for Handler things.
• EarlyErrorHandler is a more descriptive name than Handler, but is quite long. Plus "Diagnostic" would be better than "Error", given that it issues non-error diagnostics such as warnings.
• handler is used for values of type EarlyErrorHandler, but that potentially overlaps with values of type Handler, and there are some functions with both a Handler and an EarlyErrorHandler in scope.

After some discussion on Zulip, the proposal is to rename the following types:

• Handler → DiagCtxt
• HandlerInner → DiagCtxtInner
• EarlyErrorHandler → EarlyDiagCtxt
• HandlerFlags → DiagCtxtFlags

And the following non-types:

• ParseSess: span_diagnostic → dcx
• Session: diagnostic() → dcx()
• Parser: diagnostic() → dcx()
• ParseSess: with_span_handler() → with_dcx()
• AstValidator: err_handler() → dcx()
• ShowSpanVisitor: span_diagnostic → dcx
• CodegenContext: create_diag_handler() → create_dcx()
• UnstableOptions: diagnostic_handler_flags() → dcx_flags()
• SilentEmitter::fatal_handler → fatal_dcx
• new_handler() → new_dcx()
• default_handler() -> default_dcx()
• Locals/args/fields: {diag,diagnostic,span_diagnostic,sd,diag_handler,handler} → dcx (for Handler values)
• Locals/args/fields: handler → early_dcx (for EarlyErrorHandler values)
• '__diagnostic_handler_sess → 'sess

(This is an exhaustive list, or very close to one.)

DiagCtxt/dcx are more descriptive names than Handler/handler, and mirror names like TyCtxt/tcx. They are also short, which is good for these names which are used a lot.

Alternatives

DiagCx/EarlyDiagCx are also possible for the type names, and would match types like FunctionCx, CodegenCx.

Mentors or Reviewers

I can do the work; as mentioned above, I already have a draft implementation.

@compiler-errors or @estebank might be suitable reviewers.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[davidtwco]

@rustbot second

[nnethercote]

Ten days have passed without objection. I have made the changes in rust-lang/rust#119063.

[nnethercote]

rust-lang/rust#119063 has merged.

[apiraino]

@rustbot label -final-comment-period +major-change-accepted