Repository navigation
save-analysis: use a decoupled representation for dumped data #33348
Description
Activity
cc @nrc
Do you know the answer to my questions in the open problems part?
@aochagavia if the def id is from the local crate, then it should never return None. I think we can assume that and just unwrap. We do need to make sure we only call with local ids though, it is possible we could get a NodeId from an extern crate (via metadata or something?).
Currently, the
Dumptrait exposes internal types of the compiler, which is undesirable. It also forces the trait's implementors to write lowering code (as can be seen in the current implementation ofjson_dumper).Proposed solution
save-analysiscalledexternal_datawhere the new*Datastructs will live (they can be moved fromjson_dumper, along with the lowering code).Dumptrait to operate onsave_analysis::external_data::*instead of onsave_analysis::data::*.Some open problems
When getting a
DefIdfrom aNodeId, what should we do whentcx.map.opt_local_def_id(node_id)returnsNone? What does that mean? If we call the function with aNodeIdprovided by the compiler, should it always succeed? The current code doesn't make that assumption (see data.rs)