Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inject compiler_builtins during postprocessing and ensure it is made private #135501

Merged
merged 7 commits into from
Feb 23, 2025

Conversation

tgross35
Copy link
Contributor

@tgross35 tgross35 commented Jan 14, 2025

Follow up of #135278

Do the following:

  • Inject compiler_builtins during postprocessing, rather than injecting extern crate compiler_builtins as _ into the AST
  • Do not make dependencies of std private by default (this was added in Exclude dependencies of std for diagnostics #135278)
  • Make sure sysroot crates correctly mark their dependencies private/public
  • Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
  • Do the compiler_builtins update that has been blocked on this

There is more detail in the commit messages. This includes the changes I was working on in #136226.

try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2

r? @bjorn3

@rustbot

This comment was marked as outdated.

@rustbot 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. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 14, 2025
@tgross35 tgross35 marked this pull request as draft January 14, 2025 20:07
@tgross35
Copy link
Contributor Author

The test still fails, and I cannot chase down how gimli is getting into the sysroot as non-private. Locally I am testing with submodules updated too.

r? bjorn3

@rust-log-analyzer

This comment has been minimized.

@bors

This comment was marked as outdated.

@bjorn3
Copy link
Member

bjorn3 commented Jan 20, 2025

Maybe you can make the code that checks if a crate is private for diagnostics check if all paths to reach a dependency are private and if so consider the dependency to be private even if the direct dependent crate doesn't mark it as private?

@tgross35
Copy link
Contributor Author

Do you mean to do that as part of the is_private_dep check?

I am apparently missing some path since exposing more traits in builtins seems to leak into diagnostics still #135560. Haven't looked into it yet, but I suppose that might fix it.

@bjorn3
Copy link
Member

bjorn3 commented Jan 23, 2025

Do you mean to do that as part of the is_private_dep check?

Yes

@tgross35 tgross35 force-pushed the stdlib-dependencies-private branch from 560b580 to ee49697 Compare January 28, 2025 21:23
@tgross35
Copy link
Contributor Author

It looks like the reason compiler_builtins is not showing up as private is because it shows up as an extern crate item with a no-location span, which gets picked up at

self.build_reduced_graph_for_item(item);
. I'm still trying to figure out where this would come from.

@tgross35
Copy link
Contributor Author

This looks like a possibility

let item = if name == sym::compiler_builtins {
// compiler_builtins is a private implementation detail. We only
// need to insert it into the crate graph for linking and should not
// expose any of its public API.
//
// FIXME(#113634) We should inject this during post-processing like
// we do for the panic runtime, profiler runtime, etc.
cx.item(
span,
Ident::new(kw::Underscore, ident_span),
thin_vec![],
ast::ItemKind::ExternCrate(Some(name)),
)

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@tgross35 tgross35 force-pushed the stdlib-dependencies-private branch 2 times, most recently from b32d8d1 to 7a6a6cd Compare January 28, 2025 22:45
@rust-log-analyzer

This comment has been minimized.

tgross35 added a commit to tgross35/rust that referenced this pull request Jan 28, 2025
Currently, marking a dependency private does not automatically make all
its child dependencies private. Resolve this by making its children
private by default as well.

[1]: rust-lang#135501 (comment)
tgross35 added a commit to tgross35/rust that referenced this pull request Jan 28, 2025
Currently, marking a dependency private does not automatically make all
its child dependencies private. Resolve this by making its children
private by default as well.

[1]: rust-lang#135501 (comment)
@tgross35 tgross35 force-pushed the stdlib-dependencies-private branch from 5354933 to 9c9ea48 Compare January 28, 2025 23:24
@tgross35
Copy link
Contributor Author

@bors try

@tgross35 tgross35 changed the title [WIP] Mark sysroot dependencies private Resolve compiler_builtins not being treated as private; clean up #135278 Jan 28, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 28, 2025
…, r=<try>

Resolve `compiler_builtins` not being treated as private; clean up rust-lang#135278

Follow up of rust-lang#135278

try-job: test-various
@bors

This comment was marked as outdated.

Remove the portion of ed63539 that automatically sets crates private
based on whether they are dependencies of `std`. Instead, this is
controlled by dependency configuration in `Cargo.toml`.
In [1], most dependencies of `std` and other sysroot crates were marked
private, but this did not happen for `alloc` and `test`. Update these
here, marking public standard library crates as the only non-private
dependencies.

[1]: rust-lang#111076
Currently, marking a dependency private does not automatically make all
its child dependencies private. Resolve this by making its children
private by default as well.

This also resolves some FIXMEs for tests that are intended to fail but
previously passed.

[1]: rust-lang#135501 (comment)
The recent fixes to private dependencies exposed some cases in the UEFI
module where private dependencies are exposed in a public interface.
These do not need to be crate-public, so change them to `pub(crate)`.
@tgross35 tgross35 force-pushed the stdlib-dependencies-private branch from 0827f25 to 9392580 Compare February 21, 2025 17:37
@tgross35
Copy link
Contributor Author

I kept that in case a retest with further changes was needed. Dropped it now and squashed the last fixup.

@bjorn3
Copy link
Member

bjorn3 commented Feb 21, 2025

@bors r+

@bors
Copy link
Contributor

bors commented Feb 21, 2025

📌 Commit 9392580 has been approved by bjorn3

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 21, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 22, 2025
…te, r=bjorn3

Inject `compiler_builtins` during postprocessing and ensure it is made private

Follow up of rust-lang#135278

Do the following:

* Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST
* Do not make dependencies of `std` private by default (this was added in rust-lang#135278)
* Make sure sysroot crates correctly mark their dependencies private/public
* Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
* Do the `compiler_builtins` update that has been blocked on this

There is more detail in the commit messages. This includes the changes I was working on in rust-lang#136226.

try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 22, 2025
…te, r=bjorn3

Inject `compiler_builtins` during postprocessing and ensure it is made private

Follow up of rust-lang#135278

Do the following:

* Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST
* Do not make dependencies of `std` private by default (this was added in rust-lang#135278)
* Make sure sysroot crates correctly mark their dependencies private/public
* Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
* Do the `compiler_builtins` update that has been blocked on this

There is more detail in the commit messages. This includes the changes I was working on in rust-lang#136226.

try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 22, 2025
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#135501 (Inject `compiler_builtins` during postprocessing and ensure it is made private)
 - rust-lang#136543 (intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic)
 - rust-lang#137121 (stabilize `(const_)ptr_sub_ptr`)
 - rust-lang#137180 (Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes)
 - rust-lang#137256 (compiler: untangle SIMD alignment assumptions)
 - rust-lang#137298 (Check signature WF when lowering MIR body)
 - rust-lang#137415 (Remove invalid suggestion of into_iter for extern macro)

r? `@ghost`
`@rustbot` modify labels: rollup
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Feb 22, 2025
…te, r=bjorn3

Inject `compiler_builtins` during postprocessing and ensure it is made private

Follow up of rust-lang#135278

Do the following:

* Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST
* Do not make dependencies of `std` private by default (this was added in rust-lang#135278)
* Make sure sysroot crates correctly mark their dependencies private/public
* Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
* Do the `compiler_builtins` update that has been blocked on this

There is more detail in the commit messages. This includes the changes I was working on in rust-lang#136226.

try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 22, 2025
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#135501 (Inject `compiler_builtins` during postprocessing and ensure it is made private)
 - rust-lang#136543 (intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic)
 - rust-lang#137121 (stabilize `(const_)ptr_sub_ptr`)
 - rust-lang#137180 (Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes)
 - rust-lang#137256 (compiler: untangle SIMD alignment assumptions)
 - rust-lang#137383 (stabilize `unsigned_is_multiple_of`)
 - rust-lang#137415 (Remove invalid suggestion of into_iter for extern macro)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 23, 2025
…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#135501 (Inject `compiler_builtins` during postprocessing and ensure it is made private)
 - rust-lang#137121 (stabilize `(const_)ptr_sub_ptr`)
 - rust-lang#137180 (Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes)
 - rust-lang#137256 (compiler: untangle SIMD alignment assumptions)
 - rust-lang#137383 (stabilize `unsigned_is_multiple_of`)
 - rust-lang#137415 (Remove invalid suggestion of into_iter for extern macro)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 1610bfb into rust-lang:master Feb 23, 2025
6 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Feb 23, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Feb 23, 2025
Rollup merge of rust-lang#135501 - tgross35:stdlib-dependencies-private, r=bjorn3

Inject `compiler_builtins` during postprocessing and ensure it is made private

Follow up of rust-lang#135278

Do the following:

* Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST
* Do not make dependencies of `std` private by default (this was added in rust-lang#135278)
* Make sure sysroot crates correctly mark their dependencies private/public
* Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
* Do the `compiler_builtins` update that has been blocked on this

There is more detail in the commit messages. This includes the changes I was working on in rust-lang#136226.

try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2
@tgross35 tgross35 deleted the stdlib-dependencies-private branch February 23, 2025 05:30
tgross35 added a commit to tgross35/compiler-builtins that referenced this pull request Feb 24, 2025
Replace `public_test_dep!` by placing optionally public items into new
modules, then controlling what is exported with the `public-test-deps`
feature.

This is nicer for automatic formatting and diagnostics.

This is a reland of 2e2a925 ("Eliminate the use of
`public_test_dep!`"), which was reverted in 47e50fd ('Revert "Eliminate
the use of..."') due to a bug exposed at [1], reapplied in d4abaf4
because the issue should have been fixed in [2], then reverted again in
f6eef07 because [2] did not actually fix the issue.

[3] has landed in rust-lang/rust since then, which should resolve the
last problem remaining after [2]. So, apply this change for what is
hopefully the final time.

[1]: rust-lang/rust#128691
[2]: rust-lang/rust#135278
[3]: rust-lang/rust#135501
tgross35 added a commit to rust-lang/compiler-builtins that referenced this pull request Feb 24, 2025
Replace `public_test_dep!` by placing optionally public items into new
modules, then controlling what is exported with the `public-test-deps`
feature.

This is nicer for automatic formatting and diagnostics.

This is a reland of 2e2a925 ("Eliminate the use of
`public_test_dep!`"), which was reverted in 47e50fd ('Revert "Eliminate
the use of..."') due to a bug exposed at [1], reapplied in d4abaf4
because the issue should have been fixed in [2], then reverted again in
f6eef07 because [2] did not actually fix the issue.

[3] has landed in rust-lang/rust since then, which should resolve the
last problem remaining after [2]. So, apply this change for what is
hopefully the final time.

[1]: rust-lang/rust#128691
[2]: rust-lang/rust#135278
[3]: rust-lang/rust#135501
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tidy Area: The tidy tool S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants