Rollup of 6 pull requests #117071

matthiaskrgr · 2023-10-23T06:12:42Z

Successful merges:

rustdoc: align stability badge to baseline instead of bottom #105666 (rustdoc: align stability badge to baseline instead of bottom)
coverage: Emit the filenames section before encoding per-function mappings #117042 (coverage: Emit the filenames section before encoding per-function mappings)
Miri subtree update #117044 (Miri subtree update)
add a csky-unknown-linux-gnuabiv2hf target #117049 (add a csky-unknown-linux-gnuabiv2hf target )
fix broken link: update incremental compilation url #117051 (fix broken link: update incremental compilation url)
x.ps1: remove the check for Python from Windows Store #117069 (x.ps1: remove the check for Python from Windows Store)

r? @ghost
@rustbot modify labels: rollup

r? @joshtripplet

Automatic Rustup

avoid AtomicU64 when a Cell is enough

…hases This gives us a clearly-defined place to run code after the instance's MIR has been traversed by codegen, but before we emit its `__llvm_covfun` record.

The combined `get_expressions_and_counter_regions` method was an artifact of having to prepare the expressions and mappings at the same time, to avoid ownership/lifetime problems with temporary data used by both. Now that we have an explicit transition from `FunctionCoverageCollector` to the final `FunctionCoverage`, we can prepare any shared data during that step and store it in the final struct.

The main change here is that `VirtualFileMapping` now uses an internal hashmap to de-duplicate incoming global file IDs. That removes the need for `encode_mappings_for_function` to re-sort its mappings by filename in order to de-duplicate them. (We still de-duplicate runs of identical filenames to save work, but this is not load-bearing for correctness, so a sort is not necessary.)

…pings Most coverage metadata is encoded into two sections in the final executable. The `__llvm_covmap` section mostly just contains a list of filenames, while the `__llvm_covfun` section contains encoded coverage maps for each instrumented function. The catch is that each per-function record also needs to contain a hash of the filenames list that it refers to. Historically this was handled by assembling most of the per-function data into a temporary list, then assembling the filenames buffer, then using the filenames hash to emit the per-function data, and then finally emitting the filenames table itself. However, now that we build the filenames table up-front (via a separate traversal of the per-function data), we can hash and emit that part first, and then emit each of the per-function records immediately after building. This removes the awkwardness of having to temporarily store nearly-complete per-function records.

When installing Python from the Windows Store, a copy of `python.exe` is installed inder the Microsoft directory in the user's local AppData directory. Currently, `x.ps1` checks for this file, because by default running `python.exe` opens a link to the Microsoft Store rather than running Python. Once the user installs Python, however, this contains a valid interpreter. Unfortuantely, `x.ps1` can't tell the difference between a legitimate Python install and the stub. Remove the check, as it makes it impossible to use the official version from Microsoft once it has been installed. Signed-off-by: Sean Cross <[email protected]>

… r=GuillaumeGomez rustdoc: align stability badge to baseline instead of bottom | desc | img | |------|-----| | before | ![image](https://user-images.githubusercontent.com/1593513/207412598-3a6468ca-a169-4810-a689-4797688385df.png) | | | | | after | ![image](https://user-images.githubusercontent.com/1593513/207412720-b120269a-48a3-40e9-a9b0-6769bb05e104.png) | Preview: http://notriddle.com/notriddle-rustdoc-demos/stab-baseline/test_dingus/index.html Based on comment from rust-lang#105509 (comment) r? ``@joshtriplett``

coverage: Emit the filenames section before encoding per-function mappings When embedding coverage information in LLVM IR (and ultimately in the resulting binary), there are two main things that each CGU needs to emit: - A single `__llvm_covmap` record containing a coverage header, which mostly consists of a list of filenames used by the CGU's coverage mappings. - Several `__llvm_covfun` records, one for each instrumented function, each of which contains the hash of the list of filenames in the header. There is a kind of loose cyclic dependency between the two: we need the hash of the file table before we can emit the covfun records, but we need to traverse all of the instrumented functions in order to build the file table. The existing code works by processing the individual functions first. It lazily adds filenames to the file table, and stores the mostly-complete function records in a temporary list. After this it hashes the file table, emits the header (containing the file table), and then uses the hash to emit all of the function records. This PR reverses that order: first we traverse all of the functions (without trying to prepare their function records) to build a *complete* file table, and then emit it immediately. At this point we have the file table hash, so we can then proceed to build and emit all of the function records, without needing to store them in an intermediate list. --- Along the way, this PR makes some necessary changes that are also worthwhile in their own right: - We split `FunctionCoverage` into distinct collector/finished phases, which neatly avoids some borrow-checker hassles when extracting a function's final expression/mapping data. - We avoid having to re-sort a function's mappings when preparing the list of filenames that it uses.

Miri subtree update This should unblock rust-lang#116581

…2, r=bjorn3 add a `csky-unknown-linux-gnuabiv2hf` target This is the rustc side changes to support csky based Linux target(`csky-unknown-linux-gnuabiv2`). Tier 3 policy: > A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) I pledge to do my best maintaining it. > Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target. This `csky` section is the arch name and the `unknown-linux` section is the same as other linux target, and `gnuabiv2` is from the cross-compile toolchain of `gcc`. the `hf`means hardfloat. > Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it. I think the explanation in platform support doc is enough to make this aspect clear. > Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. It's using open source tools only. > The target must not introduce license incompatibilities. No new license > Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0). Understood. > The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements. There are no new dependencies/features required. > Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3. As previously said it's using open source tools only. > "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. There are no such terms present/ > Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions. I'm not the reviewer here. > This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements. I'm not the reviewer here. > Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. It supports for std > The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary. I have added the documentation, and I think it's clear. > Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via ``@)`` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages. Understood. > Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications. Understood. > Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. I believe I didn't break any other target. > In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. I think there are no such problems in this PR.

…ation-link, r=Nilstrieb fix broken link: update incremental compilation url

…eck, r=albertlarsan68 x.ps1: remove the check for Python from Windows Store When installing Python from the Windows Store, a copy of `python.exe` is installed inder the Microsoft directory in the user's local AppData directory. Currently, `x.ps1` checks for this file, because by default running `python.exe` opens a link to the Microsoft Store rather than running Python. Once the user installs Python, however, this contains a valid interpreter. Unfortuantely, `x.ps1` can't tell the difference between a legitimate Python install and the stub. Remove the check, as it makes it impossible to use the official version from Microsoft once it has been installed. This resolves rust-lang#117067

matthiaskrgr · 2023-10-23T06:12:56Z

@bors r+ rollup=never p=6

bors · 2023-10-23T06:12:58Z

📌 Commit cec7d4a has been approved by matthiaskrgr

It is now in the queue for this repository.

bors · 2023-10-23T07:32:58Z

⌛ Testing commit cec7d4a with merge 6bb4ad6...

bors · 2023-10-23T09:27:59Z

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 6bb4ad6 to master...

rust-timer · 2023-10-23T09:29:43Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#105666	rustdoc: align stability badge to baseline instead of bottom	`e67f2765dfd9f65aa23ab5341afb3241c3ae7a58` (link)
#117042	coverage: Emit the filenames section before encoding per-fu…	`1cd54185d21c07f2a80fbb513f464793a54f8867` (link)
#117044	Miri subtree update	`9d7339fff8e9f619c3b894447f6f14e81e7a7948` (link)
#117049	add a `csky-unknown-linux-gnuabiv2hf` target	`2e9c24165e31110b9e7a7eebc98f2fd9d6a0fc85` (link)
#117051	fix broken link: update incremental compilation url	`fe3b8b34c5df0ec9642edfcecae3db6821a9d2fd` (link)
#117069	x.ps1: remove the check for Python from Windows Store	`814c74483222678eb5268ef2febfaf81a1f70bab` (link)

previous master: aec4741d42

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

rust-timer · 2023-10-23T13:25:20Z

Finished benchmarking commit (6bb4ad6): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

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)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	-	-	0

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: missing data
Artifact size: 304.28 MiB -> 304.33 MiB (0.02%)

notriddle and others added 23 commits July 31, 2023 15:07

rustdoc: align stability badge to baseline instead of bottom

c564f81

r? @joshtripplet

Preparing for merge from rustc

193fec6

Merge from rustc

1f09dd2

clippy

8cbac82

Auto merge of rust-lang#3133 - rust-lang:rustup-2023-10-22, r=RalfJung

f6be93f

Automatic Rustup

avoid AtomicU64 when a Cell is enough

b53c34f

Auto merge of rust-lang#3135 - RalfJung:nonatomic-clock, r=RalfJung

f35c36a

avoid AtomicU64 when a Cell is enough

coverage: Split FunctionCoverage into distinct collector/finished p…

371883a

…hases This gives us a clearly-defined place to run code after the instance's MIR has been traversed by codegen, but before we emit its `__llvm_covfun` record.

coverage: Build the global file table ahead of time

e985ae5

coverage: Encapsulate local-to-global file mappings

88159ca

add target csky-unknown-linux-gnuabiv2hf

dc00d03

tidy docs

5454797

fix broken link: update incremental compilation url

bb67e0f

Rollup merge of rust-lang#117044 - RalfJung:miri, r=RalfJung

fe4fde2

Miri subtree update This should unblock rust-lang#116581

Rollup merge of rust-lang#117051 - gvozdvmozgu:fix-incremental-compil…

2636745

…ation-link, r=Nilstrieb fix broken link: update incremental compilation url

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 Oct 23, 2023

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 23, 2023

bors merged commit 6bb4ad6 into rust-lang:master Oct 23, 2023
11 checks passed

rustbot added this to the 1.75.0 milestone Oct 23, 2023

bors mentioned this pull request Oct 23, 2023

Update x.ps1 #116590

Closed

github-actions bot mentioned this pull request Oct 31, 2023

Automated pull from upstream master ferrocene/ferrocene#74

Merged

matthiaskrgr deleted the rollup-1tcxdgj branch March 16, 2024 18:18

matthiaskrgr mentioned this pull request Apr 16, 2024

ICE: node HirId ... cannot be placed in TypeckResults with hir_owner DefId... #124022

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rollup of 6 pull requests #117071

Rollup of 6 pull requests #117071

matthiaskrgr commented Oct 23, 2023

matthiaskrgr commented Oct 23, 2023

bors commented Oct 23, 2023

bors commented Oct 23, 2023

bors commented Oct 23, 2023

rust-timer commented Oct 23, 2023

rust-timer commented Oct 23, 2023

Rollup of 6 pull requests #117071

Rollup of 6 pull requests #117071

Conversation

matthiaskrgr commented Oct 23, 2023

matthiaskrgr commented Oct 23, 2023

bors commented Oct 23, 2023

bors commented Oct 23, 2023

bors commented Oct 23, 2023

rust-timer commented Oct 23, 2023

rust-timer commented Oct 23, 2023

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size