-
Notifications
You must be signed in to change notification settings - Fork 557
Rustc pull update #2617
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
Merged
Merged
Rustc pull update #2617
Conversation
This file contains hidden or 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
The `needs-asm-support` directive checks whether the host architecture supports inline assembly, not the target architecture. For tests that explicitly specify a target via `--target` in their compile-flags, this directive is incorrect and unnecessary. These tests are cross-compiling to specific targets (like x86_64, arm, aarch64, riscv, etc.) that are already known to have stable asm support. The directive was causing these tests to be incorrectly skipped on hosts that don't support asm, even though the target does. Tests with explicit targets should rely on `needs-llvm-components` to ensure the appropriate backend is available, rather than checking host asm support. Improve documentation about `needs-asm-support` directive.
handle spurious returns of `wait_timeout` in test Fixes rust-lang/rust#147885 Closes rust-lang/rust#147871 `wait_timeout` is allowed to spuriously return, hence the `timeout_nanoseconds` must not assume that the wakeup resulted from a `notify_all()`.
Stop invalidating CFG caches in CleanupPostBorrowck. r? `@ghost`
move `once` module out of `poison` From rust-lang/rust#134645 (comment), since `Once` will not have a non-poisoning variant, we remove it from the `poison` module. Additionally: 1. Renames `once::ExclusiveState` to `OnceExclusiveState` since it was a bit confusing reading just `ExclusiveState` where it is used. 2. Reorders a few module definitions and re-exports in `library/std/src/sync/mod.rs` for clarity. Also, once this is merged, I think that we can begin the process of stabilizing [`sync_poison_mod`](rust-lang/rust#134646)
Add `Cacheable` trait alias in `rustc_public_bridge` r? `@celinval`
…es, r=notriddle,GuillaumeGomez rustdoc search: relax rules for identifiers fixes rust-lang/rust#147763
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to 7cb1f42. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
Rollup of 5 pull requests Successful merges: - rust-lang/rust#147125 (move `once` module out of `poison`) - rust-lang/rust#147800 (Add `Cacheable` trait alias in `rustc_public_bridge`) - rust-lang/rust#147860 (rustdoc search: relax rules for identifiers) - rust-lang/rust#147916 (Update books) - rust-lang/rust#147924 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup
Add a test for the cold attribute This adds a test for the cold attribute to verify that it actually does something, and that it applies correctly in all the positions it is expected to work.
Remove broken link Idk if this link is any important but it does not work anymore so...
Make `UnevaluatedConst` have a specific ID type in the new solver For the benefit of rust-analyzer. r? types
`-Znext-solver` instantiate predicate binder without recanonicalizing goal
This strengthens the leak check to match the old trait solver. The new trait solver now also instantiates higher ranked goals in the same scope as candidate selection, so the leak check in each candidate detects placeholder errors involving this higher ranked goal.
E.g. let's look at tests/ui/higher-ranked/leak-check/leak-check-in-selection-2.rs
```rust
trait Trait<T, U> {}
impl<'a> Trait<&'a str, &'a str> for () {}
impl<'a> Trait<&'a str, String> for () {}
fn impls_trait<T: for<'a> Trait<&'a str, U>, U>() {}
fn main() {
impls_trait::<(), _>();
}
```
Here proving `(): for<'a> Trait<&'a str, ?u>` via `impl<'a> Trait<&'a str, &'a str> for ()` equates `?u` with `&'!a str` which results in a leak check error as `?u` cannot name `'a`. If this leak check error happens while considering candidates we drop the first impl and infer `?u` to `String`. If not, this remains ambiguous.
This behavior is a bit iffy, see the FCP proposal in rust-lang/rust#119820 for more details on why this current behavior is somewhat undesirable. However, considering placeholders from higher-ranked goals for candidate selection does allow more code to compile and a lot of the code *feels like it should compile*. **This caused us to revert the change of rust-lang/rust#119820 in rust-lang/rust#127568.**
I originally expected that we can avoid breakage with the new solver differently here, e.g. by considering OR-region constraints. However, doing so is a significant change and I don't have a great idea for how that should work. Matching the old solver behavior for now should not make this cleaner approach any more difficult in the future, so let's just go with what actually allows us to stabilize the new solver for now.
This PR changing the new solver to match the behavior of the old one wrt the leak check. As the new solver is already used by default in coherence, this allows more code to compile, see `tests/ui/higher-ranked/leak-check/leak-check-in-selection-7-coherence.rs`:
```rust
struct W<T, U>(T, U);
trait Trait<T> {}
// using this impl results in a higher-ranked region error.
impl<'a> Trait<W<&'a str, &'a str>> for () {}
impl<'a> Trait<W<&'a str, String>> for () {}
trait NotString {}
impl NotString for &str {}
impl NotString for u32 {}
trait Overlap<U> {}
impl<T: for<'a> Trait<W<&'a str, U>>, U> Overlap<U> for T {}
impl<U: NotString> Overlap<U> for () {}
fn main() {}
```
This behavior is quite arbitrary and not something I expect users to rely on in practice, however, it should still go through an FCP imo.
r? `@BoxyUwU` originally implemented by `@compiler-errors` in rust-lang/rust#136997. Closes rust-lang/trait-system-refactor-initiative#120.
Remove current code for embedding command-line args in PDB The compiler currently has code that will obtain a list of quoted command-line arguments, and pass it through to TargetMachine creation, so that the command-line args can be embedded in PDB output. This PR removes that code, due to subtle concerns that might not have been apparent when it was originally added. --- Those concerns include: - The entire command-line quoting process is repeated every time a target-machine-factory is created. In incremental builds this typically occurs 500+ times, instead of happening only once. The repeated quoting constitutes a large chunk of instructions executed in the `large-workspace` benchmark. - See rust-lang/rust#146804 (comment) for an example of the perf consequences of skipping all that work. - This overhead occurs even when building for targets or configurations that don't emit PDB output. - Command-line arguments are obtained in a way that completely bypasses the query system, which is a problem for the integrity of incremental compilation. - Fixing this alone is likely to inhibit incremental rebuilds for most or all CGUs, even in builds that don't emit PDB output. - Command-line arguments and the executable path are obtained in a way that completely bypasses the compiler's path-remapping system, which is a reproducibility hazard. - rust-lang/rust#128842 --- Relevant PRs: - rust-lang/rust#113492 - rust-lang/rust#130446 - rust-lang/rust#131805 - rust-lang/rust#146700 - rust-lang/rust#146973 Zulip thread: - https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Some.20PDB.20info.20bypasses.20the.20query.20system.20and.20path.20remapping/with/541432211 --- According to rust-lang/rust#96475, one of the big motivations for embedding the command-line arguments was to enable tools like Live++. [It appears that Live++ doesn't actually support Rust yet](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/embeded.20compiler.20args.20and.20--remap-path-prefix/near/523800010), so it's possible that there aren't any existing workflows for this removal to break. In the future, there could be a case for reintroducing some or all of this functionality, guarded behind an opt-in flag so that it doesn't cause problems for other users. But as it stands, the current implementation puts a disproportionate burden on other users and on compiler maintainers.
Forbid ShallowInitBox after box deref elaboration. MIR currently contains a `ShallowInitBox` rvalue. Its principal usage is to allow for in-place initialization of boxes. Having it is necessary for drop elaboration to be correct with that in-place initialization. As part of analysis->runtime MIR lowering, we canonicalize deref of boxes to use the stored raw pointer. But we did not perform the same change to the construction of the box. This PR replaces `ShallowInitBox` by the pointer manipulation it represents. Alternatives: - fully remove `ShallowInitBox` and implement `Box` in-place initialization differently; - remove the `ElaborateBoxDeref` pass and keep dereferencing `Box` in runtime MIR.
Update typos I saw that `typos` was a few versions out of date and figured it would be a good idea to update it. Upgrading to `1.38.1` adds the [July](crate-ci/typos#1331), [August](crate-ci/typos#1345), and [September](crate-ci/typos#1370) dictionary updates. As part of this change, I also sorted the configuration file.
refactor: Move to anstream + anstyle for styling `rustc` uses [`termcolor`](https://crates.io/crates/termcolor) for styling and writing, while `annotate-snippets` uses [`anstyle`](https://crates.io/crates/anstyle) for styling and currently writes directly to a `String`. When rendering directly to a terminal, there isn't/shouldn't be any differences. Still, there are differences in the escape sequences, which leads to slightly different output in JSON and SVG tests. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I switched `rustc` to use `anstlye` and [`anstream`](https://crates.io/crates/anstream) for styling and writing. The first commit migrates to `anstyle` and `anstream` and notably does not change the output. This is because it includes extra formatting to ensure that `anstyle` + `anstream` match the current output exactly. Most of this code is unnecessary, as it adds redundant resets or uses 256-color (8-bit) when it could be using 4-bit color. The subsequent commits remove this extra formatting while maintaining the correct output when rendered. [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
Split LTO out of the main codegen coordinator event loop into a separate event loop on the same thread This will make it easier to in the future move all this code to link_binary. Follow up to rust-lang/rust#146209 Part of rust-lang/compiler-team#908
… r=cuviper Remove needs-asm-support directive in tests with explicit targets The `needs-asm-support` directive checks whether the host architecture supports inline assembly, not the target architecture. For tests that explicitly specify a target via `--target` in their compile-flags, this directive is incorrect and unnecessary. These tests are cross-compiling to specific targets (like x86_64, arm, aarch64, riscv, etc.) that are already known to have stable asm support. The directive was causing these tests to be incorrectly skipped on hosts that don't support asm, even though the target does. Tests with explicit targets should rely on `needs-llvm-components` to ensure the appropriate backend is available, rather than checking host asm support.
refactor(rustdoc): Remove redundant langstr checks These same checks feed into `doctest.can_be_merged`, making them redundant.
compiletest: Add concrete examples for some config/test path fields Seeing a specific example path can be much more enlightening than trying to figure out what the prose is gesturing towards. Also, in some cases the existing comments were incorrect or misleading, as demonstrated by the example paths. The example paths were determined by dumping them directly out of the config with `dbg!`, and then lightly anonymizing them for example purposes. --- No functional changes. r? jieyouxu
Fix compiling `CondVar::wait_timeout` on 32-bit Apple platforms Fixes rust-lang/rust#147776. I feel like there's a cleaner way to write this, but that probably requires further refactoring. The build can be tested with `./x build --target arm64_32-apple-watchos` (or with any other 32-bit Apple target). Tested it works at runtime on an Intel Macbook Pro with macOS 10.12.6, in x86 emulation mode with something similar to `./x test library/std --target x86_64-apple-darwin,i686-apple-darwin`, as well as with a custom test with a timeout of `Duration::from_secs((u32::MAX as u64) + 1)` (which the naive fix would have treated as a duration of 1 second). r? libs CC ``@joboet``
test(frontmatter): Rename tests to make coverage more obvious When working on the stabilization report (rust-lang/rust#148051), I found it annoying to determine what cases were covered because areas of the frontmatter feature were either not in the file name or in inconsistent locations. This moves the area of frontmatter to the start of the file name and the moves to more specific the later in the file name so coverage is easier to see. Tracking issue: rust-lang/rust#136889
Rollup of 5 pull requests Successful merges: - rust-lang/rust#147406 (Remove needs-asm-support directive in tests with explicit targets) - rust-lang/rust#148056 (refactor(rustdoc): Remove redundant langstr checks) - rust-lang/rust#148065 (compiletest: Add concrete examples for some config/test path fields) - rust-lang/rust#148072 (Fix compiling `CondVar::wait_timeout` on 32-bit Apple platforms) - rust-lang/rust#148073 (test(frontmatter): Rename tests to make coverage more obvious) r? `@ghost` `@rustbot` modify labels: rollup
StateTransform: Only load pin field once. The current implementation starts by transforming all instances of `_1` into `(*_1)`, and then traverses the body again to transform `(*_1)` into `(*(_1.0))`, and again for `Derefer`. This PR changes the implementation to only traverse the body once. As `_1.0` cannot be not modified inside the body (we just changed its type!), we have no risk of loading from the wrong pointer.
Rollup of 4 pull requests Successful merges: - rust-lang/rust#143361 (Stop passing resolver disambiguator state to AST lowering.) - rust-lang/rust#148000 (Improvements to attribute suggestions) - rust-lang/rust#148007 (chore: Update to the latest annotate-snippets) - rust-lang/rust#148088 (compiletest: Simplify passing arguments to spawned test threads) r? `@ghost` `@rustbot` modify labels: rollup
remove a performance hack This hack seems no longer used 🤔 nalgebra compiles without it. Let's run perf to see whether it matters. r? `@BoxyUwU`
…, r=tgross35 Unify and deduplicate max recip float tests cc rust-lang/rust#141726 This is a proposal to unify and deduplicate max recip tests for f16 and f128
Don't require `T: RefUnwindSafe` for `vec::IntoIter<T>: UnwindSafe` Closes rust-lang/rust#144707 r? t-libs-api
…oundwork, r=jieyouxu compiletest: pass rustdoc mode as param, rather than implicitly Spun out of rust-lang/rust#142642 In the future, I want the rustdoc-json test suite to invoke rustdoc twice, once with `--output-format=json`, and once with the (not yet implemented) `--output-format=postcard` flag. Doing that requires being able to explicitly tell the `.document()` function which format to use, rather then implicitly using json in the rustdoc-json suite, and HTML in all others. r? `@jieyouxu` CC `@jalil-salame`
…,lolbinarycat Improve source code for `highlight.rs` I was very bothered by the complexity of this file, in particular the handling of `pending_elems` which was very tricky to follow. So instead, here comes a more sane approach: the content is store in a stack-like type which handles "levels" of HTML (ie, a macro expansion can contain other HTML tags which can themselves contain other, etc). Making it much simpler to keep track of what's going on. r? `@lolbinarycat`
resolve: When suppressing `out_of_scope_macro_calls` suppress `unused_imports` as well Fixes the example from this comment - rust-lang/rust#147823 (comment). Fixes rust-lang/rust#148143.
This updates the rust-version file to b1b464d6f61ec8c4e609c1328106378c066a9729.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: b1b464d6f61ec8c4e609c1328106378c066a9729 Filtered ref: f94cd4e Upstream diff: rust-lang/rust@4068baf...b1b464d This merge was created using https://github.com/rust-lang/josh-sync.
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
|
rather tiny, but it is an update, so... |
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.