Alex Kladov

We recently re-implemented our coverage marks on top of linker hacks, the UX is quite nice: https://github.com/rust-analyzer/rust-analyzer/blob/46d4487b8900324fc6a523c8b6ebe036d28fd0fb/crates/test_utils/src/mark.rs

@nikomatsakis https://github.com/matklad/cov-mark, https://crates.io/crates/cov-mark though, for rust-analyzer, we use a copy-pasted impl, just because we already have a crate with "assorted test utils".

I think `RUSTC_BOOTSTRAP=1 RUSTFLAGS="-Zsymbol-mangling-version=v0" cargo llvm-lines` does this, [learned from the one who knows everything](https://github.com/rust-analyzer/rust-analyzer/issues/10065#issuecomment-907684139).

Ended up writing ad-hoc code to follow call chains: https://github.com/matklad/llcg

Another way to improve compile times is to get rid of `extra-traits` feature of `syn`, as that inflates compile times quite a bit: https://github.com/dtolnay/syn/issues/794#issuecomment-629215018

As a case study, it would be nice to switch https://github.com/Xudong-Huang/generator-rs from rustc_version to autocfg. As an option for stateless API, we coud consider this: ```rust impl AutoCfg { //...

See also https://github.com/rust-lang/cargo/issues/4423 TL;DR: cargo doesn’t make a good distinction between *host* rustflags and *target* rustflags, which I imagine would complicate matters here further.

Note that there's https://github.com/theduke/crates_io_api for querying crates.io API. So it seems to me that it should not be significantly harder to avoid depending on Cargo? Specifically: * call cargo-metadata to...

>Question: if the current Items could report their range, would this be a tangible benefit, or is that not useful to you on its own in the current architecture? Yeah,...

>I guess we want to use the same level of abstraction as the Chars iterator the parser uses. Not certain what that translates into Unicode-wise. You mean, exposing range of...