Skip to content

Fix generating bindings for dead code #8065

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
alexcrichton merged 1 commit into from
Mar 14, 2024
Merged

Fix generating bindings for dead code #8065

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions crates/component-macro/tests/codegen/dead-code.wit
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
package a:b;

world imports {
import interface-with-live-type;
import interface-with-dead-type;
}

interface interface-with-live-type {
record live-type {
a: u32,
}
f: func() -> live-type;
}


interface interface-with-dead-type {
use interface-with-live-type.{live-type};

record dead-type {
a: u32,
}

variant v {
a(live-type),
b(dead-type),
}
}
Copy link
Copy Markdown
Contributor

@pchickey pchickey Mar 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not clear to me how this tests liveness since both interfaces are part of the imports?

Copy link
Copy Markdown
Member Author

@alexcrichton alexcrichton Mar 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah good point, I should clarify, liveness is calculated in terms of what's used by imported/exported functions. No function actually uses dead-type or v but live-type is used by a function, and so we don't generate bindings for dead-type and this PR fixes a bug where we previously tried to generate bindings for v despite nothing using it.

8 changes: 8 additions & 0 deletions crates/wit-bindgen/src/types.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,14 @@ impl std::ops::BitOrAssign for TypeInfo {

impl Types {
pub fn analyze(&mut self, resolve: &Resolve, world: WorldId) {
// Build up all type information first which is inherited through types,
// such as properties of borrows/lists/etc.
for (t, _) in resolve.types.iter() {
self.type_id_info(resolve, t);
}
Comment on lines +45 to +47
Copy link
Copy Markdown
Member

@elliottt elliottt Mar 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does doing this step first mean that the calls to self.type_info in type_info_func should never traverse the whole type (due to the early exit if the entry exists already)?

Copy link
Copy Markdown
Member Author

@alexcrichton alexcrichton Mar 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not for this, but the below bits would still need it for setting the owned/borrowed bits.

It's probably best to switching this to LiveSet one day as a future refactoring


// ... next handle borrowed/owned flags which aren't inherited through
// types.
let world = &resolve.worlds[world];
for (import, (_, item)) in world
.imports
Expand Down