bstaletic
commented
3 years ago I'll try to repro later. For now, check out :h g:ycm_rust_toolchain_root. YCM's bundled rust-analyzer/toolchain might not be appropriate for your project.
Closed ajgae closed 3 years ago
bstaletic
commented
3 years ago I'll try to repro later. For now, check out :h g:ycm_rust_toolchain_root. YCM's bundled rust-analyzer/toolchain might not be appropriate for your project.
puremourning
commented
3 years ago My guess is that RA just doesn’t work with no-stdlib projects. But that’s a question for RA people...
ajgae
commented
3 years ago My guess is that RA just doesn’t work with no-stdlib projects. But that’s a question for RA people...
This seems to be the case. Following the blog post further, I noticed that YCM also complains about the first line:
#![no_std], saying that it "can't find crate for 'test' [E0463]". So this issue probably does lie in writing rust crates with the #![no_std] attribute
ajgae
commented
3 years ago UPDATE: I have since continued following along the blog posts, and it turns out that enabling the unstable custom_test_frameworks feature makes the compiler complaint can't find crate for 'test' [E0463] on line 1 (which I mentioned above) disappear.
#![no_std]
#![no_main]
#![feature(custom_test_frameworks)]
#![test_runner(crate::test_runner)]
// ...
#[cfg(test)]
fn test_runner(tests: &[&dyn Fn()]) {
println!("Running {} tests.", tests.len());
for test in tests {
test();
}
}With this, YCM indicates no more errors, as expected. It seems there is sort of a grey zone between using "standard" features (stdlib, default testing framework) and not using them at all where YCM freaks out and doesn't quite understand what's going on, displaying errors about missing crates, but then it stops complaining when you have truly detached yourself from using any of these "standard" features
puremourning
commented
3 years ago I think we can close this, there’s clearly nothing YCM can do differently here. If there’s anything to change, it’s in rust-analyzer
Issue Prelude
Please complete these steps and check these boxes (by putting an
xinside the brackets) before filing your issue:vim --version.:YcmDebugInfo.:YcmToggleLogscommand.vim -Nu /path/to/YCM/vimrc_ycm_minimal, including what I expected to happen and what actually happened.install.py(orcmake/make/ninja) including its invocationThank you for adhering to this process! It ensures your issue is resolved quickly and that neither your nor our time is needlessly wasted.
Issue Details
What I did
I am following this blog post: https://os.phil-opp.com/freestanding-rust-binary/.
cargo new rust_oscd rust_osCargo.toml, and append the[profile.dev]and[profile.release]sections, resulting in the following contents:vim -Nu /path/to/YCM/ycm_vimrc_minimal:edit src/main.rsmain.rsto match the following:What I expected to happen
The output of
cargo rustc -- -C link-arg=-nostartfilesshould match the errors indicated in the buffer by YCM, that is, show no errors or warnings.What actually happened
The output of
cargo rustc -- -C link-arg=-nostartfilescompletes successfully, showing no errors or warnings, as expected. However, YCM indicates the following error on line12(obtained via:YcmShowDetailedDiagnostic):It seems some part of the YCM rust analyzer makes YCM think that a panic handler has been defined somewhere else in the freshly created
rust_oscodebase, when clearly it hasn't.Diagnostic data
Output of
vim --versionOutput of
YcmDebugInfoOutput of
YcmDiagsOutput of
git rev-parse HEADin YouCompleteMe installation directoryContents of YCM, ycmd and completion engine logfiles
/tmp/rust_language_server_stderr2o9avkkd.log/tmp/ycm_hv4vv4uy.log/tmp/ycmd_45363_stderr__nyq4x9n.log/tmp/ycmd_45363_stdout_nobwjhfe.logOS version, distribution, etc.
I am running Arch Linux, having just fully upgraded my system.