Rollup of 10 pull requests #127533
Closed
Rollup of 10 pull requests #127533
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
This is adding a migration lint for the current (in the 2021 edition and previous) to move expr to expr_2021 from expr Co-Developed-by: Eric Holk Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Co-Developed-by: Eric Holk Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
…wiser allow overwriting the output of `rustc --version` Our wonderful bisection folk [have to work around](rust-lang#123276 (comment)) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for. This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by * choosing when to update rustc * choosing when to update dependencies * choosing which nightly features they are willing to take the breakage for The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency. This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too. This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_FORCE_RUSTC_VERSION` env var. The bisection issue is then fixed by rust-lang/cargo-bisect-rustc#335. I mainly want to establish a compiler team policy: > We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to. Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection. I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
…xpr2024, r=compiler-errors,eholk migration lint for `expr2024` for the edition 2024 This is adding a migration lint for the current (in the 2021 edition and previous) to move expr to expr_2021 from expr Issue rust-lang#123742 I created also a repository to test out the migration https://github.com/vincenzopalazzo/expr2024-cargo-fix-migration Co-Developed-by: `@eholk`
…dtolnay impl FusedIterator and a size hint for the error sources iter cc tracking issue rust-lang#58520
Automatically taint when reporting errors from ItemCtxt This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places. based on rust-lang#127357 r? ````@fmease````
…e-doc, r=fmease `#[doc(alias)]`'s doc: say that ASCII spaces are allowed PR rust-lang#77570 allowed ASCII spaces in doc aliases, but the documentation wasn't updated to say so. The code checking the aliases: https://github.com/rust-lang/rust/blob/7fdefb804ec300fb605039522a7c0dfc9e7dc366/compiler/rustc_passes/src/check_attr.rs#L693-L704 ````@rustbot```` label +A-docs
…eworking, r=lcnr More trait error reworking More work on rust-lang#127492, specifically those sub-bullets under "Move trait error reporting to `error_reporting::traits`". Stacked on top of rust-lang#127493. This does introduce new `TypeErrCtxt.*Ext` traits, but those will be deleted soon. Splitting this work into bite-sized pieces is the only way that it's gonna be feasible to both author and review ❤️ r? lcnr
…=Nadrieril Update `f16`/`f128` FIXMEs that needed `(NEG_)INFINITY` Just a small fix to the pattern matching tests now that we can. Also contains a small unrelated comment tweak.
…-errors small search graph refactor small improvements which shouldn't impact behavior. r? ````@compiler-errors````
…-pings, r=lqd Remove spastorino from SMIR r? `@oli-obk`
documentation: update cmake version Previously discussed here: rust-lang#127531
rustbot
added
A-meta
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=10 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 9, 2024
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#124339 (allow overwriting the output of `rustc --version`) - rust-lang#125627 (migration lint for `expr2024` for the edition 2024) - rust-lang#127091 (impl FusedIterator and a size hint for the error sources iter) - rust-lang#127358 (Automatically taint when reporting errors from ItemCtxt) - rust-lang#127484 (`#[doc(alias)]`'s doc: say that ASCII spaces are allowed) - rust-lang#127495 (More trait error reworking) - rust-lang#127496 (Update `f16`/`f128` FIXMEs that needed `(NEG_)INFINITY`) - rust-lang#127508 (small search graph refactor) - rust-lang#127521 (Remove spastorino from SMIR) - rust-lang#127532 (documentation: update cmake version) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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.
Successful merges:
rustc --version#124339 (allow overwriting the output ofrustc --version)expr2024for the edition 2024 #125627 (migration lint forexpr2024for the edition 2024)#[doc(alias)]'s doc: say that ASCII spaces are allowed #127484 (#[doc(alias)]'s doc: say that ASCII spaces are allowed)f16/f128FIXMEs that needed(NEG_)INFINITY#127496 (Updatef16/f128FIXMEs that needed(NEG_)INFINITY)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup