Skip to content

New unsupported features table for assess #1819

@tedinski

Description

@tedinski

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:

  1. 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?).
  2. 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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions