disambiguation: improve the interface of NameChoice.disambiguate

[gasche]

This PR sits on top of #9182, and suggests a difference interface for disambiguate. The idea is that before we had lbls and scope and we had to explain the relation between the two, while now we have just scope and a filtering criterion.

scope is passed in "delayed error" style, this has not changed and remains a source of subtlety in the disambiguate implementation, but I think that this version makes the subtlety a bit clearer.

(cc @garrigue @lpw25 @trefis)

[trefis]

If I'm not mistaken, one should only look at the last commit. I had just started working on a similar patch, and while I haven't carefully reviewed yet: I like the change you propose.

[gasche]

I fixed the test output (a new warning is emitted with this implementation, which is correct) and rebased the PR against the current trunk.

[Octachron]

There is a hidden bugfix here compared to trunk. Previously, lbls could be empty here, for instance

module M = struct
  type t = { x:int; y:int}
end
type u = { a:int }
let _ = ( { M.x=0 } : u )

which triggers an assert false in Printtyp.
With this PR this is not the case anymore because we don't fold the filter error case into Ok [ ] .

[gasche]

I added this example to the testsuite.

[gasche]

Note: I cannot reproduce the printing failure with 4.10, this is trunk-only. I wonder if it is a result of the previous refactoring PRs for NameChoice.

[Octachron]

The bug is present in 4.10, but it requires -principal and a non-principal expected type:

module M = struct
  type t = { x:int; y:int}
end
type u = { a:int }
let f (x:u) = x = { M.x=0 }

[Octachron]

The refactoring looks good to me, as illustrated by the missing warning and printing failure that it fixes incidentally.

[gasche]

Thanks! Merged.