Skip to content

Conversation

@silentbicycle
Copy link
Collaborator

Previously the conflicts were flagged inside of carryopaque, but that was removed in 3d532ee. Now do it in its own pass, called ast_noteconflicts.

Add a test (tests/lxconflict/in0.lx and out0.err).

This fixes the lx side of #438.

Previously the conflicts were flagged inside of carryopaque,
but that was removed in 3d532ee. Now do it in its own pass,
called `ast_noteconflicts`.

Add a test (`tests/lxconflict/in0.lx` and `out0.err`).
We're trying to test lx's error output for ambiguity, so replacing
${LX} with "true; echo lx" obviously won't work, and it also breaks
the build in a really confusing way. Just skip it.
@katef
Copy link
Owner

katef commented Aug 7, 2023

Hm I think something is amiss here, but I can't work out what.
image

Here I think $t1 shouldn't be matched by "b", and therefore that the example for this is wrong:

ambiguous mappings to $t1, $t2; for example on input 'b'

doing the same with re(1) (note -b) gives the end labels I'd expect:
image

So is lx propogating these endids too enthusiastically between states somehow?

@katef
Copy link
Owner

katef commented Aug 7, 2023

Confirming that the above bug doesn't exist on the current main (which is of course the point of #438):
image

@silentbicycle
Copy link
Collaborator Author

silentbicycle commented Dec 8, 2023

Hm I think something is amiss here, but I can't work out what.

Your re command line has a?b?c whereas your lx commands a?b?c? (note the trailing ?) so that's an extra difference.

There's clearly something wrong here ($t1 shouldn't match "bc"), but that's a thing to keep in mind with the example above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants