-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Export #[inline]
fns with extern indicators
#73034
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
src/librustc_typeck/collect.rs
Outdated
// with "internal" linkage and are never exported unless we're | ||
// building a `staticlib` or `cdylib` and they are marked | ||
// `#[no_mangle]`. | ||
tcx.codegen_fn_attrs(def_id).flags.contains(CodegenFnAttrFlags::NO_MANGLE) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is also #[export_name = "..."]
and #[linkage = "..."]
to consider so this should really be calling contains_extern_indicator
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't aware of contains_extern_indicator
, thank you so much for the suggestion!
src/librustc_typeck/collect.rs
Outdated
// `#[no_mangle]`. | ||
tcx.codegen_fn_attrs(def_id).flags.contains(CodegenFnAttrFlags::NO_MANGLE) | ||
&& (tcx.sess.crate_types().contains(&CrateType::Cdylib) | ||
|| tcx.sess.crate_types().contains(&CrateType::Staticlib)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to check the crate type here? Even when building rlib
s we'll still need to codegen and export #[no_mangle] #[inline]
items in case they're linked into a staticlib
or cdylib
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to check I understand between these two you're saying that #[inline]
should always be superseded by an extern indicator and crate-type/specifics of indicator are irrelevant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this should be done regardless of the output crate type.
#[inline] #[no_mangle]
fns in cdylibs and staticlibs#[inline]
fns with extern indicators
@bors r+ |
📌 Commit f57893b has been approved by |
…matthewjasper Export `#[inline]` fns with extern indicators In ancient history (rust-lang#36280) we stopped `#[inline]` fns being codegened if they weren't used. However, - rust-lang#72944 - rust-lang#72463 observe that when writing something like ```rust #![crate_type = "cdylib"] #[no_mangle] #[inline] pub extern "C" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves rust-lang#72944, resolves rust-lang#72463 (and maybe some more)
@bors r- Failed in #73240 (comment): The function |
failed in rollup log @bors r- |
I can't reproduce this locally, is this an architecture specific failure? |
@mati865 that'll do it 😅 Thanks! |
So looking into this, |
|
@bors r+ |
📌 Commit e8e0a0e has been approved by |
…matthewjasper Export `#[inline]` fns with extern indicators In ancient history (rust-lang#36280) we stopped `#[inline]` fns being codegened if they weren't used. However, - rust-lang#72944 - rust-lang#72463 observe that when writing something like ```rust #![crate_type = "cdylib"] #[no_mangle] #[inline] pub extern "C" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves rust-lang#72944, resolves rust-lang#72463 (and maybe some more)
…matthewjasper Export `#[inline]` fns with extern indicators In ancient history (rust-lang#36280) we stopped `#[inline]` fns being codegened if they weren't used. However, - rust-lang#72944 - rust-lang#72463 observe that when writing something like ```rust #![crate_type = "cdylib"] #[no_mangle] #[inline] pub extern "C" fn foo() { // ... } ``` we really _do_ want `foo` to be codegened. This change makes this the case. Resolves rust-lang#72944, resolves rust-lang#72463 (and maybe some more)
…arth Rollup of 17 pull requests Successful merges: - rust-lang#70551 (Make all uses of ty::Error delay a span bug) - rust-lang#71338 (Expand "recursive opaque type" diagnostic) - rust-lang#71976 (Improve diagnostics for `let x += 1`) - rust-lang#72279 (add raw_ref macros) - rust-lang#72628 (Add tests for 'impl Default for [T; N]') - rust-lang#72804 (Further tweak lifetime errors involving `dyn Trait` and `impl Trait` in return position) - rust-lang#72814 (remove visit_terminator_kind from MIR visitor) - rust-lang#72836 (Complete the std::time documentation to warn about the inconsistencies between OS) - rust-lang#72968 (Only highlight doc search results via mouseover if mouse has moved) - rust-lang#73034 (Export `#[inline]` fns with extern indicators) - rust-lang#73315 (Clean up some weird command strings) - rust-lang#73320 (Make new type param suggestion more targetted) - rust-lang#73361 (Tweak "non-primitive cast" error) - rust-lang#73425 (Mention functions pointers in the documentation) - rust-lang#73428 (Fix typo in librustc_ast docs) - rust-lang#73447 (Improve document for `Result::as_deref(_mut)` methods) - rust-lang#73476 (Added tooltip for should_panic code examples) Failed merges: r? @ghost
In ancient history (#36280) we stopped
#[inline]
fns being codegened if they weren't used. However,#[inline]
prevents symbol from appearing instaticlib
output #72463observe that when writing something like
we really do want
foo
to be codegened. This change makes this the case.Resolves #72944, resolves #72463 (and maybe some more)