Skip to content

ILVerify: list the error names in ilverify --help --verbose? #136056

Closed

Description

@pcshrosbree

TL;DR: ILVerify's --ignore-error and --ignore-error-file match error names that the tool does not list anywhere and does not always print. I propose that ilverify --help --verbose print those names after the usual help text, with each verification error's message; plain --help would not change. I ask whether you would take a PR, whether --help --verbose is the right trigger, and whether the type system names should be listed.

--ignore-error and --ignore-error-file take regular expressions that ILVerify matches against error names. Verification errors use VerifierError names such as StackUnexpected. Errors from the type system, such as a type that fails to load or a missing method, use ExceptionStringID names such as ClassLoadGeneral when ILVerify keeps the name. An error with neither name, such as an exception thrown while verifying a method, matches as None. The matching is in ShouldIgnoreVerificationResult in src/coreclr/tools/ILVerify/Program.cs.

The tool does not list these names anywhere, and its output does not always show them: errors found while verifying a type print only their message, and a method error that matches as None is printed as [IL]: Error []: .... A user may have to read VerifierError.cs and ExceptionStringID.cs to find a name.

I'd like to propose that ilverify --help --verbose prints the names after the usual help text, with each verification error's message. Plain --help would not change.

It would add no new error messages to maintain: the messages are the existing ones in Strings.resx, read at run time. ILVerify already compiles src/coreclr/tools/Common/CommandLineHelpers.cs, whose UseExtendedHelp appends text after the help for crossgen2, ILCompiler and dotnet-pgo. ILVerify would call it next to UseVersion(), with a callback that checks --verbose.

I tried this locally on main, adding 24 lines to ILVerifyRootCommand.cs and Program.cs and changing one. With --help --verbose, the end of the output looks like this:

  -?, -h, --help                           Show help and usage information
  -v, --version                            Show version information

Verification errors (--ignore-error matches these names):
  UnknownOpcode: Unknown opcode.
  MethodFallthrough: Fall through end of the method without returning.
  EHClauseOutOfRange: Exception handling clause bounds outside code size.
  ...
  UnalignedAlignment: Alignment specified for 'unaligned.' must be 1, 2, or 4.

Type system errors (--ignore-error also matches these names):
  ClassLoadGeneral
  ClassLoadExplicitGeneric
  ...
  AmbiguousMatchUnsafeAccessor

An error with neither kind of name, such as an exception while verifying a method, matches None.

That is 124 verification errors and 25 type system errors. Five messages contain placeholders such as '{0}', which ILVerify fills in when it reports the error; the list would show them unfilled.

Questions:

  1. Would you take a PR for this?
  2. Is --help --verbose the right trigger? A dedicated option, such as --help --error-codes or a standalone --list-errors, would have its own help entry. The help entry for --verbose only says "Verbose output".
  3. Should the type system names be listed? --ignore-error already matches them, but they come from the shared type system, which you said on #135989 should not be presented as something others can depend on.

Note

This issue was prepared with AI assistance (Anthropic Claude and OpenAI Codex), under my direction. I reviewed it before posting.

Activity

  1. dotnet-policy-service commented on Oct 19, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to this area: @JulieLeeMSFT, @dotnet/jit-contrib
    See info in area-owners.md if you want to be subscribed.

  2. jkotas commented on Oct 19, 2026

    @jkotas
    Member

    Fine with me if you think this is useful. I do not have a strong opinion about the details.

  3. jkotas commented on Oct 19, 2026

    @jkotas
    Member

    they come from the shared type system, which you said on #135989 (comment) should not be presented as something others can depend on.

    I was concerned about the shared type system APIs. The error code IDs are fine.

  4. added a commit that references this issue on Oct 20, 2026
    6ee7dd7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-Tools-ILVerificationIssues related to ilverify tool and IL verification in general

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions