0xPolygonMiden / compiler

Compiler from MidenIR to Miden Assembly

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Reduce friction for users when reporting ICE

greenhat opened this issue · comments

When ICE happens, the cargo extension could gather all the context (source files, dependencies, Cargo.toml, etc.) and after asking the user's permission, generate a file(output?) that would be posted as an issue in this repo.
Alternatively, the cargo extension could interactively ask the user's permission and create the issue (using gh, HTTP API, etc.) and upload all the context info (see above).

Tasks

We almost certainly can't include source files automatically, and would need to be very careful about any data we do collect, even if we ask permission to create an issue. If the project is proprietary, or otherwise covered by some sensitive contractual agreement (like an NDA), uploading those kind of artifacts could get someone in deep trouble. But even setting that aside, in general, people can be very touchy about things like that.

Fundamentally, we'll need cooperation from the person who reported the error, so I think we can rely on them either providing us the source (and other necessary details), or an equivalent reproducer, upon request. If they can't/won't, then if we are unable to proceed without that, then we just close the issue until we encounter it again but with additional context/data we need.

What I think we definitely can do by default, are necessary to troubleshoot most issues, and are at least provided currently by human_panic are:

  • The platform on which the program is being compiled (i.e. are they running the compiler on macOS, if so, what version, etc.)
  • The full version (including git hash) of the compiler that produced the error
  • The target type (e.g. "core" Miden, or the rollup)
  • Any flags passed to the compiler or higher-level tools, stripped of any potentially sensitive information (not sure we have any of those currently anyway, but wan't to be explicit about that point)
  • The full backtrace of the panic/error that occurred
  • Any warning/error diagnostics produced during that invocation (if we captured them) (NOTE: This isn't provided by human_panic, but is something I think would be useful)

Anything above and beyond that will require cooperation by the user reporting the error (i.e. providing us with the source code, or an equivalent reproducer; dependencies and their versions, any other configuration or necessary context).

I think we should also summarize what we're sending when reporting an issue, and where that payload is, so that they can review it and upload it by hand if they so choose.

I updated the description to ask the user's permission for including the sources. For an unknown reason, I did not spell it out, although I always had that in mind.
I agree that it might be a big ask and should not be the default behavior.