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
Crate 1 contains a pub static item of that struct, with the field being initialized to a priv extern fn
Crate 2 contains a static item of the same struct which is initialized to the static item in crate 1
All crates are built as dylibs, and a program is linked against crate 2
Result
Crate 2 ends up referring directly to the priv extern fn in crate 1, which is not in the dynamic symbol table for the crate. The program fails to link.
This ensures that private functions exported through static initializers will
actually end up being public in the object file (so other objects can continue
to reference the function).
Closesrust-lang#13620
This ensures that private functions exported through static initializers will
actually end up being public in the object file (so other objects can continue
to reference the function).
Closes#13620
…r=Veykril
fix: check tail expressions more precisely in `extract_function`
Fixesrust-lang#13620
When extracting expressions with control flows into a function, we can avoid wrapping tail expressions in `Option` or `Result` when they are also tail expressions of the container we're extracting from (see rust-lang#7840, rust-lang#9773). This is controlled by `ContainerInfo::is_in_tail`, but we've been computing it by checking if the tail expression of the range to extract is contained in the container's syntactically last expression, which may be a block that contains both tail and non-tail expressions (e.g. in rust-lang#13620, the range to be extracted is not a tail expression but we set the flag to true).
This PR tries to compute the flag as precise as possible by utilizing `for_each_tail_expr()` (and also moves the flag to `Function` struct as it's more of a property of the function to be extracted than of the container).
Scenario
Result
Crate 2 ends up referring directly to the priv extern fn in crate 1, which is not in the dynamic symbol table for the crate. The program fails to link.
Code
crate1.rs
crate2.rs
main.rs
Makefile
Output
Excerpt of error:
The text was updated successfully, but these errors were encountered: