test: Surprising behaviour on anonymous actions with multiple aliases

[NatKarmios]

Related to #15576 & #15581

Adds 3 tests for anonymous actions with multiple aliases, specifically:

• Building one of an action's aliases can pull in another alias
• Duplicating or re-ordering aliases in a rule does not cause a re-run

Note that all these tests currently fail, but are fixed by #15581:

Test results

File "test/blackbox-tests/test-cases/alias/alias-multiple.t", line 1, characters 0-0:
------ test/blackbox-tests/test-cases/alias/alias-multiple.t
++++++ test/blackbox-tests/test-cases/alias/alias-multiple.t.corrected
File "test/blackbox-tests/test-cases/alias/alias-multiple.t", line 139, characters 0-1:
 |
 |A rule attached to several aliases must not make one alias pull in unrelated
 |contributions to another alias. Here alias [a] also receives an unrelated
 |action; building [b] must run only the shared action.
 |  $ cat > dune << EOF
 |  > (rule
 |  >  (aliases a b)
 |  >  (action (echo "I have run\n")))
 |  > (rule
 |  >  (alias a)
 |  >  (action (echo "unrelated\n")))
 |  > EOF
 |
 |  $ dune clean
 |  $ dune build @b
 |  I have run
+|  unrelated
 |
 |Building [a] still runs both the shared action and the action attached only
 |to [a].
 |  $ dune clean
 |  $ dune build @a
 |  I have run
 |  unrelated
 |
 |The set of aliases determines the action's identity: neither duplicating an
 |alias nor reordering the aliases should re-run the action.
 |
 |Duplicating an alias does not re-run the action:
 |  $ cat > dune << EOF
 |  > (rule
 |  >  (aliases a)
 |  >  (action (echo "I have run\n")))
 |  > EOF
 |  $ dune clean
 |  $ dune build @a
 |  I have run
 |  $ cat > dune << EOF
 |  > (rule
 |  >  (aliases a a)
 |  >  (action (echo "I have run\n")))
 |  > EOF
 |  $ dune build @a
+|  Error: Dependency cycle between:
+|     alias a in dune:1
+|  [1]
 |
 |Reordering the aliases does not re-run the action:
 |  $ cat > dune << EOF
 |  > (rule
 |  >  (aliases a b)
 |  >  (action (echo "I have run\n")))
 |  > EOF
 |  $ dune clean
 |  $ dune build @a @b
 |  I have run
 |  $ cat > dune << EOF
 |  > (rule
 |  >  (aliases b a)
 |  >  (action (echo "I have run\n")))
 |  > EOF
 |  $ dune build @a @b
+|  I have run

[Alizter]

Can you promote the failing output so that they still "succeed" in the CI? The goal of cram tests should always be snapshotting the current behaviour of dune, you can use cram test prose to comment on it and point out if it should be different and why.

[NatKarmios]

Can you promote the failing output so that they still "succeed" in the CI? The goal of cram tests should always be snapshotting the current behaviour of dune, you can use cram test prose to comment on it and point out if it should be different and why.

Sure, done.