Improve ppx_repr error message when shadowing a Stdlib type without @nobuiltin

[Ngoguey42]

type result = int [@@deriving repr]

type t = result list [@@deriving repr]

causes

19 | type t = result list [@@deriving repr]
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: This expression has type
         'a Repr.ty -> 'b Repr.ty -> ('a, 'b) Stdlib.result Repr.ty
       but an expression was expected of type 'c Repr.ty

[craigfe]

At some level, this is expected and is what the [@nobuiltin] attribute is for. (See ppx_deriving conventions and testing of the ppx_repr implementation.)

In this case, we could do better because result is used at a different arity from the one in the standard library, so attempting to use Repr.result isn't going to work. What do you think?

[Ngoguey42]

Thanks for the precisions.

The biggest problem here is that the error message is very misleading, it took me a while to understand this was caused by a name clash. Ideally, an error message would have suggested me to use [@nobuiltin].

When Repr sees a result, could we inject into the AST something that asserts that result is Stdlib.result(and likewise for all the other types from stdlib)? This way I suppose that the error message would be clearer.

[craigfe]

Yep, good point. This is part of a larger problem with PPXes having no way to hook into the error message mechanism. It's possible we could emit code like the following:

(* In a PPX runtime library *)
type ('a, 'b) expected_equality = Refl : ('a, 'a) expected_equality

(* In user code *)
type (_, _) result = unit 
type foo = int * (bool, string) result

let foo_t = 
  let _ : (('a, 'b) result, ('a, 'b) Stdlib.result) expected_equality = Ppx_repr_runtime.Refl in
  ...

which would produce an error of the following sort:

Line 1, characters 72-76:
Error: This expression has type (unit, unit) expected_equality
       but an expression was expected of type
         (unit, ('a, 'b) Stdlib.result) expected_equality
       Type unit is not compatible with type ('a, 'b) Stdlib.result

It's very possible that there are ways to coerce a better error message out of OCaml.