Clone rustc_public using josh sync #104
Open
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
Implement unstable trait impl This PR allows marking impls of stable trait with stable type as unstable. ## Approach In std/core, an impl can be marked as unstable by annotating it with ``#[unstable_feature_bound(feat_name)]``. This will add a ``ClauseKind::Unstable_Feature(feat_name)`` to the list of predicates in ``predicates_of`` . When an unstable impl's function is called, we will first iterate through all the goals in ``param_env`` to check if there is any ``ClauseKind::UnstableFeature(feat_name)`` in ``param_env``. The existence of ``ClauseKind::Unstable_Feature(feat_name)`` in ``param_env`` means an``#[unstable_feature_bound(feat_name)]`` is present at the call site of the function, so we allow the check to succeed in this case. If ``ClauseKind::UnstableFeature(feat_name)`` does not exist in ``param_env``, we will still allow the check to succeed for either of the cases below: 1. The feature is enabled through ``#[feature(feat_name)]`` outside of std / core. 2. We are in codegen because we may be monomorphizing a body from an upstream crate which had an unstable feature enabled that the downstream crate do not. For the rest of the case, it will fail with ambiguity. ## Limitation In this PR, we do not support: 1. using items that need ``#[unstable_feature_bound]`` within stable APIs 2. annotate main function with ``#[unstable_feature_bound]`` 3. annotate ``#[unstable_feature_bound]`` on items other than free function and impl ## Acknowledgement The design and mentoring are done by `@BoxyUwU`
Rollup of 15 pull requests Successful merges: - rust-lang/rust#142304 (tests: Add `RUST_BACKTRACE` and `-Cpanic` revisions to `panic-main.rs` test) - rust-lang/rust#143388 (Various refactors to the LTO handling code) - rust-lang/rust#143409 (Enable xgot feature for mips64 musl targets) - rust-lang/rust#143592 (UWP: link ntdll functions using raw-dylib) - rust-lang/rust#143595 (add `const_make_global`; err for `const_allocate` ptrs if didn't call) - rust-lang/rust#143678 (Added error for invalid char cast) - rust-lang/rust#143820 (Fixed a core crate compilation failure when enabling the `optimize_for_size` feature on some targets) - rust-lang/rust#143829 (Trim `BorrowedCursor` API) - rust-lang/rust#143851 (ci cleanup: rustdoc-gui-test now installs browser-ui-test) - rust-lang/rust#143856 (Linting public reexport of private dependencies) - rust-lang/rust#143895 (Dont collect assoc ty item bounds from trait where clause for host effect predicates) - rust-lang/rust#143922 (Improve path segment joining) - rust-lang/rust#143964 (Fix handling of SCRIPT_ARG in docker images) - rust-lang/rust#144002 (Update poison.rs) - rust-lang/rust#144016 (trait_sel: `MetaSized` always holds temporarily) r? `@ghost` `@rustbot` modify labels: rollup
`-Zhigher-ranked-assumptions`: Consider WF of coroutine witness when proving outlives assumptions ### TL;DR This PR introduces an unstable flag `-Zhigher-ranked-assumptions` which tests out a new algorithm for dealing with some of the higher-ranked outlives problems that come from auto trait bounds on coroutines. See: * rust-lang/rust#110338 While it doesn't fix all of the issues, it certainly fixed many of them, so I'd like to get this landed so people can test the flag on their own code. ### Background Consider, for example: ```rust use std::future::Future; trait Client { type Connecting<'a>: Future + Send where Self: 'a; fn connect(&self) -> Self::Connecting<'_>; } fn call_connect<C>(c: C) -> impl Future + Send where C: Client + Send + Sync, { async move { c.connect().await } } ``` Due to the fact that we erase the lifetimes in a coroutine, we can think of the interior type of the async block as something like: `exists<'r, 's> { C, &'r C, C::Connecting<'s> }`. The first field is the `c` we capture, the second is the auto-ref that we perform on the call to `.connect()`, and the third is the resulting future we're awaiting at the first and only await point. Note that every region is uniquified differently in the interior types. For the async block to be `Send`, we must prove that both of the interior types are `Send`. First, we have an `exists<'r, 's>` binder, which needs to be instantiated universally since we treat the regions in this binder as *unknown*[^exist]. This gives us two types: `{ &'!r C, C::Connecting<'!s> }`. Proving `&'!r C: Send` is easy due to a [`Send`](https://doc.rust-lang.org/nightly/std/marker/trait.Send.html#impl-Send-for-%26T) impl for references. Proving `C::Connecting<'!s>: Send` can only be done via the item bound, which then requires `C: '!s` to hold (due to the `where Self: 'a` on the associated type definition). Unfortunately, we don't know that `C: '!s` since we stripped away any relationship between the interior type and the param `C`. This leads to a bogus borrow checker error today! ### Approach Coroutine interiors are well-formed by virtue of them being borrow-checked, as long as their callers are invoking their parent functions in a well-formed way, then substitutions should also be well-formed. Therefore, in our example above, we should be able to deduce the assumption that `C: '!s` holds from the well-formedness of the interior type `C::Connecting<'!s>`. This PR introduces the notion of *coroutine assumptions*, which are the outlives assumptions that we can assume hold due to the well-formedness of a coroutine's interior types. These are computed alongside the coroutine types in the `CoroutineWitnessTypes` struct. When we instantiate the binder when proving an auto trait for a coroutine, we instantiate the `CoroutineWitnessTypes` and stash these newly instantiated assumptions in the region storage in the `InferCtxt`. Later on in lexical region resolution or MIR borrowck, we use these registered assumptions to discharge any placeholder outlives obligations that we would otherwise not be able to prove. ### How well does it work? I've added a ton of tests of different reported situations that users have shared on issues like rust-lang/rust#110338, and an (anecdotally) large number of those examples end up working straight out of the box! Some limitations are described below. ### How badly does it not work? The behavior today is quite rudimentary, since we currently discharge the placeholder assumptions pretty early in region resolution. This manifests itself as some limitations on the code that we accept. For example, `tests/ui/async-await/higher-ranked-auto-trait-11.rs` continues to fail. In that test, we must prove that a placeholder is equal to a universal for a param-env candidate to hold when proving an auto trait, e.g. `'!1 = 'a` is required to prove `T: Trait<'!1>` in a param-env that has `T: Trait<'a>`. Unfortunately, at that point in the MIR body, we only know that the placeholder is equal to some body-local existential NLL var `'?2`, which only gets equated to the universal `'a` when being stored into the return local later on in MIR borrowck. This could be fixed by integrating these assumptions into the type outlives machinery in a more first-class way, and delaying things to the end of MIR typeck when we know the full relationship between existential and universal NLL vars. Doing this integration today is quite difficult today. `tests/ui/async-await/higher-ranked-auto-trait-11.rs` fails because we don't compute the full transitive outlives relations between placeholders. In that test, we have in our region assumptions that some `'!1 = '!2` and `'!2 = '!3`, but we must prove `'!1 = '!3`. This can be fixed by computing the set of coroutine outlives assumptions in a more transitive way, or as I mentioned above, integrating these assumptions into the type outlives machinery in a more first-class way, since it's already responsible for the transitive outlives assumptions of universals. ### Moving forward I'm still quite happy with this implementation, and I'd like to land it for testing. I may work on overhauling both the way we compute these coroutine assumptions and also how we deal with the assumptions during (lexical/nll) region checking. But for now, I'd like to give users a chance to try out this new `-Zhigher-ranked-assumptions` flag to uncover more shortcomings. [^exist]: Instantiating this binder with infer regions would be incomplete, since we'd be asking for *some* instantiation of the interior types, not proving something for *all* instantiations of the interior types.
Subtree update of `rust-analyzer` r? `@ghost`
Use $crate in macros for rustc_public (aka stable_mir) This makes `#[macro_use] extern crate rustc_public` unnecessary (which brings all of `rustc_public`'s macros into scope for the entire crate); instead, now you can simply use `rustc_public::run!()`.
resolve: Make disambiguators for underscore bindings module-local Disambiguators attached to underscore name bindings (like `const _: u8 = something;`) do not need to be globally unique, they just need to be unique inside the module in which they live, because the bindings in a module are basically kept as `Map<BindingKey, SomeData>`. Also, the specific values of the disambiguators are not important, so a glob import of `const _` may have a different disambiguator than the original `const _` itself. So in this PR the disambiguator is just set to the current number of bindings in the module. This removes one more piece of global mutable state from resolver and unblocks rust-lang/rust#143884.
Fix wrong messages from methods with the same name from different traits fix issue rust-lang/rust#143740
Add myself to the `infra-ci` reviewer group and adjust some infra auto-labels - Commit 1 is a drive-by adjustment. Auto-label `src/ci` and `.github/workflows` with https://github.com/rust-lang/rust/labels/A-CI, and include `.github/workflows` for https://github.com/rust-lang/rust/labels/T-infra trigger files. - Commit 2 adds myself to the `infra-ci` reviewer adhoc group. r? ``````@Kobzol``````
ci: use windows 22 for all free runners try-job: `x86_64-msvc-*`
Rollup of 11 pull requests Successful merges: - rust-lang/rust#143280 (Remove duplicate error about raw underscore lifetime) - rust-lang/rust#143649 (Add test for `default_field_values` and `const_default`) - rust-lang/rust#143699 (Make `AsyncDrop` check that it's being implemented on a local ADT) - rust-lang/rust#143908 (`tests/ui`: A New Order [0/28] ) - rust-lang/rust#143909 (docs(alloc::fmt): Make type optional, instead of matching empty string) - rust-lang/rust#143925 (Make slice comparisons const) - rust-lang/rust#143997 (Use $crate in macros for rustc_public (aka stable_mir)) - rust-lang/rust#144013 (resolve: Make disambiguators for underscore bindings module-local) - rust-lang/rust#144029 (Fix wrong messages from methods with the same name from different traits) - rust-lang/rust#144063 (Add myself to the `infra-ci` reviewer group and adjust some infra auto-labels) - rust-lang/rust#144069 (ci: use windows 22 for all free runners) r? `@ghost` `@rustbot` modify labels: rollup
Split-up stability_index query
This PR aims to move deprecation and stability processing away from the monolithic `stability_index` query, and directly implement `lookup_{deprecation,stability,body_stability,const_stability}` queries.
The basic idea is to:
- move per-attribute sanity checks into `check_attr.rs`;
- move attribute compatibility checks into the `MissingStabilityAnnotations` visitor;
- progressively dismantle the `Annotator` visitor and the `stability_index` query.
The first commit contains functional change, and now warns when `#[automatically_derived]` is applied on a non-trait impl block. The other commits should not change visible behaviour.
Perf in rust-lang/rust#143845 (comment) shows small but consistent improvement, except for unused-warnings case. That case being a stress test, I'm leaning towards accepting the regression.
This PR changes `check_attr`, so has a high conflict rate on that file. This should not cause issues for review.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 460259d14de0274b97b8801e08cb2fe5f16fdac5 Filtered ref: 599ee17eb87c83f97eb37fd9fe264da65d4c9461 This merge was created using https://github.com/rust-lang/josh-sync.
minor: Sync from downstream
Rustc pull update
rustc_public: de-StableMIR-ize This PR updates relevant docs about StableMIR, basically just rewording StableMIR/SMIR to rustc_public/rustc_public's IR. The README.md in the `rustc_public` crate is out-dated. I plan to rewrite it after we fork rustc_public into its own repository. This PR doesn't change the fact that we still use `-Z unpretty=stable-mir` as a rustc parameter for printing the IR, since I feel it's a bit verbose and weird if we use `-Z unpretty=rustc-public-ir`. I was wondering if we can have a short and easy alias for rustc_public's IR.
clippy: make tests work in stage 1 This finally fixes rust-lang/rust#78717 :) Similar to what Miri already does, the clippy test step needs to carefully consider which compiler is used to build clippy and which compiler is linked into clippy (and thus must be used to build the test dependencies). On top of that we have some extra complications that Miri avoided by using `cargo-miri` for building its test dependencies: we need cargo to use the right rustc and the right sysroot, but rust-lang/cargo#4423 makes this quite hard to do. See the long comment in `src/tools/clippy/tests/compile-test.rs` for details. Some clippy tests tried to import rustc crates; that fundamentally requires a full bootstrap loop so it cannot work in stage 1. I had to kind of guess what those tests were doing so I don't know if my changes there make any sense. Cc ```@flip1995``` ```@Kobzol```
Mitigate `#[align]` name resolution ambiguity regression with a rename Mitigates beta regression rust-lang/rust#143834 after a beta backport. ### Background on the beta regression The name resolution regression arises due to rust-lang/rust#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as ```rs macro_rules! align { () => { /* .. */ }; } pub(crate) use align; // `use` here becomes ambiguous ``` ### Mitigation approach This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by: 1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`. 2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`. This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622). ### Alternative mitigation options [Various mitigation options were considered during the compiler triage meeting](rust-lang/rust#143834 (comment)), and those consideration are partly reproduced here: - Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own. - Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying. - Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code. - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code. - This avoids backing out a whole implementation. ### Review advice This PR is best reviewed commit-by-commit. - Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master. - Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass. This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.
Add approval blocking labels for new bors If a PR contains these labels, new bors won't let anyone approve it. We don't merge PRs using new bors yet, ofc, but I wanted to prepare this so that I don't forget about it. This was proposed here: [#t-lang/meetings > Triage meeting 2025-07-23 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202025-07-23/near/529407150) and implemented [here](rust-lang/bors#367). CC ````@RalfJung```` r? ````@oli-obk````
fix handling of base address for TypeId allocations This fixes the problems discovered by ````@theemathas```` in rust-lang/rust#142789: - const-eval would sometimes consider TypeId pointers to be null - the type ID is different in Miri than in regular executions Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations). r? ````@oli-obk````
const-eval: full support for pointer fragments This fixes rust-lang/const-eval#72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in rust-lang/rust#137280. For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics: ```rust use std::{mem::{self, MaybeUninit}, ptr}; type Byte = MaybeUninit<u8>; const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) { let mut i = 0; while i < n { *dst.add(i) = *src.add(i); i += 1; } } const _MEMCPY: () = unsafe { let ptr = &42; let mut ptr2 = ptr::null::<i32>(); // Copy from ptr to ptr2. memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>()); assert!(*ptr2 == 42); }; ``` What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again. We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^ This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to rust-lang/unsafe-code-guidelines#558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
|
I was planning to open two separate PRs for josh-sync and infrastructure, since this one includes bunches of commits that would make reviewing difficult if the two parts were mixed. |
|
Makes sense |
|
It looks like we have to fix the book deployment |
|
What about the Cargo.toml though? I do think it would be cleaner to have a |
|
Yea that can done with josh, but unsure if the rust-lang josh script can do it If it can, that seems like a nice idea to keep many rustc_public things in this repo next to each other |
|
rustc-josh-sync currently doesn't support using josh-filter, but now I am able to clone rustc_public into a subdir by modifying rustc-josh-sync. |
|
I still want to reuse rustc-josh-sync, though which apparently requires us to come up with a more general solution for adding josh-filter to it. So atm we could write our own josh script first, then see if there's any chance to contribute this back to rustc-josh-sync. |
… r=petrochenkov Sometimes skip over tokens in `parse_token_tree`. r? `@petrochenkov`
rust-cloud-vms
bot
force-pushed
the
josh-history
branch
from
8c86f11 to
2e2ea6e
Compare
|
Oh just found adding that filter to the url has the same effect as using the josh-filter command. yay so we don't need to write anything else ^^ |
|
I need to read a bit more about how josh-sync works. If it's like subtree, squashing will definitely break the synchronization. I'm assuming that rebase strategy will be okay as long as there's no rebase to be performed. Let me take a look at it quickly. @makai410 maybe hold on merging other changes for now and let's make sure this PR is up-to-date |
|
Btw, the reason I'm worried is because of this comment:
|
…efix=rustc_public
rust-cloud-vms
bot
force-pushed
the
josh-history
branch
from
2e2ea6e to
7d8cf35
Compare
|
Oh I see the problem here. Check if this version can be merged using normal merges |
celinval
approved these changes
Aug 20, 2025
|
@makai410 can you please double check that this PR is tracking the latest commit in the main branch? |
|
I.e., make sure this PR is the result of running the rustc-josh-sync against the head of the main branch of the project-stable-mir repo. After that, select the rebase and merge option. |
|
I’ve confirmed that the PR is tracking the latest commit in the main branch. |
I'm seeing the following message with rebase though: "This branch cannot be rebased due to conflicts" |
|
ummm I've tried to use rebase instead of merge on my branch, josh works fine but then I can't open a PR on github since the histories are entirely different. And I also tried to rebase this branch onto upstream/main to resolve the "conflicts", then the history was much cleaner but josh was broken. I am afraid that we should use normal merge. :( |
|
Can you create a new PR for now? We need to request a change to this repo settings to the rust admin in order to enable normal merge. |
It does support it, you can specify a filter instead of a subdirectory path :) |
Thanks for the reminder, and actually I've fixed that ^^ #104 (comment) |
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 PR was created using https://github.com/rust-lang/josh-sync.
cc @oli-obk @celinval