Add `force` option for `--extern` flag #109421

mhammerly · 2023-03-21T01:02:24Z

When --extern force:foo=libfoo.so is passed to rustc and foo is not actually used in the crate, ~~inject an extern crate foo; statement into the AST~~ force it to be resolved anyway in CrateLoader::postprocess(). This allows you to, for instance, inject a #[panic_handler] implementation into a #![no_std] crate without modifying its source so that it can be built as a dylib. It may also be useful for #![panic_runtime] or #[global_allocator]/#![default_lib_allocator] implementations.

My work previously involved integrating Rust into an existing C/C++ codebase which was built with Buck and shipped on, among other platforms, Android. When targeting Android, Buck builds all "native" code with shared linkage* so it can be loaded from Java/Kotlin. My project was not itself #![no_std], but many of our dependencies were, and they would fail to build with shared linkage due to a lack of a panic handler. With this change, that project can add the new force option to the std dependency it already explicitly provides to every crate to solve this problem.

*This is an oversimplification - Buck has a couple features for aggregating dependencies into larger shared libraries, but none that I think sustainably solve this problem.

The AST injection happens after macro expansion around where we similarly inject a test harness and proc-macro harness. The resolver's list of actually-used extern flags is populated during macro expansion, and if any of our --extern arguments have the force option and weren't already used, we inject an extern crate statement for them. The injection logic was added in rustc_builtin_macros as that's where similar injections for tests, proc-macros, and std/core already live.

(New contributor - grateful for feedback and guidance!)

rustbot · 2023-03-21T01:02:33Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jackh726 (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

clubby789 · 2023-03-21T02:51:06Z

I believe adding a new option like this requires a Major Change Proposal

mhammerly · 2023-03-21T02:56:04Z

A similar change (#96067) didn't go through that process afaict, but if that's what's appropriate I'm happy to do it! cc @ehuss who seems to have implemented the first --extern options in #67074 - what do you think?

ehuss · 2023-03-21T03:13:49Z

I'm not on the compiler team, but I believe the MCP is the process nowadays.

est31 · 2023-03-21T03:20:41Z

This will probably remain a buck-only feature, as the one added by #96067 was too. As in, for cargo the problem should already solved because even if you specify some crate to be compiled as cdylib, the crates it depends on aren't. Also, cargo doesn't specify any explicit extern param for depending on std, using the sysroot mechanism instead.

I guess this feature is the crate-level equivalent of the #[used] attribute, so there is precedent both for the feature as well as options/flags on --extern params.

mhammerly · 2023-03-21T03:32:20Z

@rustbot blocked

i'll create an MCP and then bump for review later

EDIT: MCP rust-lang/compiler-team#605

petrochenkov · 2023-03-21T13:31:45Z

Injecting extern crate statements is a pretty large hammer that may have unintended consequences.
I'm not actually sure that the current implementation works as written, extern crate items are processed during expansion and if they are inserted after it they are left unprocessed (unless some error recovery logic processes them?).

I suggest directly calling CrateLoader::resolve_crate on the crates from the --extern force list instead.
Probably somewhere inside CrateLoader::postprocess.

mhammerly · 2023-03-21T18:05:43Z

@petrochenkov I think the injected crates are processed fully; following the lead of test_harness.rs and proc_macro_harness.rs, extern_crate_statement::inject() calls cx.monotonic_expander().fully_expand_fragment(fragment).

That said, I went with the AST approach because it seemed like a "complete" injection and I worried merely calling resolve_crate() (which is all that is done for the profiler runtime too) could cause some non-obvious bug down the line. It sounds like you don't expect any issues, so if someone seconds the MCP I can make sure that approach works and update the PR before bumping for review!

As an aside: with std/core/compiler_builtins, test, and proc-macro injections happening around AST expansion and profiler_runtime, panic_runtime, and allocator shim injection happening in CrateLoader::postprocess(), do you think it's worth a separate change to establish a unified pattern?

petrochenkov · 2023-03-21T18:31:25Z

std/core/compiler_builtins

User code can refer to these (even to compiler_builtins on 2015 edition, if I'm not mistaken), so these are injected before doing any crate expansion.

compiler_builtins can probably be moved to postprocess with minimal breakage though, it's only there for linking.

test and proc-macro

These need to be in AST/HIR (or at least it's the simplest way to achieve the desired effect).
Also they just generate some regular code, not link to other crates.

profiler_runtime, panic_runtime, and allocator shim injection happening

These are added only for linking side effect, so they can be added directly to CStore without any AST.

mhammerly · 2023-03-21T18:53:50Z

thanks for those details! that all makes sense.

mhammerly · 2023-04-14T22:26:14Z

the MCP was seconded a week ago so I updated the PR to take @petrochenkov's suggestion: skip the extern crate statement and just call CrateLoader::resolve_crate() instead. the test cases I added before still work

@rustbot review

compiler/rustc_session/src/config.rs

tests/ui/extern-flag/redundant-force-extern.rs

tests/ui/extern-flag/no-force-extern.stderr

mhammerly · 2023-04-20T23:53:02Z

@rustbot review

thanks for the feedback!

mhammerly · 2023-05-08T23:50:07Z

@jsgf @pcwalton i've been in touch with @capickett about this separately, but you may also be interested in this PR. it lets you build vendored #![no_std] crates as dylibs by force-injecting a dependency on a crate that includes a panic handler (such as std). it'll be in 1.71.0 i think

Summary: When building buck sysroot from source, `#[no_std]` crates would fail to link as shared libraries, citing "missing #[panic_handler]". Matt introduced a mechanism in rust-lang/rust#109421 that allows us to still link in the default panic handler from `std`, even if the rest of the crate is completely unused (as is the case with `no_std` crates). The net result is that we no longer need to force static linkage when building no_std crates with buckified sysroot. Reviewed By: zertosh Differential Revision: D47402849 fbshipit-source-id: 35e31c7ff6d5683ff32a3c1eb2d67acec57acc8f

If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable@vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1] Fixes: 2f7ab12 ("Kbuild: add Rust support") Link: rust-lang/rust#111302 [2] Link: rust-lang/rust#109421 [3] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable@vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1] Fixes: 2f7ab12 ("Kbuild: add Rust support") Link: rust-lang/rust#111302 [2] Link: rust-lang/rust#109421 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable@vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1] Fixes: 2f7ab12 ("Kbuild: add Rust support") Link: rust-lang/rust#111302 [2] Link: rust-lang/rust#109421 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

commit ded103c upstream. If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable@vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1] Fixes: 2f7ab12 ("Kbuild: add Rust support") Link: rust-lang/rust#111302 [2] Link: rust-lang/rust#109421 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit ded103c ] If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable@vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1] Fixes: 2f7ab12 ("Kbuild: add Rust support") Link: rust-lang/rust#111302 [2] Link: rust-lang/rust#109421 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ded103c7eb23753f22597afa500a7c1ad34116ba upstream. If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable@vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1] Fixes: 2f7ab12 ("Kbuild: add Rust support") Link: rust-lang/rust#111302 [2] Link: rust-lang/rust#109421 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit ded103c ] If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable@vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1] Fixes: 2f7ab12 ("Kbuild: add Rust support") Link: rust-lang/rust#111302 [2] Link: rust-lang/rust#109421 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

stable inclusion from stable-v6.6.30 commit 4805d764f9041799a559dc2b112f227dcd26d599 bugzilla: https://gitee.com/openeuler/kernel/issues/I9MPZ8 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4805d764f9041799a559dc2b112f227dcd26d599 -------------------------------- commit ded103c7eb23753f22597afa500a7c1ad34116ba upstream. If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable@vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida@collabora.com> Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1] Fixes: 2f7ab12 ("Kbuild: add Rust support") Link: rust-lang/rust#111302 [2] Link: rust-lang/rust#109421 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>

rustbot assigned jackh726 Mar 21, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 21, 2023

This comment has been minimized.

Sign in to view

mhammerly force-pushed the extern-force-option branch 2 times, most recently from f08dc30 to 2c5c361 Compare March 21, 2023 01:52

rustbot added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 21, 2023

mhammerly mentioned this pull request Mar 21, 2023

Add force option for --extern flag rust-lang/compiler-team#605

Closed

3 tasks

petrochenkov self-assigned this Mar 21, 2023

mhammerly force-pushed the extern-force-option branch from 2c5c361 to 698c24f Compare April 14, 2023 22:18

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. labels Apr 14, 2023

petrochenkov reviewed Apr 17, 2023

View reviewed changes

compiler/rustc_session/src/config.rs Outdated Show resolved Hide resolved

tests/ui/extern-flag/redundant-force-extern.rs Outdated Show resolved Hide resolved

tests/ui/extern-flag/no-force-extern.stderr Outdated Show resolved Hide resolved

petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 17, 2023

petrochenkov unassigned jackh726 Apr 17, 2023

mhammerly force-pushed the extern-force-option branch from 698c24f to 76f076c Compare April 20, 2023 21:57

est31 mentioned this pull request Jun 26, 2023

Crate name found in --extern gets suggested verbatim on unresolved import #113035

Closed

est31 mentioned this pull request Jul 6, 2023

Disallow non-identifier-valid --extern crate names rust-lang/compiler-team#650

Closed

3 tasks

petrochenkov mentioned this pull request Jul 10, 2023

Hide compiler_builtins in the prelude #113557

Merged

ojeda mentioned this pull request Apr 22, 2024

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

71 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `force` option for `--extern` flag #109421

Add `force` option for `--extern` flag #109421

mhammerly commented Mar 21, 2023 •

edited

rustbot commented Mar 21, 2023

This comment has been minimized.

clubby789 commented Mar 21, 2023

mhammerly commented Mar 21, 2023

ehuss commented Mar 21, 2023

est31 commented Mar 21, 2023

mhammerly commented Mar 21, 2023 •

edited

petrochenkov commented Mar 21, 2023

mhammerly commented Mar 21, 2023

petrochenkov commented Mar 21, 2023

mhammerly commented Mar 21, 2023

mhammerly commented Apr 14, 2023

mhammerly commented Apr 20, 2023

mhammerly commented May 8, 2023

Add force option for --extern flag #109421

Add force option for --extern flag #109421

Conversation

mhammerly commented Mar 21, 2023 • edited

rustbot commented Mar 21, 2023

This comment has been minimized.

clubby789 commented Mar 21, 2023

mhammerly commented Mar 21, 2023

ehuss commented Mar 21, 2023

est31 commented Mar 21, 2023

mhammerly commented Mar 21, 2023 • edited

petrochenkov commented Mar 21, 2023

mhammerly commented Mar 21, 2023

petrochenkov commented Mar 21, 2023

mhammerly commented Mar 21, 2023

mhammerly commented Apr 14, 2023

mhammerly commented Apr 20, 2023

mhammerly commented May 8, 2023

Add `force` option for `--extern` flag #109421

Add `force` option for `--extern` flag #109421

mhammerly commented Mar 21, 2023 •

edited

mhammerly commented Mar 21, 2023 •

edited