-Z default-visibility option · Issue #782 · rust-lang/compiler-team (original) (raw)

Proposal

• Replace the existing -Z default-hidden-visibility with -Z default-visibility, which takes one of several different visibility levels as an argument.
• The motivation for doing this is to allow building shared objects with symbols that use protected visibility rather than default visibility.
• Using protected visibility means that those symbols cannot be interposed by the executable or by other shared objects earlier in the load order. This allows the compiler to emit direct references to those symbols when used within the same shared object that defines them. This is more efficient.
• Ideally all symbols emitted by rustc into shared objects would be protected by default unless there was a need for a particular symbol to be able to be interposed. i.e. we shouldn't pay the cost of having interposable symbols if we're not actually using that feature.
• Unfortunately GNU ld used to error if there were direct references to protected symbols and this was only fixed in GNU ld 2.40, so we can't emit symbols with protected visibility by default.
• We could probably however make protected symbols the default when linking with LLD.
• ELF on Linux names the visibility levels as "default", "protected" and "hidden"
• We could use these names as the values that are accepted by the -Z default-visibility option, however I'm a little uncomfortable with naming one of the options "default" if it may eventually not be the default. i.e. if we change the default to protected.
• One option would be to call this option something else, such as "interposable".
• Alternatively, we can just call it "default", but document that it isn't actually the default (if / when that happens).

Tracking issue for default-hidden-visibility: #656

PR that makes this change, but as a separate flag: rust-lang/rust#130005

Original issue that proposed changing to protected, but without a flag: rust-lang/rust#105518

Mentors or Reviewers

None

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.