I don't think there's anything wrong with project_model depending on
proc_macro_api directly -- fundamentally, both are about gluing our pure
data model to the messy outside world.
However, it's easy enough to avoid the dependency, so why not.
As an additional consideration, `proc_macro_api` now pulls in `base_db`.
project_model should definitely not depend on that!
Our project model code is rather complicated -- the logic for lowering
from `cargo metadata` to `CrateGraph` is fiddly and special-case. So
far, we survived without testing this at all, but this increasingly
seems like a poor option.
So this PR introduces a simple tests just to detect the most obvious
failures. The idea here is that, although we rely on external processes
(cargo & rustc), we are actually using their stable interfaces, so we
might just mock out the outputs.
Long term, I would like to try to virtualize IO here, so as to do such
mocking in a more principled way, but lets start simple.
Should we forgo the mocking and just call `cargo metadata` directly
perhaps? Touch question -- I personally feel that fast, in-process tests
are more important in this case than any extra assurance we get from
running the real thing.
Super-long term, we would probably want to extend our heavy tests to
cover more use-cases, but we should figure a way to do that without
slowing the tests down for everyone.
Perhaps we need two-tiered bors system, where we pull from `master` into
`release` branch only when an additional set of tests passes?
The completion of cfg will look at the enabled cfg keys when
performing completion.
It will also look crate features when completing a feature cfg
option. A fixed list of known values for some cfg options are
provided.
For unknown keys it will look at the enabled values for that cfg key,
which means that completion will only show enabled options for those.
9227: Add a config setting to disable the 'test' cfg in specified crates r=matklad a=lf-
If you are opening libcore from rust-lang/rust as opposed to e.g.
goto definition from some other crate which would use the sysroot
instance of libcore, a `#![cfg(not(test))]` would previously have made
all the code excluded from the module tree, breaking the editor
experience.
Core does not need to ever be edited with `#[cfg(test)]` enabled,
as the tests are in another crate.
This PR puts in a slight hack that checks for the crate name "core" and
turns off `#[cfg(test)]` for that crate.
Fixes#9203Fixes#9226
Co-authored-by: Jade <software@lfcode.ca>
If you are opening libcore from rust-lang/rust as opposed to e.g.
goto definition from some other crate which would use the sysroot
instance of libcore, a `#![cfg(not(test))]` would previously have made
all the code excluded from the module tree, breaking the editor
experience.
This puts in a slight hack that checks for the crate name "core" and
turns off `#[cfg(test)]`.
Cargo commands are affected by the `.cargo/config` files above
their working directory. If cargo is invoked from above the directory
holding `Cargo.toml`, it may not pick up important settings like
registry replacements, causing it to behave differently or even fail.
Most cargo invocations are currently setting their working directories
to the directory containing `Cargo.toml`, but a couple of paths remain
in which cargo is invoked from the default workspace root instead.
This change fixes that, resolving some cargo check failures that I
experienced in a multi-root workspace in which packages used different
registries.
At the moment,the popup is just a bazillion of Cargo's "Compiling this\nCompiling that",
which is not that useful.
--quiet still displays error, which is what we needc
reading both stdout & stderr is a common gotcha, you need to drain them
concurrently to avoid deadlocks. Not sure why I didn't do the right
thing from the start. Seems like I assumed the stderr is short? That's
not the case when cargo spams `compiling xyz` messages
