[draft] Forward port "Soft disable incremental" to 1.53 #86301
Closed
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
…lang#82465. (update: placated tidy)
This reverts commit eb18746.
This reverts commit 0a8e401.
That PR caused multiple test failures when Rust's channel is changed from nightly to anything else. The commit will have to be landed again after the test suite is fixed.
…crum [beta] Prepare beta 1.53.0 Along with updating the channel and updating the bootstrap compiler, this also includes: * 692454d - Fixes the diagnostics difference we had for some cycles already * 9157430 - Disables the known broken RLS builder on AArch64 Windows * rust-lang#84183 - Update RELEASES.md for 1.52.0 * rust-lang#84950 - Revert PR 83866 * rust-lang#84886 - Update RLS and Rustfmt Changes we backported to 1.52.0 that we also need to include in 1.53.0 to avoid regressing: * rust-lang#84867 - rustdoc: revert deref recur to resume inclusion of impl ExtTrait<Local> for ExtType * rust-lang#84759 - [beta] remove assert_matches * rust-lang#83171 - Revert PR 81473 to resolve (on beta) issues 81626 and 81658. r? `@ghost`
Fix rust-lang#84769, follow up to rust-lang#84499, rust-lang#83667.
…ulacrum [beta] backports First-ish round of beta backports: * [beta] backport for rust-lang#84769 rust-lang#84969 * [beta] Bump stage0 to production 1.52.0 rust-lang#84994 * Deduplicate ParamCandidates with the same value except for bound vars rust-lang#84559
Backport of rust-lang#7170 to beta r? `@ghost` changelog: none (fixes stack overflow, but this was introduced in this release cycle) Now actually opened towards the `beta` branch.
The unsoundness is not in Peekable per se, it rather is due to the interaction between Peekable being able to hold an extra item and vec::IntoIter's clone implementation shortening the allocation. An alternative solution would be to change IntoIter's clone implementation to keep enough spare capacity available.
This also checks the contents and not only the capacity in case IntoIter's clone implementation is changed to add capacity at the end. Extra capacity at the beginning would be needed to make InPlaceIterable work. Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
When encountering a path that can't have generics, do not call `generics_of`. This would happen when writing something like `path::this_is_a_mod<const_val>`. Fix rust-lang#84831.
using allow_internal_unstable (as recommended) Fixes: rust-lang#84836 ```shell $ ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc src/test/run-make-fulldeps/coverage/no_cov_crate.rs error[E0554]: `#![feature]` may not be used on the dev release channel --> src/test/run-make-fulldeps/coverage/no_cov_crate.rs:2:1 | 2 | #![feature(no_coverage)] | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0554`. ```
…ntrinsics). This is to address issue 84297.
…pping`. Test was added in PR rust-lang#84404. The intent here is: The `copy`/`copy_overlapping` intrinsics are going through some flip-flopping now of "are they intrinsics or not". We can achieve the same effect that the test intended by using `likely`/`unlikely`.
…r=dtolnay Beta targetted Make copy/copy_nonoverlapping fn's again beta backport of PR rust-lang#86003 to address issue rust-lang#84297
This addresses a codegen-issue that needs to be fixed upstream in LLVM. While we wait for the fix, we can disable it. Verified manually that the outliner is no longer run when `-Copt-level=z` is specified, and also that you can override this with `-Cllvm-args=-enable-machine-outliner` if you need it anyway. A regression test is not really feasible in this instance, given that we do not have any minimal reproducers. Fixes rust-lang#85351
Fixes rust-lang#85432 When processing a `#[derive]` or `#[cfg_eval]` attribute, we need to re-parse our attribute target, which requires flattenting all `Nonterminals`. However, this caused us to incorrectly gate on a (flattented) nonterminal in a key-value attribute, which is supposed to be allowed. Since we already perform this gating during the initial parse, we suppress it in `capture_cfg` mode.
Fixes rust-lang#85197 We already preserved the `SyntaxContext` for invalid/dummy spans in the incremental cache, but we weren't doing the same for crate metadata. If an invalid (lo/hi from different files) span is written to the incremental cache, we will decode it with a 'dummy' location, but keep the original `SyntaxContext`. Since the crate metadata encoder was only checking for `DUMMY_SP` (dummy location + root `SyntaxContext`), the metadata encoder would treat it as a normal span, encoding the `SyntaxContext`. As a result, the final span encoded to the metadata would change across sessions, even if the crate itself was unchanged. This PR updates our encoding of spans in the crate metadata to mirror the encoding of spans into the incremental cache. We now always encode a `SyntaxContext`, and encode location information for spans with a non-dummy location.
Removes the implementations that depend on the user-definable trait `Copy`. Beta backport: Does not modify `vec::IntoIter`.
…ulacrum [beta] backports * Disable the machine outliner by default rust-lang#86020 * Fix incorrect gating of nonterminals in key-value attributes rust-lang#85445 * Build crtbegin.o/crtend.o from source code rust-lang#85395 * Bring back x86_64-sun-solaris target to rustup rust-lang#85252 * Preserve SyntaxContext for invalid/dummy spans in crate metadata rust-lang#85211 * [beta] backport: Remove unsound TrustedRandomAccess implementations rust-lang#86222 r? `@Mark-Simulacrum`
…lacrum Integrate attributes as part of the crate hash Backport of rust-lang#83901 r? `@Mark-Simulacrum`
This disables incremental (i.e., -Cincremental) taking effect unless an environment variable, RUSTC_FORCE_INCREMENTAL, is set to 1 in the environment of the running rustc. Currently incremental causes errors for many users, and we do not have an expectation of being able to quickly fix these errors in a backportable way - so, for now, disable incremental entirely. The user can still opt-in, but this way the majority of users merely get slower builds, not broken builds.
|
(rust-highfive has picked a reviewer for you, use r? to override) |
|
rust-highfive
added
the
S-waiting-on-review
pnkfelix
changed the title
|
(I'm just putting this up so @Mark-Simulacrum has a trivial thing to grab as part of the beta-to-stable promotional rollup they land.) |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
Going to go ahead and close this as I'm manually packaging up the commits. |
|
☔ The latest upstream changes (presumably #86226) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
This disables incremental (i.e., -Cincremental) taking effect unless an environment variable, RUSTC_FORCE_INCREMENTAL, is set to 1 in the environment of the running rustc. Currently incremental causes errors for many users, and we do not have an expectation of being able to quickly fix these errors in a backportable way - so, for now, disable incremental entirely. The user can still opt-in, but this way the majority of users merely get slower builds, not broken builds.
(Cherry-pick of 4e62503 )