Add force option for --extern flag · Issue #605 · rust-lang/compiler-team (original) (raw)

Proposal

See also: rust-lang/rust#109421

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. 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.

The AST injection in the linked PR happens after macro expansion around where the compiler similarly injects 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 the compilation session's --extern arguments have the force option and aren't in that list, the compiler injects 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.

Documentation for this option should be added to the "--extern Options" page of the Rust Unstable book.

The particular situation prompting this MCP is a project to integrate Rust into a preexisting large C/C++ codebase. To summarize: this codebase builds with Buck and ships on, among other platforms, Android. When targeting Android, Buck builds "native" code with shared linkage so that it can be loaded by Java/Kotlin, and the project's many #![no_std] dependencies failed to build as they lacked a panic handler. With this change, that project can add a force option to the existing std dependency it specifies on every crate and solve the problem.

nounused (from rust-lang/rust#96067) is a similar Buck-centric --extern option.

Mentors or Reviewers

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.