eif: fix name collision in same folder for exes and melange emits

[jchavarri]

This applies (somehow) the idea mentioned in #10179 (comment).

Part of the fix for #10222.

In order to keep the duplication check active for actual cases where 2 libs are enabled in the same folder, a new field is added to the group_part type to keep track of the enable state of either libs, exes or melange-emits.

For cases when a collision is detected when both stanzas are enabled, the previous behavior remains.

If one of the stanzas is disabled, then we filter out the disabled stanzas from the list before proceeding. I guess we could filter the stanzas upfront, but I believe keeping the disable ones as much as possible might enable use cases where the user is trying to target the artifact of a disabled stanza, so Dune can error out appropriately (see related #10026). Edit: in the end, the stanzas are filtered upfront as there were not many upsides to do it lazily at the moment.

[rgrinberg]

It seems like you pass the toggle to artifacts_obj but you don't do anything with it, any reason for that?

[jchavarri]

I used it originally, but I guess I can remove it now and just pass the right list of libs, exes and emits directly from the caller, if that's the better approach.

[rgrinberg]

I'm not sure if it's the better approach, so I'm looking at the code right to find out. I'll list my thought process below. You'll have to repeat in a few different places, so it might be useful.

First, I need to check where are the callers of Artifacts_obj that use a library name. Looks like there's only one caller of:

val lookup_library : t -> Lib_name.t -> Lib_info.local option

That lives in Expander:

    (match Artifacts_obj.lookup_library artifacts name with
     | None -> does_not_exist ~what:"Library" (Lib_name.to_string name)
     | Some lib ->
       Mode.Dict.get (Lib_info.archives lib) mode
       |> Action_builder.List.map ~f:(fun fn ->
         let fn = Path.build fn in
         let+ () = Action_builder.path fn in
         Value.Path fn))

So now I think about what's going to happen if we pretend that a disabled library does not exist. Since this code is part of the expander, to reproduce this behavior I'd run the following command dune build %{cma:dir/disabled-lib}.

From the perspective of the user, dune telling me this does not exist would be rather undesirable. So we need to improve the situation somehow. To do so, we need Artifacts_obj.lookup_library to propagate the library being disabled.

I make the conclusion that your decision is indeed correct and we need to pass enabled/disabled to Artifacts_obj

Hope that helps.

[jchavarri]

Just to make sure I understand, this process would help on the eventual case that in some future Dune sets "fake" rules for all the disabled libraries in the current context right? As we confirmed the other day that there's no need to set rules for disabled libs right now.

I also wonder, in this hypothetic future where there are fake rules for disabled libraries (for better user errors), how would we deal with the case where two libraries are defined in the same folder with the same name, but one defined on each context? I assume we would skip the creation of fake rules in that case?

[rgrinberg]

Yes, we discussed using fake rules to make the error messages better. And indeed the decision was to forego them for now, as it's quite complex to implement. However, there's other cases where we can improve the error messages without much complexity. Expanding percent forms like we have here is an obvious candidate.

In your hypothetical case we would skip the fake rules. As they would overlap with actual rules.

[rgrinberg]

I added a test case for this in #10245

Looks like we don't handle disabled libraries correctly

[jchavarri]

The change requests didn't specify if this is something that should be fixed in this PR. Is that the case? In any case, the PR doesn't seem to change the current behavior.

[rgrinberg]

No, there's no need to fix it here.

[jchavarri]

@rgrinberg Sorry, this PR is not yet ready. The CI failures helped me understand there is something borked on the way setup_emit_js_rules is called (from Gen_rules.gen_rules), because the right context is not taken into account, and so there is a mismatch between that function and Lib_rules.rules (which sets the rules for melange cmj). I still don't fully understand the problem.

[jchavarri]

cc @emillon. This PR seems to fix the case found in #7899.

[rgrinberg]

The old behavior was in fact correct and this PR breaks it. The description of this test might be the source of confusion. There's no limitation anywhere, it's just that the different semantics were chosen for enabled_if on tests.

[jchavarri]

Should be fixed in 050aed8.

[jchavarri]

Just as a side note, if I'm understanding the current behavior properly, it is quite confusing from a user perspective. enabled_if semantics are now different depending on where it's used:

• In executable stanzas, the field means the executable is not built if it evaluates to false
• In test stanzas:
  • when all alias is used, the field means the test executable is always built, regardless its evaluated value
  • but for runtest alias it means the executable will not be built if it evaluates to false (like executable stanzas)

I found this comment that explains the use case for it: #7899 (comment).

It's probably too late, but wonder if it would have been possible to leave the behavior of enabled_if consistent, and allow advanced use cases to use a combination of rule and executable, or add a new field test_if.

[rgrinberg]

Yes, in hindsight it would be better to do it your way. We could revisit it for 4.0

[jchavarri]

These errors might be more meaningful to users than the previous behavior (not building anything because the alias is "empty", but not erroring either).

[anmonteiro]

is it time we make this a record instead? that'd be a whole lot easier to follow what each member of this group_part is.

[jchavarri]

I agree. I can do so in a follow-up PR.

[rgrinberg]

The old behavior was in fact correct and this PR breaks it. The description of this test might be the source of confusion. There's no limitation anywhere, it's just that the different semantics were chosen for enabled_if on tests.

[rgrinberg]

I added a test case for this in #10245

Looks like we don't handle disabled libraries correctly

[rgrinberg]

I improved the PR as follows:

1. stop propagating enabled_if when they aren't being used. we should propagate them to improve error messages in the future, but we can save that until its actually needed.
2. correctly handle build_if for tests
3. avoid evaluating enabled_if on melange.emit unless it's needed (to avoid possible cycles)
4. do not compute modules for disabled stanzas.

Should be good once you add a CHANGES entry

[jchavarri]

@rgrinberg Thanks for the improvements!

I updated the tests in b22ae6f, and added a changelog entry. Please merge if everything looks fine.