rescript-lang / rescript-lang/rescript

[bug] error reporting for res/resi/ conflict is hard to parse?

Offen
#7,950 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Vorherrschende Sprache
OCaml
Sterne
7.5k
Forks
485
Ø Merge
1 T. 2 Std.
Gemergte PRs (30 T.)
55

Beschreibung

i guess this is pretty opinionated of me but to me, it's hard to read:

  The implementation <project path>/src/utils.res
  does not match the interface ../ocaml/utils.cmi:
  Values do not match:
    let anyToJson: (
  'a,
  ~breakCycle: ('a, array<string>) => JSON.t=?,
  ~encodeBigInt: BigInt.t => JSON.t=?,
  ~encodeSymbol: Symbol.t => JSON.t=?,
  ~encodeFunction: {..} => JSON.t=?,
) => JSON.t
  is not included in
    let anyToJson: (
  'a,
  ~breakCycle: ('a, array<string>) => JSON.t=?,
  ~encodeBigInt: BigInt.t => JSON.t=?,
  ~encodeSymbol: Symbol.t => JSON.t=?,
  ~encodeFunction: 'a => JSON.t=?,
) => JSON.t
  <project path>/src/utils.resi:1:1-7:11:
    Expected declaration
  <project path>/src/utils.res:69:5-13:
    Actual declaration
  1. the formatting and indentation is all weird
  2. it doesn't immediately tell me what the problem is
  3. it says something about Expected declaration which makes it even more confusin
  The implementation <project path>/src/utils.res
  does not match its expected interface:

  Implementation:

    let anyToJson: (
      'a,
      ~breakCycle: ('a, array<string>) => JSON.t=?,
      ~encodeBigInt: BigInt.t => JSON.t=?,
      ~encodeSymbol: Symbol.t => JSON.t=?,
      ~encodeFunction: {..} => JSON.t=?,
    ) => JSON.t

  Declaration:

    let anyToJson: (
      'a,
      ~breakCycle: ('a, array<string>) => JSON.t=?,
      ~encodeBigInt: BigInt.t => JSON.t=?,
      ~encodeSymbol: Symbol.t => JSON.t=?,
      ~encodeFunction: 'a => JSON.t=?,
    ) => JSON.t

  ~encodeFunction has the following type in implementation: {..} => JSON.t=?,
  but should have this type according to interface:         'a => JSON.t=?

i don't need to see something about a .cmi file, and it's always easy enough to grep that i don't need to see line and column numbers for both implementation and declaration anyway. it's probably more common that a file is so small that reading the convoluted message costs me more time than the off-chance that the module is an absolute huge monolith to the point it'd save me time, so all in all, better to remove it.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Reproduziere den res/resi-Konflikt anhand der Beispielpfade src/utils.res und src/utils.resi und untersuche anschließend den Fehlerberichterstattungspfad des Compilers für diese Schnittstellenabweichung. Erledigt ist die Aufgabe, wenn die Diagnose besser lesbar ist, den Typunterschied direkt erklärt und unnötige .cmi-Details sowie doppelte Ortsangaben vermeidet.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
ocaml
Bereich
compilers
Issue-Typ
Bug
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.