initial josh subtree sync #2583
Merged
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
add regression test for miri issue 2433 Adding this here because the test needs to be run with debug assertions enabled to be sure so I had to run it in the rustc workspace. Cc rust-lang#2433 r? ``@oli-obk``
rustdoc: clean up CSS/DOM for deprecation warnings Preview: https://notriddle.com/notriddle-rustdoc-test/stab-p/std/macro.try.html
Fix a typo in `std`'s root docs Remarkably, this typo has been present for *seven years.* I was so surprised that I reread the text five times and then asked people on the rust Zulip to double-check. :)
Rollup of 7 pull requests Successful merges: - #102094 (Add missing documentation for `bool::from_str`) - #102115 (Add examples to `bool::then` and `bool::then_some`) - #102134 (Detect panic strategy using `rustc --print cfg`) - #102137 (Don't convert valtree to constvalue during normalization) - #102148 (add regression test for miri issue 2433) - #102158 (rustdoc: clean up CSS/DOM for deprecation warnings) - #102177 (Fix a typo in `std`'s root docs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Always print '_, even for erased lifetimes. Explicit lifetime arguments are now the recommended syntax in rust 2018 and rust 2021. This PR applies this discipline to rustc itself.
Revert perf-regression 101620 Reverts #101862 #101620 r? `@Mark-Simulacrum`
Add `#[inline]` to trivial functions on `core::sync::Exclusive` When optimizing for size things like these sometimes don't inlined even though they're generic. This is bad because they're no-ops. Only dodgy one is poll I guess since it forwards to the inner poll, but it's not like we're doing `#[inline(always)]` here.
Stabilize bench_black_box This PR stabilize `feature(bench_black_box)`. ```rust pub fn black_box<T>(dummy: T) -> T; ``` The FCP was completed in rust-lang/rust#64102. `@rustbot` label +T-libs-api -T-libs
Suggest unwrapping `???<T>` if a method cannot be found on it but is present on `T`. This suggests various ways to get inside wrapper types if the method cannot be found on the wrapper type, but is present on the wrappee. For this PR, those wrapper types include `Localkey`, `MaybeUninit`, `RefCell`, `RwLock` and `Mutex`.
…y-binding, r=cjgillot
Deny associated type bindings within associated type bindings
Fixes #102335
This was made worse by #100865, which unified the way we generate substs for GATs and non-generic associated types. However, the issue was not _caused_ by #100865, evidenced by the test I added for GATs:
```rust
trait T {
type A: S<C<(), i32 = ()> = ()>;
//~^ ERROR associated type bindings are not allowed here
}
trait Q {}
trait S {
type C<T>: Q;
}
fn main() {}
```
^ which passes on beta (where GATs are stable) and presumably ever since GATs support was added to `create_substs_for_associated_item` in astconv.
Unescaping cleanups Some minor improvements. r? `@matklad`
Tweak `FulfillProcessor`. Avoids some unnecessary references and lifetimes. r? `@jackh726`
Use already resolved `self_ty` in `confirm_fn_pointer_candidate` Fixes #102289
… r=camelid rustdoc: remove redundant mobile `.source > .sidebar` CSS When the source sidebar and standard sidebar had most of their code merged in 07e3f998b1ceb4b8d2a7992782e60f5e776aa114, the properties `z-index: 11`, `margin: 0`, and `position: fixed` were already being set on the `.sidebar` class, so no need to repeat them. https://github.com/rust-lang/rust/blob/57ee5cf5a93923dae9c98bffb11545fc3a31368d/src/librustdoc/html/static/css/rustdoc.css#L1742-L1754
Rollup of 8 pull requests Successful merges: - #100747 (Add long description and test for E0311) - #102232 (Stabilize bench_black_box) - #102288 (Suggest unwrapping `???<T>` if a method cannot be found on it but is present on `T`.) - #102338 (Deny associated type bindings within associated type bindings) - #102347 (Unescaping cleanups) - #102348 (Tweak `FulfillProcessor`.) - #102378 (Use already resolved `self_ty` in `confirm_fn_pointer_candidate`) - #102380 (rustdoc: remove redundant mobile `.source > .sidebar` CSS) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
More lexer improvements A follow-up to #99884. r? `@matklad`
…vidtwco Migrate more of rustc_parse to SessionDiagnostic Still far from complete, but I thought I'd add a checkpoint here because rebasing was starting to get annoying.
Do not overwrite lifetime binders for another HirId. This PR makes higher-ranked bounds in where clauses a bit more principled. We used to conflate `for<'a> T: Trait` with `(for<'a> T): Trait`. This PR separates both binders. This caused issued with fn types, which have their own binder, causing us to overwrite the predicates's binders with `fn`'s binders, ICEing. Fixes rust-lang/rust#98594
…wesleywiser Add `#[rustc_safe_intrinsic]` This PR adds the `#[rustc_safe_intrinsic]` attribute as mentionned on Zulip. The goal of this attribute is to avoid keeping a list of symbols as the source for stable intrinsics, and instead rely on an attribute. This is similar to `#[rustc_const_stable]` and `#[rustc_const_unstable]`, which among other things, are used to mark the constness of intrinsic functions.
rustdoc: Remove `clean::TraitWithExtraInfo` and queryify `is_notable_trait` cc `@notriddle` `@GuillaumeGomez`
Enable inline stack probes on PowerPC and SystemZ The LLVM PowerPC and SystemZ targets have both supported `"probe-stack"="inline-asm"` for longer than our current minimum LLVM 13 requirement, so we can turn this on for all `powerpc`, `powerpc64`, `powerpc64le`, and `s390x` targets in Rust. These are all tier-2 or lower, so CI does not run their tests, but I have confirmed that their `linux-gnu` variants do pass on RHEL. cc #43241
remove outdated coherence hack we have a more precise detection for downstream conflicts in candidate assembly: the `is_knowable` check in `candidate_from_obligation_no_cache`. r? types cc `@nikomatsakis`
Serialize return-position `impl Trait` in trait hidden values in foreign libraries Fixes #101630
…estebank Move lint level source explanation to the bottom So, uhhhhh r? `@estebank` ## User-facing change "note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic: ```diff - = note: `#[warn(unsupported_calling_conventions)]` on by default = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #87678 <rust-lang/rust#87678> + = note: `#[warn(unsupported_calling_conventions)]` on by default ``` Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO. ## Developer-facing change `struct_span_lint` and similar methods have a different signature. Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)` After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>` The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion. Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere. ## Subtle problem By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings... I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate. ## P.S. I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
Fix `format_args` capture for macro expanded format strings
Since #100996 `format_args` capture for macro expanded strings aren't prevented when the span of the expansion points to a string literal, e.g.
```rust
// not a terribly realistic example, but also happens for proc_macros that set
// the span of the output to an input str literal, such as indoc
macro_rules! x {
($e:expr) => { $e }
}
fn main() {
let a = 1;
println!(x!("{a}"));
}
```
The tests didn't catch it as the span of `concat!()` points to the macro invocation
r? `@m-ou-se`
|
Yea, this looks good now. Starting at the sync we see merge commits from rustc, but most of them are just merge commits of the B sort below, where we merge with a commit that is already in the history (X). This is much better than the previous sync. Looking at the other direction now |
|
Also see josh-project/josh#952 (comment) for why these merge commits arise. |
… r=joshtriplett Add `AsFd` implementations for stdio lock types on WASI. This mirrors the implementations on Unix platforms, and also mirrors the existing `AsRawFd` impls. This is similar to #100892, but is for the `*Lock` types.
|
I got the exact same sync commit with the other josh branch from josh-project/josh#965 (by the josh devs) :) |
…Simulacrum Adding target_rustcflags to `compiletest` TargetCfg creation Adjustment to rust-lang/rust#102134, ensures config returned by `rustc --target foo --print cfg` accurately reflects rustflags passed via `target_rustcflags`. Fixes breaking change of not correctly handling `x.py test ... --test-args "--target-rustcflags -Cpanic=abort --target-rustcflags -Zpanic_abort_tests"` cc `@djkoloski`
Fix unwind drop glue for if-then scopes cc `@est31` Fix #102317 Fix #99852 This PR fixes the drop glue for unwinding from a panic originated in a drop while breaking out for the else block in an `if-then` scope. MIR validation does not fail for the synchronous versions of the test program, because `StorageDead` statements are skipped over in the unwinding process. It is only becoming a problem when it is inside a generator where `StorageDead` must be kept around.
Miri sync This is a Miri sync created with my experimental fork of josh. We should probably not merge this yet, but we can use this to check if the sync looks the way it should. r? `@oli-obk`
Enable doctests in compiler/ crates Helps with rust-lang/rust#99144
…properly, r=GuillaumeGomez rustdoc: render more cross-crate HRTBs properly Follow-up to #102439. Render the `for<>` parameter lists of cross-crate higher-rank trait bounds (in where-clauses and in `impl Trait`). I've added a new field `bound_params` to `clean::WherePredicate::EqPredicate` (mirroring its sibling variant `BoundPredicate`). However, I had to box the existing fields since `EqPredicate` used to be the largest variant (128 bytes on 64-bit systems) and it would only have gotten bigger). Not sure if you like that approach. As an alternative, I could pass the uncleaned `ty::Predicate` alongside the cleaned `WherePredicate` to the various re-sugaring methods (similar to what `clean::AutoTraitFinder::param_env_to_generics` does). I haven't yet added the HTML & JSON rendering code for the newly added `bound_params` field since I am waiting for your opinion. Those two rendering code paths should actually be unreachable in practice given we re-sugar all(?) equality predicates to associated type bindings (and arbitrary equality predicates are not part of the Rust surface language at the time of this writing). If you agree with storing `bound_params` in `EqPredicate`, I think I can use it to greatly simplify the `clean::auto_trait` module (by also using `simplify::merge_bounds`). Maybe I can do that in any case though. `@rustbot` label T-rustdoc A-cross-crate-reexports r? `@GuillaumeGomez`
Standard library OS support for Apple WatchOS This PR was split from rust-lang/rust#98101
|
Given that two independent implementations of this josh feature produced the exact same commit -- should we risk it and land this before things land in josh upstream? I am not sure what their timeline is. |
|
worst case we'll force push again in the future |
|
so yea, let's go! |
I think cargo has a bug here: rust-lang/cargo#11191 but for now we bless its output so that we can keep CI green
|
We also have @bors r=oli-obk |
|
☀️ Test successful - checks-actions |
bors
added a commit
that referenced
this pull request
Apr 27, 2024
josh rustc-pull: check that no new root commits get created A second root was a bad sign in Miri (judging from the description in #2583) and seems to be a [bad sign in RA](rust-lang/rust-analyzer#17025 (comment)). So let's add this to the sanity checks.
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this pull request
Apr 27, 2024
josh rustc-pull: check that no new root commits get created A second root was a bad sign in Miri (judging from the description in rust-lang/miri#2583) and seems to be a [bad sign in RA](rust-lang/rust-analyzer#17025 (comment)). So let's add this to the sanity checks.
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this pull request
May 4, 2024
josh rustc-pull: check that no new root commits get created A second root was a bad sign in Miri (judging from the description in rust-lang/miri#2583) and seems to be a [bad sign in RA](rust-lang/rust-analyzer#17025 (comment)). So let's add this to the sanity checks.
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 demonstrates what a josh-based rustup would look like with my patched josh. To create it I did
Unlike the previous attempt, this does not add a new root commit to the repo.
Once we merge this, we committed to using josh for subtree syncing, and in particular a version of josh that includes josh-project/josh#961 (or something compatible).