Fix rust#cargotest namespace search

[dhleong]

The position.file property seems to often be just a file name; for files
like mod.rs this would throw an error due to the way the special casing
was set up; to fix this (and to assist with building the full module
path for 'nearest' and 'file' tests) I've expanded to the full path
(which is what the code seems to have been expecting).

Next, with the full path to the file in hand, the way it searched for
Cargo.toml would just not work on macOS (at least) since it would look
like, eg: Users/name/path/to/Cargo.toml, which glob() would treat as
relative, and so not match. To fix this in a (hopefully)
platform-agnostic way, I've pulled out the prefix before the first
"modules" entry and prepended it to the proposed path.

---

Make sure these boxes are checked before submitting your pull request:

• Add fixtures and spec when implementing or updating a test runner
• Update the README accordingly
• Update the Vim documentation in doc/test.txt

[codeinabox]

Thank you for this, LGTM though you need to update the expectations in spec/cargotest_spec.vim. Let me know if you need a hand with this.

[dhleong]

Hi @codeinabox sorry for the long delay—I've been a bit busy with Real Life and this fell off my radar.

I found some time recently to finally figure out how to run the unit tests, and investigated this a bit further. It seems like the reason the unit tests work fine but I run into errors in practical use is autochdir. I automatically change directory whenever I move buffers, so expand('%') is always just the filename for me. However, the unit test environment does not have this logic, and so when it does view src/file.rs the buffer name (even made relative to the current directory with ":.") still contains src/file.rs.

I can probably proceed with updating the fixtures/tests to pass using my approach here of forcing absolute paths, but I wonder if there are other runners that have this brittleness, assuming noautochdir. Also, I couldn't quite verify this behavior in the tests; I would've expected calling set autochdir in the before hook would work, but nothing seems to change. I did verify, however, that running nvim -u NONE and executing :e src/cli.rs | echo expand('%:.') with and without set autochdir before it will result in cli.rs and src/cli.rs, respectively 🤔

[dhleong]

Also it seems that vim-flavor v3.0.0 doesn't work anymore due to changes on github's side:

fatal: remote error: 
[1440]()  The unauthenticated git protocol on port 9418 is no longer supported.
[1441]()Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.

Locally, I had to install a newer version of ruby and install the latest vim-flavor there to get the tests to run.

[codeinabox]

Also it seems that vim-flavor v3.0.0 doesn't work anymore due to changes on github's side:

fatal: remote error: 
[1440]()  The unauthenticated git protocol on port 9418 is no longer supported.
[1441]()Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.

Locally, I had to install a newer version of ruby and install the latest vim-flavor there to get the tests to run.

Thank you for spotting this, I have fixed the build

[codeinabox]

@dhleong keen to get this merged in though there is still one failing test, could you please look into this and let me know if you need a hand

[dhleong]

@codeinabox Sorry for the delay, I've been totally swamped and this keeps falling off my radar. I suspect that the actual issue here was just from me being unaware of the `test#project_root` config, and the implications of it. I don't know if/when I'll have a chance to confirm this, but I suspect that there's actually no change needed here, so long as the project root is configured the way vim-test expects.

…

On Wed, Sep 14, 2022, 8:16 AM Mathew Attlee ***@***.***> wrote: @dhleong <https://github.com/dhleong> keen to get this merged in though there is still one failing test, could you please look into this and let me know if you need a hand — Reply to this email directly, view it on GitHub <#613 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGHIFSBH2S4UPLUUM7W2QTV6G6ZRANCNFSM5K5DNY6A> . You are receiving this because you were mentioned.Message ID: ***@***.***>