Test rust-analyzer in CI

[cuviper]

This adds x.py support for testing rust-analyzer in-tree, and runs
that in CI for x86_64-gnu-tools so we can track toolstate.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[cuviper]

However, the tests are failing locally for me in-tree, and I don't know why. I'm aware of the proc-macro bridge issues due to nightly changes, but even with cargo +stable test I get a lot of failures where "Expect:" is empty. The same commit tests fine for me in an independent checkout of the rust-analyzer repo.

[cuviper]

If the whole testsuite is infeasible, we could also narrow it -- e.g. -p proc-macro-srv shows the current problems:

failures:
    tests::test_attr_macro
    tests::test_derive_empty
    tests::test_derive_error
    tests::test_fn_like_macro
    tests::test_fn_like_macro2

[fasterthanlime]

even with cargo +stable test I get a lot of failures where "Expect:" is empty

I'm able to reproduce the failures when checking out your branch. Those tests use expect-test's expect_file!.

strace tells the story:

$ clear; strace -e open,openat -ff cargo t test_string_highlighting
(lots of output omitted)
[pid 38722] openat(AT_FDCWD, "/home/amos/bearcove/rust/crates/ide/src/syntax_highlighting/./test_data/highlight_strings.html", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Indeed that file doesn't exist:

$ stat /home/amos/bearcove/rust/crates/ide/src/syntax_highlighting/./test_data/highlight_strings.html
stat: cannot statx '/home/amos/bearcove/rust/crates/ide/src/syntax_highlighting/./test_data/highlight_strings.html': No such file or directory

The correct path is as follows:

$ stat /home/amos/bearcove/rust/src/tools/rust-analyzer/crates/ide/src/syntax_highlighting/./test_data/highlight_strings.html 
  File: /home/amos/bearcove/rust/src/tools/rust-analyzer/crates/ide/src/syntax_highlighting/./test_data/highlight_strings.html
  Size: 45127           Blocks: 96         IO Block: 4096   regular file
Device: 803h/2051d      Inode: 16409270    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    amos)   Gid: ( 1000/    amos)
Access: 2022-07-18 13:45:36.999588514 +0200
Modify: 2022-07-18 13:44:44.295860084 +0200
Change: 2022-07-18 13:44:44.295860084 +0200
 Birth: 2022-07-18 13:44:44.295860084 +0200

That feels like a bug in expect-test. It uses the file! macro then later uses it to build an absolute path by finding the workspace root. However, it goes too deep and finds rust's top-level Cargo.toml, and then the paths are all wrong.

[fasterthanlime]

@cuviper I opened a PR against your PR to also bump the rust-analyzer submodule, which should let tests pass.

• ⬆️ rust-analyzer cuviper/rust#1

[fasterthanlime]

@cuviper I opened a PR against your PR to also bump the rust-analyzer submodule, which should let tests pass.

• ⬆️ rust-analyzer cuviper/rust#1

So, this is enough to make cargo check pass from rust/src/tools/rust-analyzer, but not from x.py test rust-analyzer. I guess the .cargo/config.toml doesn't get picked up then?

The alternative there is to set CARGO_WORKSPACE_DIR from x.py directly. (The changes to expect-test are still good since we still want to be able to run cargo check from within the rust-analyzer tree in rust-lang/rust)

[fasterthanlime]

I opened a PR against your PR

I updated this PR to set CARGO_WORKSPACE_DIR from "x.py" (well, really, bootstrap::tool::prepare_tool_cargo) and all rust-analyzer tests now pass with ./x.py test rust-analyzer 🎉

[fasterthanlime]

I opened #99465 for research purposes - it re-adds rust-analyzer as a subtree, and it includes all commits from this here PR & my follow-up.

The reason I did this now is because @jyn514 and others suggested "skipping toolstate altogether" and going straight for subtree.

[Mark-Simulacrum]

Thanks! Closing per https://rust-lang.zulipchat.com/#narrow/stream/301329-t-devtools/topic/test.20--stage.200.20rust-analyzer/near/290636735.