Make ShellError more readable by consistently using named fields

[sholderbach]

Our ShellError still has a number of variants that are tuple structs (i.e. unnamed list of types to provide). Especially if there are multiple fields of the same type it is unclear at the creation side of a ShellError which field goes where. This is exacerbated by the fact that for the miette diagnostics we have sometimes format strings that make strong assumptions what should be provided for a particular field.

Thus we should convert each of them to named struct variants (i.e. Identifier { field: type, ... }). While doing so it is worth checking if we use the fields of the error correctly. Sometimes we might need to change incompatible uses of a variant to a different variant.

Variants that need named fields

• UnsupportedInput
• DatetimeParseError
• NetworkFailure
• CommandNotFound
• AliasNotFound
  - FlagNotFound
• FileNotFound
• FileNotFoundCustom
• PluginFailedToLoad
• PluginFailedToEncode
• PluginFailedToDecode
• IOInterrupted
• IOError
• IOErrorSpanned
• PermissionDeniedError
• OutOfMemoryError
• NotADirectory
• DirectoryNotFound
• DirectoryNotFoundCustom
• MoveNotPossibleSingle
• CreateNotPossible
• ChangeAccessTimeNotPossible
• ChangeModifiedTimeNotPossible
• RemoveNotPossible
• NoFileToBeRemoved
• NoFileToBeMoved
• NoFileToBeCopied
• ReadingFile
• DidYouMean
• DidYouMeanCustom
• NonUtf8
• NonUtf8Custom
• DowncastNotPossible
• UnsupportedConfigValue
• MissingConfigValue
• NeedsPositiveValue
• GenericError
• OutsideSpannedLabeledError
• RemovedCommand
• UnexpectedAbbrComponent
• EvalBlockWithInput
• Break
• Continue
• Return
• NotAConstant
• NotAConstCommand
• NotAConstHelp

Example PRs

• Document and critically review ShellError variants - Ep. 1 #8229
• Document and critically review ShellError variants - Ep. 2 #8326
• Document and critically review ShellError variants - Ep. 3 #8340

[fdncred]

It would be nice to pin this but I'm not sure which other pinned issue to remove.

Would love to have more consistency across our ShellError messages!

[kaiba42]

tldr; ShellError variants should have record<> types for fields instead of strings.

I'm having some trouble dealing with these ShellError variants in try { cmd } catch{|e| ...} blocks. When cmd fails, the type of $e is record<msg: string, debug: string, raw: error>, which I can see is mapped from ShellError::ExternalCommand.

The problem is that the fields within the record, the debug string is formatted as

ExternalCommand { label: "some string", help: "some error", span: Span { start: 12345, end: 67890 } }

Which isn't able to be parsed into a structured data type to my knowledge. However, it clearly is more than just a string to nushell, because running metadata ($e.debug) will actually yield a record<span: record<start: int, end: int>>, which suggests that $e.debug is not merely a string. I think $e.debug should be a record, not a string.

[sholderbach]

@kaiba42 there is certainly some extra work necessary to make sure as a Nushell user you have access to the relevant fields.

But, yes completing this internal polishing here should make it easier to cleanly serialize the internal error to a Nushell record.

[amtoine]

@drbrain
there are 13 unticked tasks in this issue, should it be reopened?