Diag in rustc_errors - Rust (original) (raw)

pub struct Diag<'a, G: EmissionGuarantee = ErrorGuaranteed> {
    pub dcx: DiagCtxtHandle<'a>,
    diag: Option<Box<DiagInner>>,
    _marker: PhantomData<G>,
}

Expand description

Used for emitting structured error messages and other diagnostic information. Wraps a DiagInner, adding some useful things.

The dcx field, allowing it to (a) emit itself, and (b) do a drop check that it has been emitted or cancelled.
The EmissionGuarantee, which determines the type returned from emit.

Each constructed Diag must be consumed by a function such as emit,cancel, delay_as_bug, or into_diag. A panic occurs if a Diagis dropped without being consumed by one of these functions.

If there is some state in a downstream crate you would like to access in the methods of Diag here, consider extending DiagCtxtFlags.

Why the Option? It is always Some until the Diag is consumed viaemit, cancel, etc. At that point it is consumed and replaced withNone. Then drop checks that it is None; if not, it panics because a diagnostic was built but not used.

Why the Box? DiagInner is a large type, and Diag is often used as a return value, especially within the frequently-used PResult type. In theory, return value optimization (RVO) should avoid unnecessary copying. In practice, it does not (at the time of writing).

Allow moving diagnostics between different error tainting contexts

Creates a new Diag with an already constructed diagnostic.

Delay emission of this diagnostic as a bug.

This can be useful in contexts where an error indicates a bug but typically this only happens when other compilation errors have already happened. In those cases this can be used to defer emission of this diagnostic as a bug in the compiler only if no other errors have been emitted.

In the meantime, though, callsites are required to deal with the “bug” locally in whichever way makes the most sense.

Appends a labeled span to the diagnostic.

Labels are used to convey additional context for the diagnostic’s primary span. They will be shown together with the original diagnostic’s span, not with spans added byspan_note, span_help, etc. Therefore, if the primary span is not displayable (because the span is DUMMY_SP or the source code isn’t found), labels will not be displayed either.

Implementation-wise, the label span is pushed onto the MultiSpan that was created when the diagnostic was constructed. However, the label span is not considered a“primary span”; only the Span supplied when creating the diagnostic is primary. See Diag::span_label().

Appends a labeled span to the diagnostic.

Labels are used to convey additional context for the diagnostic’s primary span. They will be shown together with the original diagnostic’s span, not with spans added byspan_note, span_help, etc. Therefore, if the primary span is not displayable (because the span is DUMMY_SP or the source code isn’t found), labels will not be displayed either.

Implementation-wise, the label span is pushed onto the MultiSpan that was created when the diagnostic was constructed. However, the label span is not considered a“primary span”; only the Span supplied when creating the diagnostic is primary. See Diag::span_label().

Add a note attached to this diagnostic. See Diag::note().

Add a note attached to this diagnostic. See Diag::note().

This is like Diag::note(), but it’s only printed once.

Prints the span with a note above it. This is like Diag::note_once(), but it gets its own span.

Add a warning attached to this diagnostic. See Diag::warn().

Add a warning attached to this diagnostic. See Diag::warn().

Prints the span with a warning above it. This is like Diag::warn(), but it gets its own span.

Add a help message attached to this diagnostic. See Diag::help().

Add a help message attached to this diagnostic. See Diag::help().

This is like Diag::help(), but it’s only printed once.

Add a help message attached to this diagnostic with a customizable highlighted message.

Add a help message attached to this diagnostic with a customizable highlighted message.

Prints the span with some help above it. This is like Diag::help(), but it gets its own span.

Disallow attaching suggestions to this diagnostic. Any suggestions attached e.g. with the span_suggestion_* methods (before and after the call to disable_suggestions) will be ignored.

Prevent new suggestions from being added to this diagnostic.

Suggestions added before the call to .seal_suggestions() will be preserved and new suggestions will be ignored.

Helper for pushing to self.suggestions.

A new suggestion is added if suggestions are enabled for this diagnostic. Otherwise, they are ignored.

Show a suggestion that has multiple parts to it. In other words, multiple changes need to be applied as part of this suggestion. See Diag::multipart_suggestion().

Show a suggestion that has multiple parts to it. In other words, multiple changes need to be applied as part of this suggestion. See Diag::multipart_suggestion().

Show a suggestion that has multiple parts to it, always as its own subdiagnostic. In other words, multiple changes need to be applied as part of this suggestion.

Prints out a message with for a multipart suggestion without showing the suggested code.

This is intended to be used for suggestions that are obvious in what the changes need to be from the message, showing the span label inline would be visually unpleasant (marginally overlapping spans or multiline spans) and showing the snippet window wouldn’t improve understandability.

Prints out a message with a suggested edit of the code.

In case of short messages and a simple suggestion, rustc displays it as a label:

try adding parentheses: `(tup.0).1`

The message

should not end in any punctuation (a : is added automatically)
should not be a question (avoid language like “did you mean”)
should not contain any phrases like “the following”, “as shown”, etc.
may look like “to do xyz, use” or “to do xyz, use abc”
may contain a name of a function, variable, or type, but not whole expressions

See CodeSuggestion for more information. See Diag::span_suggestion().

Prints out a message with a suggested edit of the code.

In case of short messages and a simple suggestion, rustc displays it as a label:

try adding parentheses: `(tup.0).1`

The message

should not end in any punctuation (a : is added automatically)
should not be a question (avoid language like “did you mean”)
should not contain any phrases like “the following”, “as shown”, etc.
may look like “to do xyz, use” or “to do xyz, use abc”
may contain a name of a function, variable, or type, but not whole expressions

See CodeSuggestion for more information. See Diag::span_suggestion().

Prints out a message with multiple suggested edits of the code, where each edit consists of multiple parts. See also Diag::multipart_suggestion().

Prints out a message with a suggested edit of the code. If the suggestion is presented inline, it will only show the message and not the suggestion.

See CodeSuggestion for more information. See Diag::span_suggestion_short().

Prints out a message with a suggested edit of the code. If the suggestion is presented inline, it will only show the message and not the suggestion.

See CodeSuggestion for more information. See Diag::span_suggestion_short().

Prints out a message for a suggestion without showing the suggested code.

This is intended to be used for suggestions that are obvious in what the changes need to be from the message, showing the span label inline would be visually unpleasant (marginally overlapping spans or multiline spans) and showing the snippet window wouldn’t improve understandability.

Adds a suggestion to the JSON output that will not be shown in the CLI.

This is intended to be used for suggestions that are very obvious in what the changes need to be from the message, but we still want other tools to be able to apply them. See Diag::tool_only_span_suggestion().

Adds a suggestion to the JSON output that will not be shown in the CLI.

This is intended to be used for suggestions that are very obvious in what the changes need to be from the message, but we still want other tools to be able to apply them. See Diag::tool_only_span_suggestion().

Add a subdiagnostic from a type that implements Subdiagnostic (seerustc_macros::Subdiagnostic). Performs eager translation of any translatable messages used in the subdiagnostic, so suitable for use with repeated messages (i.e. re-use of interpolated variables).

Fluent variables are not namespaced from each other, so whenDiagnostics and Subdiagnostics use the same variable name, one value will clobber the other. Eagerly translating the diagnostic uses the variables defined right then, before the clobbering occurs.

Helper function that takes a SubdiagMessage and returns a DiagMessage by combining it with the primary message of the diagnostic (if translatable, otherwise it just passes the user’s string along).

Convenience function for internal use, clients should use one of the public methods above.

Used by proc_macro_server for implementing server::Diagnostic.

Convenience function for internal use, clients should use one of the public methods above.

Takes the diagnostic. For use by methods that consume the Diag: emit,cancel, etc. Afterwards, drop is the only code that will be run onself.

This method allows us to access the path of the file where “long types” are written to.

When calling Diag::emit, as part of that we will check if a long_ty_path has been set, and if it has been then we add a note mentioning the file where the “long types” were written to.

When calling tcx.short_string() after a Diag is constructed, the preferred way of doing so is tcx.short_string(ty, diag.long_ty_path()). The diagnostic itself is the one that keeps the existence of a “long type” anywhere in the diagnostic, so the note telling the user where we wrote the file to is only printed once at most, and it makes it much harder to forget to set it.

If the diagnostic hasn’t been created before a “short ty string” is created, then you should ensure that this method is called to set it *diag.long_ty_path() = path.

As a rule of thumb, if you see or add at least one tcx.short_string() call anywhere, in a scope, diag.long_ty_path() should be called once somewhere close by.

Most emit_producing_guarantee functions use this as a starting point.

ErrorGuaranteed::emit_producing_guarantee uses this.

Emit and consume the diagnostic.

Emit the diagnostic unless delay is true, in which case the emission will be delayed as a bug.

See emit and delay_as_bug for details.

Cancel and consume the diagnostic. (A diagnostic must either be emitted or cancelled or it will panic when dropped).

See DiagCtxt::stash_diagnostic for details.

Delay emission of this diagnostic as a bug.

This can be useful in contexts where an error indicates a bug but typically this only happens when other compilation errors have already happened. In those cases this can be used to defer emission of this diagnostic as a bug in the compiler only if no other errors have been emitted.

In the meantime, though, callsites are required to deal with the “bug” locally in whichever way makes the most sense.

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference's “Type Layout” chapter for details on type layout guarantees.

Size: 24 bytes