Rustc pull update #2291
Open
Rustc pull update #2291
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Move `hir::Item::ident` into `hir::ItemKind`.
`hir::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`, `Const`, `Fn`, `Macro`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`, Trait`, TraitAalis`.
- It's always empty for these item kinds: `ForeignMod`, `GlobalAsm`, `Impl`.
- For `Use`, it is non-empty for `UseKind::Single` and empty for `UseKind::{Glob,ListStem}`.
All of this is quite non-obvious; the only documentation is a single comment saying "The name might be a dummy name in case of anonymous items". Some sites that handle items check for an empty ident, some don't. This is a very C-like way of doing things, but this is Rust, we have sum types, we can do this properly and never forget to check for the exceptional case and never YOLO possibly empty identifiers (or possibly dummy spans) around and hope that things will work out.
This is step towards `kw::Empty` elimination (#137978).
r? `@fmease`
Clarify "owned data" in E0515.md This clarifies the explanation of why this is not allowed and also what to do instead. Fixes #62071 PS There was suggestion of adding a link to the book. I did not yet do that, but if desired that could be added.
Store test diffs in job summaries and improve analysis formatting This PR stores the test diffs that we already have in the post-merge workflow also into individual job summaries. This makes it easier to compare test (and later also other) diffs per job, which will be especially useful for try jobs, so that we can actually see the test diffs *before* we merge a given PR. As a drive-by, I also made a bunch of cleanups in `citool` and in the formatting of the summary and post-merge analyses. These changes are split into self-contained commits. The analysis can be tested locally with the following command: ```bash $ curl https://ci-artifacts.rust-lang.org/rustc-builds/<current-sha>/metrics-<job-name>.json > metrics.json $ cargo run --manifest-path src/ci/citool/Cargo.toml postprocess-metrics metrics.json --job-name <job-name> --parent <parent-sha> > out.md ``` For example, for [this PR](rust-lang/rust#138523): ```bash $ curl https://ci-artifacts.rust-lang.org/rustc-builds/282865097d138c7f0f7a7566db5b761312dd145c/metrics-aarch64-gnu.json > metrics.json $ cargo run --manifest-path src/ci/citool/Cargo.toml postprocess-metrics metrics.json --job-name aarch64-gnu --parent d9e5539a39192028a7b15ae596a8685017faecee > out.md ``` Best reviewed commit by commit. r? `@marcoieni` try-job: aarch64-gnu try-job: dist-x86_64-linux
Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly Some CI jobs (x64 Linux, ARM64 Linux and x64 MSVC) use the `opt-dist` tool to build an optimized toolchain using PGO and BOLT. When performing a default try build for x64 Linux, in most cases we want to run perf. on that artifact. To reduce the latency of this common use-case, `opt-dist` skips building several components not needed for perf., and it also skips running post-optimization tests, when it detects that the job is executed as a try job (not a merge/auto job). This is useful, but it also means that if you *want* to run the tests, you had to go to `jobs.yml` and manually comment this environment variable, create a WIP commit, do a try build, and then remove the WIP commit, which is annoying (in the similar way that modifying what gets run in try builds was annoying before we had the `try-job` annotations). I thought that we could introduce some additional PR description marker like `try-job-run-tests`, but it's hard to discover that such things exist. Instead, I think that there's a much simpler heuristic for determining whether `DIST_TRY_BUILD` should be used (that I implemented in this PR): - If you do just ``@bors` try`, without any custom try jobs selected, `DIST_TRY_BUILD` will be activated, to finish the build as fast as possible. - If you specify any custom try jobs, you are most likely doing experiments and you want to see if tests pass and everything builds as it should. The `DIST_TRY_BUILD` variable will thus *not* be set in this case. In this way, if you want to run dist tests, you can just add the `try-job: dist-x86_64-linux` line to the PR description, and you don't need to create any WIP commits. r? `@marcoieni`
…laumeGomez,Urgau Fix ICE: attempted to remap an already remapped filename This commit fixes an internal compiler error (ICE) that occurs when rustdoc attempts to process macros with a remapped filename. The issue arose during macro expansion when the `--remap-path-prefix` option was used. Instead of passing remapped filenames through, which would trigger the "attempted to remap an already remapped filename" panic, we now extract the original local path from remapped filenames before processing them. A test case has been added to verify this behavior. Fixes #138520
rustc_target: Add target feature constraints for LoongArch Part of rust-lang/rust#116344 r? `@RalfJung`
Flatten `if`s in `rustc_codegen_ssa` Best viewed [while ignoring whitespace](https://github.com/rust-lang/rust/pull/138619/files?diff=unified&w=1)
Rollup of 7 pull requests Successful merges: - #138384 (Move `hir::Item::ident` into `hir::ItemKind`.) - #138508 (Clarify "owned data" in E0515.md) - #138531 (Store test diffs in job summaries and improve analysis formatting) - #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly) - #138556 (Fix ICE: attempted to remap an already remapped filename) - #138608 (rustc_target: Add target feature constraints for LoongArch) - #138619 (Flatten `if`s in `rustc_codegen_ssa`) r? `@ghost` `@rustbot` modify labels: rollup
uefi: fs: Implement exists Also adds the initial file abstractions. The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol. After that, it queries all handles supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat. It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently. DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators. This is an effort to break the original PR (rust-lang/rust#129700) into much smaller chunks for faster upstreaming.
Temporarily disable Fuchsia test job to unblock queue See <https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/fuchsia.20failure/with/506637259> for efforts to fix the test job. This PR temporarily disables the Fuchsia test job to unblock the queue, so that neither the Fuchsia maintainers nor T-infra maintainers should feel pressured to fix the job ASAP. Please feel free to re-enable once the test job is fixed. FYI `@erickt` since you or other Fuchsia maintainers will need to revert this change to merge Fuchsia test job fixes in the future. r? infra-ci
clarify BufRead::{fill_buf, consume} docs
Fixes #85394
Remove the regex dependency from coretests It is only used by a single test, yet would take up unnecessary space once stdlib deps get vendored.
rustc-dev-guide sync r? `@jieyouxu`
Remove double nesting in post-merge workflow See [this](rust-lang/rust#138630 (comment)) :) Can be tested with: ```bash #!/bin/bash PARENT_COMMIT=493c38ba371929579fe136df26eccd9516347c7a SHA=259fdb521200c9abba547302fc2c826479ef26b2 printf "<details>\n<summary>What is this?</summary>\n" >> output.log printf "This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.\n" >> output.log printf "</details>\n\n" >> output.log cargo run --release post-merge-report ${PARENT_COMMIT} ${SHA} >> output.log ``` I think that it's better to leave the notice in CI, to avoid generating it in citool, which can also be executed locally. r? `@marcoieni`
CI: mirror alpine and centos images to ghcr
coverage: Don't store a body span in `FunctionCoverageInfo` We aren't using this body span for anything truly essential, and having it around will be awkward when we eventually start to support expansion regions, since they aren't necessarily within the main body.
…chenkov Revert: Add *_value methods to proc_macro lib This reverts rust-lang/rust#136355. That PR caused unexpected breakage: - the rustc-dev component can no longer be loaded by cargo, which impacts Miri and clippy and likely others - rustc_lexer can no longer be published to crates.io, which impacts RA See rust-lang/rust#138647 for context. Cc `@GuillaumeGomez` `@Amanieu`
Remove existing AFIDT implementation This experiment will need to be reworked differently; I don't think we'll be going with the `dyn* Future` approach that is currently implemented. r? oli-obk Fixes #136286 Fixes #137706 Fixes #137895 Tracking: * #133119
Various codegen_llvm cleanups Mostly just adding safe wrappers and deduplicating code
use then in docs for `fuse` to enhance readability
use the more-idiomatic `then_some` rather than an `if { some } else { none }` for `fused` docs
Rollup of 10 pull requests
Successful merges:
- #136177 (clarify BufRead::{fill_buf, consume} docs)
- #138654 (Remove the regex dependency from coretests)
- #138655 (rustc-dev-guide sync)
- #138656 (Remove double nesting in post-merge workflow)
- #138658 (CI: mirror alpine and centos images to ghcr)
- #138659 (coverage: Don't store a body span in `FunctionCoverageInfo`)
- #138661 (Revert: Add *_value methods to proc_macro lib)
- #138670 (Remove existing AFIDT implementation)
- #138674 (Various codegen_llvm cleanups)
- #138684 (use then in docs for `fuse` to enhance readability)
r? `@ghost`
`@rustbot` modify labels: rollup
Represent diagnostic side effects as dep nodes This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index. Some implications of this: - Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that. - Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks. - Reusing a CGU will now emit diagnostics from the task generating it.
github-actions
bot
force-pushed
the
rustc-pull
branch
from
9d4b933 to
a3e1c32
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.