Skip to content

-Z default-visibility option #782

@davidlattimore

Description

@davidlattimore

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.

Activity

added
major-changeA proposal to make a major change to rustc
T-compilerAdd this label so rfcbot knows to poll the compiler team
on Sep 6, 2024
rustbot

rustbot commented on Sep 6, 2024

@rustbot
Collaborator

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.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rustbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rustbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler @rust-lang/compiler-contributors

lqd

lqd commented on Sep 19, 2024

@lqd
Member

@rustbot second

added
final-comment-periodThe FCP has started, most (if not all) team members are in agreement
on Sep 19, 2024
apiraino

apiraino commented on Sep 30, 2024

@apiraino
Contributor

@rustbot label -final-comment-period +major-change-accepted

added and removed
final-comment-periodThe FCP has started, most (if not all) team members are in agreement
on Sep 30, 2024

9 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-compilerAdd this label so rfcbot knows to poll the compiler teammajor-changeA proposal to make a major change to rustcmajor-change-acceptedA major change proposal that was accepted

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @lqd@apiraino@davidlattimore@rustbot

        Issue actions

          -Z default-visibility option · Issue #782 · rust-lang/compiler-team