You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the MIR linker with assess changes what we codegen (to just that reachable from the assessed crate), and consequently changes what "unsupported features" are hit during codegen (unreachable code is never codegen'd). This is a change from the legacy linker, and merits thinking about what we want to see from the assess report.
I think this change is probably a positive one: We're assessing the crate being built, so if there's code in dependencies that's never used, we shouldn't complain about it. But it makes it hard to reproduce our old metrics for unsupported code in crates, and it raises the question of what information should be reported in the unsupported features table.
I think we want to see two tables:
Early report on what unsupported features were found during codegen, as we do now, but with new columns. Currently we report two columns (number of crates affected, total instances of construct). I think we should instead report (instances in primary crate, instances potentially reachable in dependencies, and maybe also total?).
Later on, after running tests, we'll also want to see unsupported features we actually hit in the tests. I'm not sure yet if this should be its own table, or reproduce the original table with a new column (and new sort order on that column).
I believe we should then be able to reproduce our original metrics, as "instances in primary crate" (run for every crate and then aggregated) should be enough to compute the original metric (as originally, we actually did still skip things that were unreachable from "pub" items).
The text was updated successfully, but these errors were encountered:
Using the MIR linker with assess changes what we codegen (to just that reachable from the assessed crate), and consequently changes what "unsupported features" are hit during codegen (unreachable code is never codegen'd). This is a change from the legacy linker, and merits thinking about what we want to see from the assess report.
I think this change is probably a positive one: We're assessing the crate being built, so if there's code in dependencies that's never used, we shouldn't complain about it. But it makes it hard to reproduce our old metrics for unsupported code in crates, and it raises the question of what information should be reported in the unsupported features table.
I think we want to see two tables:
I believe we should then be able to reproduce our original metrics, as "instances in primary crate" (run for every crate and then aggregated) should be enough to compute the original metric (as originally, we actually did still skip things that were unreachable from "pub" items).
The text was updated successfully, but these errors were encountered: