opendylan icon indicating copy to clipboard operation
opendylan copied to clipboard

Improve "No applicable method" warnings

Open cgay opened this issue 7 years ago • 1 comments

GOT (I inserted line breaks to avoid scroll bars.)

 .../dylan/repo/package-manager/catalog.dylan:33-35: Serious warning - 
No applicable methods for call to 
error (cond-or-string :: <object>, #rest arguments :: <object>)
 => (will-never-return :: <bottom>)
 - inferred argument types #[singleton(<catalog-error> :: <class>), 
singleton(format-string :: <symbol>), <string>, 
singleton(format-arguments :: <symbol>), <simple-object-vector>].
        ----------------------
  33    error(<catalog-error>,
  34          format-string: fmt,
  35          format-arguments: args);
      -------------------------------

WANT

.../dylan/repo/package-manager/catalog.dylan:33-35: Error: 
No matching methods for error(<object>, #rest <object>) 
=> (never returns)
  Inferred types in call: #[<class>, <symbol>, <string>, <symbol>, 
<simple-object-vector>]
        ----------------------
  33    error(<catalog-error>,
  34          format-string: fmt,
  35          format-arguments: args);
      -------------------------------

Changes:

  • "Serious warning -" --> "Error:". Housel mentions that we already have an ERROR class for fatal errors. I suggest switching to warning/error/fatal terminology.
  • Remove some verbosity: "applicable methods for call to" --> "applicable methods for"
  • Only display the argument types, not the names of the arguments or the values. Those are obvious at the call site.
  • Remove :: <bottom> from the return value spec. That's an internal detail. It looks like will-never-return :: <bottom> is the return spec, verbatim, for various methods in boot.dylan and elsewhere. What about, as a quick and easy solution, renaming <bottom> to <does-not-return> and then it will look like => (<does-not-return>) when we only print the types as suggested in the previous bullet point.

cgay avatar Sep 19 '18 23:09 cgay

I didn't point out that it says "Inferred types in call" but then goes on to list things that aren't really types.

I missed that several of the arguments were singletons. We should come up with a standard, succinct way to display singleton types. Just precede it with ==?

singleton(format-string :: <symbol>) doesn't give me the slightest impression that the literal keyword format-string: was passed. Can we display symbol singletons as #"format-string" in error messages? Or perhaps we always precede singleton types with == and get == #"format-string".

singleton(<catalog-error> :: <class>) could be written == <catalog-error>

With those ideas in mind, here's my alternative WANT:

.../dylan/repo/package-manager/catalog.dylan:33-35: Error: 
No matching methods for error(<object>, #rest <object>) => (never returns)
Inferred types in call: == <catalog-error>, == #"format-string", <string>,
    == #"format-arguments", <simple-object-vector>
        ----------------------
  33    error(<catalog-error>,
  34          format-string: fmt,
  35          format-arguments: args);
      -------------------------------

If that's too radical, maybe just singleton(<catalog-error>), singleton(#"format-string"), etc.

cgay avatar Jan 15 '20 05:01 cgay