-
Notifications
You must be signed in to change notification settings - Fork 13k
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.
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
Static items can result in references to unexported symbols #13620
Labels
A-linkage
Area: linking into static, shared libraries and binaries
Comments
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
May 2, 2014
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 rust-lang#13620
bors
added a commit
that referenced
this issue
May 3, 2014
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 9, 2023
…r=Veykril fix: check tail expressions more precisely in `extract_function` Fixes rust-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).
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Nov 7, 2024
…onst, r=Manishearth Fire large_const_arrays for computed array lengths changelog: [`large_const_arrays`]: Lint now fires when the length is determined by an expression
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: