Include the context name for errors that happen in the non-default context

[jchavarri]

trafficstars

Consider this example (it uses Melange but that's only for demo purposes, could happen in any multi-context setup):

  $ cat > dune-project << EOF
  > (lang dune 3.13)
  > (using melange 0.1)
  > (package (name bar) (allow_empty))
  > (package (name baz) (allow_empty))
  > EOF

  $ cat > dune-workspace << EOF
  > (lang dune 3.13)
  > 
  > (context default)
  > 
  > (context
  >  (default
  >   (name melange)))
  > EOF
  $ cat > dune << EOF
  > (library
  >  (name foo)
  >  (public_name bar.foo)
  >  (enabled_if (= %{context_name} "default")))
  > (library
  >  (name foo)
  >  (public_name baz.foo)
  >  (modes melange)
  >  (enabled_if (= %{context_name} "melange")))
  > EOF

  $ cat > foo.ml <<EOF
  > let t = Str.regexp
  > EOF

  $ dune build
  File "foo.ml", line 1, characters 8-18:
  1 | let t = Str.regexp
              ^^^^^^^^^^
  Error: Unbound module Str
  [1]

The error message does not allow the user to know under which context the error is happening. This can be quite confusing when using more than one context at scale.

I wonder if Dune could include the context name for "alt contexts" (non-default), similarly to what is done currently for display=short, e.g.:

  $ dune build
  [melange]
  File "foo.ml", line 1, characters 8-18:
  1 | let t = Str.regexp
              ^^^^^^^^^^
  Error: Unbound module Str
  [1]

cc @davesnx

[emillon]

interesting, I thought we did that for tests?

[jchavarri]

@emillon I don't think so, or at least I can't find it 🤔

I took a look at the way user errors are handled, printed some stack trace in Report_error.gen_report to identify the modules involved:

  Raised by primitive operation at Dune_util__Report_error.gen_report in file "src/dune_util/report_error.ml", line 161, characters 19-43
  Called from Stdlib__List.iter in file "list.ml", line 110, characters 12-15
  Called from Dune_engine__Build_system.run.f in file "src/dune_engine/build_system.ml", line 1148, characters 6-28
  Called from Fiber__Scheduler.exec in file "vendor/fiber/src/scheduler.ml", line 76, characters 8-11

I am not sure yet how this can be implemented, but it seems that at least we should add the context where the error is happening to Exn_with_backtrace? That'll lead to cycles as that module is in stdune, which Context.t (dune_rules) uses. So maybe it can be just a string? So many questions 😄

[emillon]

no, you're right, I think I'm mixing up things. that must be because the full path to failing tests is sometimes printed, and the context name is part of these.