"cabal: Internal error in target matching" (was: Internal error/infinite loop in D.Client.TargetSelector)

[sebright]

I reproduced the issue on master (3781531) by running the following command in the cabal repository:

$ cabal new-build test:unknown-test-suite
cabal: Internal error in target matching. It should always be possible to find
a syntax that's sufficiently qualified to give an unambiguous match. However
when matching 'test:unknown-test-suite' we found test:unknown-test-suite
(unknown-component) which does not have an unambiguous syntax. The possible
syntax and the targets they match are as follows:
cabal: <<loop>>

It also occurs when I run the same command on a simple project with one directory containing a simple .cabal file:

name: example
version: 1.0
build-type: Simple
cabal-version: >= 1.2

library

The error message is from D.Client.TargetSelector:

cabal/cabal-install/Distribution/Client/TargetSelector.hs

Line 653 in 3781531

die' verbosity $ "Internal error in target matching. It should always "

[23Skidoo]

/cc @dcoutts, may be caused by your recent patches.

[gelisam]

I found it, I'll send a PR

[sebright]

Reopening, since there is still an internal error. After #5263, cabal prints the full error message:

$ cabal new-build test:unknown-test-suite
cabal: Internal error in target matching. It should always be possible to find
a syntax that's sufficiently qualified to give an unambiguous match. However
when matching 'test:unknown-test-suite' we found test:unknown-test-suite
(unknown-component) which does not have an unambiguous syntax. The possible
syntax and the targets they match are as follows:
'test:unknown-test-suite' which matches test:unknown-test-suite
(unknown-component), :pkg:test:lib:test:file:unknown-test-suite (unknown-file)

[gelisam]

Ah, I thought this bug was only about the loop, but now that I am taking a closer look at the error message, it does say "Internal error", so I guess this error message isn't supposed to be displayed in the first place. Hmm, what's the desired behaviour instead?

Let's see, if there is a package foo with a test-suite which is also named foo, and we ask for foo, we get the following error message:

cabal: Ambiguous target 'foo'. It could be:
test:foo (component)
lib:foo (component)

So I think what is going on is that test:unknown-test-suite is ambiguous, just like foo, and so cabal is trying to list a few alternatives which aren't ambiguous. Unfortunately, one of those alternatives is test:unknown-test-suite itself, which isn't any less ambiguous than test:unknown-test-suite. Fortunately, cabal has an internal sanity check which catches the problem and reports this as an internal error.

But wait, why is test:unknown-test-suite ambiguous? Now that the message no longer loops, we can see that the other possibility is :pkg:test:lib:test:file:unknown-test-suite, a format I have never seen before. Let's double-check the documentation.

Okay, so apparently there are many more ways of specifying a target than I though. Only looking at packages, libraries (which have the same name as the package) and test suites, we have all of those possibilities:

• <package-name>
• test
• test:<test-suite>
• <test-suite>
• <package-name>:<test-suite>
• <package-name>:test:<test-suite>
• lib
• lib:<package-name>
• <package-name>:<package-name>
• <package-name>:lib:<package-name>

So if the package and the test-suite are both named test, then asking for test or test:test are both ambiguous, as they can both either mean to build the library or the test-suite. Since we don't have a weirdly named package or test-suite, this still doesn't explain why test:unknown-test-suite is ambiguous. My guess is that there is a separate ambiguity-check for unknown targets:

1. If there are multiple matching known targets, show some disambiguations. Otherwise,
2. If there is only one matching known target, pick it. Otherwise,
3. If there are no matching known targets, check for unknown targets.
4. If there are multiple matching unknown targets, show some disambiguations. Otherwise,
5. If there is only one matching unknown target, complain that the specified component doesn't exist.
6. If there are no matching unknown target, complain that the target syntax is not recognized.

Our bug seems to be in phase 4: test:unknown-test-suite is obviously meant to refer to a test-suite named unknown-test-suite, but technically it could also refer to a package named test and a component (not necessarily a test suite) named unknown-test-suite. So the two ways of disambiguating are:

• <package-name>:test:unknown-test-suite
• test:<component-name>:unknown-test-suite

but since we're talking about a non-existing component, who knows which non-existing package name and component-name we should pick?

I now think the expected behaviour should be to offer the following disambiguations:

• :test:unknown-test-suite
• test:lib:unknown-test-suite
• test:exe:unknown-test-suite
• test:test:unknown-test-suite
• test:bench:unknown-test-suite

Where the first disambiguation uses an empty package name, meaning the current package. That syntax doesn't refer to any package if the current folder uses a cabal.project file to specify multiple projects, but that should hopefully be enough to guide the user in the right direction. One alternative would be to list <package-name>:test:unknown-test-suite for every package in the cabal.project file.