@dherman doesn't like it 😄

Previously PRs would only do a build on Windows, which confusingly
meant that PRs got a green tick for Windows despite not testing them.

See discussion in rust-lang#17019.

Run Windows tests on PRs too

Previously PRs would only do a build on Windows, which confusingly meant that PRs got a green tick for Windows despite not testing them.

See discussion in rust-lang#17019.

fix: VFS should not confuse paths with source roots that have the same prefix

Previously, the VFS would assign paths to the source root that had the longest string prefix match. This would break when we had source roots in subdirectories:

```
/foo
/foo/bar
```

Given a file `/foo/bar_baz.rs`, we would attribute it to the `/foo/bar` source root, which is wrong.

As a result, we would attribute paths to the wrong crate when a crate was in a subdirectory of another one. This is more common in larger monorepos, but could occur in any Rust project.

Fix this in the VFS, and add a test.

Previously PRs would only do a build on Windows, which confusingly
meant that PRs got a green tick for Windows despite not testing them.

See discussion in rust-lang#17019.

Run Windows tests on PRs too

Previously PRs would only do a build on Windows, which confusingly meant that PRs got a green tick for Windows despite not testing them.

See discussion in rust-lang#17019.

fix: VFS should not confuse paths with source roots that have the same prefix

Previously, the VFS would assign paths to the source root that had the longest string prefix match. This would break when we had source roots in subdirectories:

```
/foo
/foo/bar
```

Given a file `/foo/bar_baz.rs`, we would attribute it to the `/foo/bar` source root, which is wrong.

As a result, we would attribute paths to the wrong crate when a crate was in a subdirectory of another one. This is more common in larger monorepos, but could occur in any Rust project.

Fix this in the VFS, and add a test.