David Barsky

I wish it was that simple: when it comes to project loading/discovery, parts of rust-analyzer are lazy; other parts are eager. We should make all of it lazy, I described...

`tracing` _used_ to use the slab crate, but it wasn't particularly scalable across multiple cores. We should probably get a release of `sharded-slab` out, though.

I'm able to reproduce the intended behavior with the following: ```rust use tracing_subscriber::{filter::LevelFilter, prelude::*, Layer}; fn main() { let stdout_layer = tracing_subscriber::fmt::layer() .without_time() .with_filter(LevelFilter::ERROR); tracing_subscriber::registry() // .with(tracing_subscriber::fmt::layer().with_writer(std::io::sink)) .with(stdout_layer) .init(); tracing::error!("just...

This was blocked on https://github.com/rust-lang/chalk/pull/826, which I think still requires a release.

I think that if we want to simplify the VFS, it *will* need to take a dependency on Salsa. This means that the proc-macro-server-api will _also_ need a Salsa dependency.

The dependency graph is `proc-macro-srv-cli` -> `proc-macro-api` -> `span` -> `vfs`. Span declares `EditionedFileId`, which can be constructed from a `vfs::FileId`.

> Then we can continue as we did (do now? I don't remember), with span using a cfg and defining FileId as either a salsa::input or a wrapper around u32....

A downside of this proposal that I don't see mentioned is that it would make error recovery more difficult in IDEs like rust-analyzer or RustRover. Delimiters like parentheses/curly brackets make...

> @davidbarsky wrote: > > > A downside of this proposal that I don't see mentioned is that it would make error recovery more difficult in IDEs like rust-analyzer or...

The changes look good to me, can you open a corresponding PR to the master branch as well?