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

Eagerly compute output_filenames #117584

Merged
merged 7 commits into from
Nov 27, 2023
Merged

Conversation

bjorn3
Copy link
Member

@bjorn3 bjorn3 commented Nov 4, 2023

It can be computed before creating TyCtxt. Previously the query would also write the dep info file, which meant that the output filenames couldn't be accessed before macro expansion is done. The dep info file writing is now done as a separate non-query function. The old query was always executed again anyways due to depending on the HIR.

Also encode the output_filenames in rlink files to ensure #![crate_name] affects the linking stage when doing separate compiling and linking using -Zno-link/-Zlink-only.

@rustbot
Copy link
Collaborator

rustbot commented Nov 4, 2023

r? @b-naber

(rustbot has picked a reviewer for you, use r? to override)

@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. labels Nov 4, 2023
// Make sure name resolution and macro expansion is run for
// the side-effect of providing a complete set of all
// accessed files and env vars.
let _ = tcx.resolver_for_lowering(());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use ensure().

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If resolver_for_lowering weren't eval_always and it is green, using ensure() would mean that the side effects of resolver_for_lowering (adding the list of used files and env vars to the Session) are not replayed as far as I understand it. Now resolver_for_lowering is eval_always currently, so it shouldn't matter for now I guess. There shouldn't be any perf difference though as resolver_for_lowering returns a reference.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we maybe add a comment in the query definition explaining this, i.e. why this needs to be eval_always?

@@ -580,7 +580,7 @@ pub enum ResolveDocLinks {
/// *Do not* switch `BTreeMap` out for an unsorted container type! That would break
/// dependency tracking for command-line arguments. Also only hash keys, since tracking
/// should only depend on the output types, not the paths they're written to.
#[derive(Clone, Debug, Hash, HashStable_Generic)]
#[derive(Clone, Debug, Hash, HashStable_Generic, Encodable, Decodable)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this cause us to leak host info into build artifacts?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rlink file already contains absolute file paths. rustc -Zlink-only foo.rlink is supposed to be called immediately after all dependencies of a rustc -Zlink-only invocation are finished. This has to be done on the same machine and can only be done once because all temporary files that are shared between the two rustc invocations have unpredictable names and are removed by rustc -Zlink-only.

@bors
Copy link
Contributor

bors commented Nov 17, 2023

☔ The latest upstream changes (presumably #118001) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Nov 17, 2023

☔ The latest upstream changes (presumably #117993) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Nov 18, 2023

☔ The latest upstream changes (presumably #118002) made this pull request unmergeable. Please resolve the merge conflicts.

@bjorn3 bjorn3 mentioned this pull request Nov 20, 2023
#[deprecated = "pre_configure may be made private in the future. If you need it please open an issue with your use case."]
pub fn pre_configure(&self) -> Result<QueryResult<'_, (ast::Crate, ast::AttrVec)>> {
self.pre_configure.compute(|| {
pub fn global_ctxt(&'tcx self) -> Result<QueryResult<'_, &'tcx GlobalCtxt<'tcx>>> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@nnethercote
Copy link
Contributor

The commit message of the third commit is truncated.

@bjorn3
Copy link
Member Author

bjorn3 commented Nov 21, 2023

I think the line that got removed originally started with #![crate_name = "..."], which git commit or git rebase then interpreted as a comment and removed.

@bors
Copy link
Contributor

bors commented Nov 22, 2023

☔ The latest upstream changes (presumably #118086) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Nov 26, 2023

☔ The latest upstream changes (presumably #117301) made this pull request unmergeable. Please resolve the merge conflicts.

This ensures that linking will use the correct crate name even when
`#![crate_name = "..."]` is used to specify the crate name.
Since the introduction of the crate attribute pre-expansion pass we
don't need access to the TyCtxt to compute it.
It has side-effects and as such can't be cached.
// Make sure name resolution and macro expansion is run for
// the side-effect of providing a complete set of all
// accessed files and env vars.
let _ = tcx.resolver_for_lowering(());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we maybe add a comment in the query definition explaining this, i.e. why this needs to be eval_always?

@b-naber
Copy link
Contributor

b-naber commented Nov 26, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Nov 26, 2023

📌 Commit d7e9a30 has been approved by b-naber

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 26, 2023
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 26, 2023
@bors
Copy link
Contributor

bors commented Nov 27, 2023

⌛ Testing commit d7e9a30 with merge ac9b308...

@bors
Copy link
Contributor

bors commented Nov 27, 2023

☀️ Test successful - checks-actions
Approved by: b-naber
Pushing ac9b308 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 27, 2023
@bors bors merged commit ac9b308 into rust-lang:master Nov 27, 2023
12 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Nov 27, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (ac9b308): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.2% [0.2%, 0.2%] 1
Regressions ❌
(secondary)
0.6% [0.6%, 0.6%] 1
Improvements ✅
(primary)
-0.2% [-0.2%, -0.2%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [-0.2%, 0.2%] 2

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
5.1% [1.8%, 8.8%] 3
Improvements ✅
(primary)
-1.6% [-1.6%, -1.6%] 1
Improvements ✅
(secondary)
-3.1% [-4.1%, -1.5%] 8
All ❌✅ (primary) -1.6% [-1.6%, -1.6%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 673.544s -> 675.005s (0.22%)
Artifact size: 313.34 MiB -> 313.35 MiB (0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler 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