Description
For Leptos 0.7, we've switched our HTML rendering engine to use large recursive static types to represent the HTML tree, giving us significant benefits to final binary size and runtime speed, but unfortunately not to compile time.
To fix that, we've brought back the old behavior where we type erase the HTML components in the tree behind a feature flag for users to develop faster. However, we also added generic attribute spreading in this release to make our maintenance and user's code nicer and easier to write.
The crux of the issue here is implementing the trait that does that causes an error: cannot encode offset of relocations; object file too large on Mac after compiling for 10ish minutes and using 50GB of ram, with other issues on other platforms, but only with the AddAnyAttr trait. Not having attribute spreading in the type erased version severely limits its usefulness.
The trait can be found here but is basically this:
// Pre-erases output to reduce compile-time explosions
impl AddAnyAttr for AnyView {
type Output<SomeNewAttr: Attribute> = AnyView;
#[inline(never)]
fn add_any_attr<NewAttr: Attribute>(
self,
attr: NewAttr,
) -> Self::Output<NewAttr>
where
Self::Output<NewAttr>: RenderHtml,
{
let attr = attr.into_cloneable_owned();
let any_attr = attr.into_any_attr();
self.value.dyn_add_any_attr(any_attr)
}
}A similar issue was discussed broadly here, but I wanted to provide a specific reproducer for a more targeted issue in the hopes of a solution or a workaround. Please let me know if this is out of line.
This can be reproduced by running cargo +stable build --bin demo --features ssr in the main branch of this repo.
To fix(and disable attribute spreading), in the workspace Cargo.toml change the leptos branch to "any-attr-disabled", see the extra commit on that branch for the minimal change that allows compilation to succeed in about 1m30s. This leads us to the idea that this specific trait implementation brakes everything, even though it seems to be perfectly valid Rust.
Thanks to @zakstucke and all the other Leptos users who have worked on this and tested various workarounds