Repository navigation
Enable proc macros by default #7328
Description
Proc macros are opt-in, we should make them opt-out. Part of #7325 (comment)
Steps:
- cleanup settings naming, docs, location and semantics. Current settings are a bit of a mess.
- make sure that proc macros are loaded asynchronously. At the moment, we run
cargo checkandcargo metadatatogether. Instead, we should first run only metadata, immediatelly start suggesting cod insight, and loadcargo checkinfo in backgrooud. This should also pave the way for reloading things when build.rs / proc macros change. - (ideally) implement ABI detection, so that we don't silently crash on ABI misatch
Reacted by Kenny Kerr, Jake Goulding, Tomas Miklovic and Virgiel
Activity
matklad commentedon Jan 18, 2021
cc #6448 and @edwin0cheng
edwin0cheng commentedon Jan 18, 2021
#6822 maybe the first step
edwin0cheng commentedon Jan 19, 2021
Do we want to integrate it with
flycheck?matklad commentedon Jan 19, 2021
I don't think so, they have different conditions for when they must be recomputed.
edwin0cheng commentedon Jan 19, 2021
One of the problems here is
cargo checkwill block anothercargo check, and it will make users confused what happen under the hoodWe have to make sure the progress bar will provide enough information about it.
edwin0cheng commentedon Jan 22, 2021
@matklad , after #7387,
BuildDatarepresents the build script related data we fetch fromcargo check.And next step will be putting it into
salsaas input (with a key ofCrateId).matklad commentedon Jan 22, 2021
Hm, I think we just need to set the crate graph, rather than introducing a new input? We'll need to modify the graph for features anyway. I imagine we want to add
build_info: Option<BuildInfo>toto_crate_graphfunction. Then, the global state will hold current metadata result, current build info, and merge them as appropriate.edwin0cheng commentedon Jan 22, 2021
Just want to clarify :
If I understand correctly, In your approach, when I change a single
build.rsin dependency, a modifedCrateGraphwill be set to salsa. But almost all things depends onCrateGraphinsalsa, so they will be have to rebuild, right ? Did I miss something here?matklad commentedon Jan 22, 2021
Right! The same already happens to
Cargo.tomledit. I think that long term we should be smarter here and don't store crate graph as a single value in salsa, but this is orthogonal to the work here.Merge #7412
edwin0cheng commentedon Feb 8, 2021
Some crazy ideas:
Can we use the debug information ot figure out the ABI in
debug=1case (and at least in CI) ? What I mean is, we could extract the dwarf information from a dynamic library and find out some important functions & structures signatures in src/proc_macro/bridge/client.rs. @bjorn3 do you have any experience about it ?Another idea is, we could use rustc-nightly in CI and compare these structures side by side, but it will only detect what changed in nightly but not stable.
bjorn3 commentedon Feb 8, 2021
The DWARF emitted by rustc is unstable. You need
debug=2by the way for figuring out the ABI.debug=1only enables lineinfo. It seems that proc_macro is only compiled withdebug=1, so the necessary info is missing: