Add new unstable attribute: `#[export_visibility = ...]`. #151431

anforowicz · 2026-01-20T21:02:55Z

This PR is an implementation of the RFC tracked in #151425

rustbot · 2026-01-20T21:02:59Z

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

rustbot · 2026-01-20T21:03:01Z

r? @chenyukang

rustbot has assigned @chenyukang.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Kivooeo · 2026-01-20T21:29:28Z

i had a quick look, mostly looks good, but i'd like to maybe @JonathanBrouwer take a look on this as well, i may overlooked something

r? JonathanBrouwer

JonathanBrouwer · 2026-01-20T21:36:42Z

Would like to take a look, will do so tomorrow :)

JonathanBrouwer

Some minor questions, looks good on a high level :)

View changes since this review

compiler/rustc_attr_parsing/src/attributes/codegen_attrs.rs

JonathanBrouwer · 2026-01-21T08:44:09Z

compiler/rustc_attr_parsing/src/attributes/codegen_attrs.rs

+            return None;
+        };
+        let Ok(visibility) = ExportVisibilityAttrValue::from_str(sv.as_str()) else {
+            cx.emit_err(InvalidExportVisibility {


Could this use cx.expected_specific_argument_strings instead?
(not sure)

I am also not sure. Right now the new attribute expects a string literal as an argument (e.g. #[export_visibility = "target_default"] - this is the syntax that has been used so far by the RFC) . And it seems that expected_specific_argument_strings is meant to be used with symbols rather than with string literals (e.g. #[export_visibility = target_default]). Do you think the new attribute should use the latter syntax?

JonathanBrouwer · 2026-01-21T08:50:05Z

compiler/rustc_codegen_ssa/src/codegen_attrs.rs

+                export_visibility_span,
+                "#[export_visibility = ...]` will be ignored without \
+                 `export_name`, `no_mangle`, or similar attribute",
+            );


Can we make these struct errors?
In my opinion these are still nicer for simple errors like this. If you strongly disagree feel free to keep them like this

Could you please help me understand what you mean by "struct errors"? Can you point at a piece of code that I should mimic?

Are you asking me to hoist the error string into impl DiagMessage for NewStructForThisParticularError?

compiler/rustc_hir/src/attrs/data_structures.rs

JonathanBrouwer · 2026-01-21T08:56:47Z

compiler/rustc_hir/src/attrs/encode_cross_crate.rs

            EiiImpls(..) => No,
            ExportName { .. } => Yes,
            ExportStable => No,
+            ExportVisibility { .. } => Yes,


Is exporting this attribute needed? (Not sure, genuine question)

I am also not sure. I think if #[export_name = ...] needs to be exported, then so does #[export_visibility = ...] although I can't really convincingly point to a specific scenario where this is needed.

rustbot · 2026-01-21T08:57:44Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

tgross35 · 2026-01-22T08:20:20Z

tests/codegen-llvm/export-visibility.rs

+// Exact LLVM IR differs depending on the target triple (e.g. `hidden constant`
+// vs `internal constant` vs `constant`).  Because of this, we only apply the
+// specific test expectations below to one specific target triple.  If needed,
+// additional targets can be covered by adding copies of this test file with
+// a different `only-X` directive.
+//
+//@     only-x86_64-unknown-linux-gnu


It would be good to use add-minicore here so it gets checked on all targets:

//@ add-minicore //@ compile-flags: --target x86_64-unknown-linux-gnu #![feature(no_core)] #![no_core]

Possibly also roll this into the revisions so different targets wouldn't need different files.

//@ revisions: LINUX-X86-HIDDEN LINUX-X86-PROTECTED //@ [LINUX-X86-HIDDEN,LINUX-X86-PROTECTED] compile-flags: --target x86_64-unknown-linux-gnu ...

Adding //@ add-minicore + #![feature(no_core)] + #![no_core] results in build errors of the test code:

error: cannot find macro `line` in this scope --> /usr/local/google/home/lukasza/src/github/rust/tests/codegen-llvm/export-visibility.rs:82:5 | 82 | line!() | ^^^^

And also another error that I don't quite understand:

error: requires `sized` lang_item --> /usr/local/google/home/lukasza/src/github/rust/tests/codegen-llvm/export-visibility.rs:43:1 | 43 | pub static TEST_STATIC_NO_ATTR: [u8; 7] = *b"static1"; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think I'd rather avoid multiplying test expectations and revisions by multiple target platforms. I think focusing on x86_64 in this test is ok. FWIW I tried explaining this in the comment in the new test file:

// Exact LLVM IR differs depending on the target triple (e.g. `hidden constant` // vs `internal constant` vs `constant`). Because of this, we only apply the // specific test expectations below to one specific target triple. If needed, // additional targets can be covered by adding copies of this test file with // a different `only-X` directive. // //@ only-x86_64-unknown-linux-gnu

For now maybe I can leave things as-is here, but also try to add make-based, end-to-end tests.

Adding //@ add-minicore + #![feature(no_core)] + #![no_core] results in build errors of the test code:

error: cannot find macro `line` in this scope --> /usr/local/google/home/lukasza/src/github/rust/tests/codegen-llvm/export-visibility.rs:82:5 | 82 | line!() | ^^^^

Could it just return a different int rather than line!()?

And also another error that I don't quite understand:

error: requires `sized` lang_item --> /usr/local/google/home/lukasza/src/github/rust/tests/codegen-llvm/export-visibility.rs:43:1 | 43 | pub static TEST_STATIC_NO_ATTR: [u8; 7] = *b"static1"; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Huh, this definitely happened with //@ add-minicore? Minicore should pull it in

rust/tests/auxiliary/minicore.rs

Lines 58 to 63 in d222ddc

#[lang = "sized"]

#[diagnostic::on_unimplemented(

message = "the size for values of type `{Self}` cannot be known at compilation time",

label = "doesn't have a size known at compile-time"

)]

pub trait Sized: MetaSized {}

. If you push, I can take a look.

For reference https://github.com/rust-lang/rust/blob/d222ddc4d90743dfc1e53b610be8fc9d95893d2c/src/doc/rustc-dev-guide/src/tests/minicore.md

I think I'd rather avoid multiplying test expectations and revisions by multiple target platforms. I think focusing on x86_64 in this test is ok. FWIW I tried explaining this in the comment in the new test file:

I agree that testing only a x86-64 target is good. But only- restricts the host in addition to the target, so my suggestions were intended to drop it and use --target with minicore instead (just a convenience so anyone can run the tests easy, even if they're not on an x64 Linux machine).

tgross35 · 2026-01-22T08:43:31Z

tests/codegen-llvm/export-visibility.rs

Because of how complex and target-specific everything linker-related is, I think an end-to-end test in tests/run-make would be great to cover an ELF/PE/Mach-O target. Then you have access to the object crate via run_make_support for checking symbol visibility.

To allow each object file type to be built on all platforms with just --target, the test can use a minicore like

rust/tests/run-make/wasm-unexpected-features/foo.rs

Line 27 in b765963

mod minicore {

(unfortunately there is nothing convenient like what codegen tests have with //@ add-minicore).

rustbot · 2026-01-24T00:33:00Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 20, 2026

rustbot assigned chenyukang Jan 20, 2026

rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 20, 2026

rustbot assigned JonathanBrouwer and unassigned chenyukang Jan 20, 2026

This comment has been minimized.

Sign in to view

JonathanBrouwer requested changes Jan 21, 2026

View reviewed changes

rustbot 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 Jan 21, 2026

tgross35 mentioned this pull request Jan 22, 2026

Tracking Issue for #[export_visibility = ...] attribute #151425

Open

3 tasks

tgross35 reviewed Jan 22, 2026

View reviewed changes

Add new unstable attribute: #[export_visibility = ...].

8dc8f60

anforowicz force-pushed the export-visibility branch from 2043b51 to 8dc8f60 Compare January 24, 2026 00:32

	#[lang = "sized"]
	#[diagnostic::on_unimplemented(
	message = "the size for values of type `{Self}` cannot be known at compilation time",
	label = "doesn't have a size known at compile-time"
	)]
	pub trait Sized: MetaSized {}

Uh oh!

Add new unstable attribute: #[export_visibility = ...]. #151431

Are you sure you want to change the base?

Add new unstable attribute: #[export_visibility = ...]. #151431

Uh oh!

Conversation

anforowicz commented Jan 20, 2026

Uh oh!

rustbot commented Jan 20, 2026

Uh oh!

rustbot commented Jan 20, 2026

Uh oh!

Kivooeo commented Jan 20, 2026

Uh oh!

JonathanBrouwer commented Jan 20, 2026

Uh oh!

This comment has been minimized.

JonathanBrouwer left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jan 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jan 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Add new unstable attribute: `#[export_visibility = ...]`. #151431

Add new unstable attribute: `#[export_visibility = ...]`. #151431

JonathanBrouwer left a comment •

edited by rustbot

Loading