compiletest: `./x test <filter>` is a substring match

This is very non-intuitive...

I tried on native x86_64-pc-windows-msvc:

./x test tests/run-make/exp/ --stage 1

This showed me 8 tests were ignored (incl. a local tests/run-make/exp/ test I added for testing) even though I would've expected an exact match for only the local test I added:

[23:37] Joe:rust (return-adjustment-target) | ls -d tests/run-make/*exp*
tests/run-make/export-executable-symbols/             tests/run-make/share-generics-export-again/
tests/run-make/extern-fn-explicit-align/              tests/run-make/wasm-export-all-symbols/
tests/run-make/mingw-export-call-convention/          tests/run-make/wasm-symbols-not-exported/
tests/run-make/rustdoc-scrape-examples-invalid-expr/

I almost never want this substring match behavior, at least not unless I explicitly write some kind of --test-name="exp", for example.

I suspect this is some behavior related to the test name constructed by compiletest, which is fed to libtest which probably handles the test filtering... Ah, it might be the test name constructed from the test path...

Start by tracing how compiletest constructs test names for ./x test <filter> and how that filter is passed to libtest. Reproduce the tests/run-make/exp/ example, then verify that the default filter selects the intended test path rather than substring matches, while any explicitly supported pattern behavior remains clear.