Sync from rustc #17152
Closed
Sync from rustc #17152
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 test for recently fixed issue Adds a test for issue #116864.
check_consts: fix duplicate errors, make importance consistent This is stuff I noticed while working on rust-lang/rust#120932, but it's orthogonal to that PR. r? ``@oli-obk``
improve `btree_cursors` functions documentation As suggested by ``@Amanieu`` (and others) in #107540 (rust-lang/rust#107540 (comment)) Improvements: - Document exact behavior of `{upper/lower}_bound{,_mut}` with each of the three `Bound` types using unambigous words `{greatest,greater,smallest,smaller,before,after}`. - Added another doc-example for the `Bound::Unbounded` for each of the methods - Changed doc-example to use From<[T; N]> rather than lots of `insert()`s which requires a mutable map which clutters the example when `mut` may not be required for the method (such as for `{upper,lower}_bound`. - Removed `# Panics` section from `insert_{before,after}` methods since they were changed to return an error instead a while ago. - Reworded some phrases to be more consistent with the more regular `BTreeMap` methods such as calling entries "key-value" rather than "element"s.
Check that the ABI of the instance we are inlining is correct When computing the `CallSite` in the mir inliner, double check that the instance of the function that we are inlining is compatible with the signature from the trait definition that we acquire from the MIR. Fixes #120940 r? ``@oli-obk`` or ``@cjgillot``
…meGomez Clean inlined type alias with correct param-env We were cleaning the `hir::Ty` of a type alias item in the param-env of the item that *references* the type alias, and not the alias's own param-env. Fixes #120954
Add myself to library/std review I'll see how it goes.
…-errors fix ICE for deref coercions with type errors Follow-up to rust-lang/rust#120895, where I made types with errors go through the full coercion code, which is necessary if we want to build MIR for bodies with errors (rust-lang/rust#120550). The code for coercing `&T` to `&U` currently assumes that autoderef for `&T` will succeed for at least two steps (`&T` and `T`): https://github.com/rust-lang/rust/blob/b17491c8f6d555386104dfd82004c01bfef09c95/compiler/rustc_hir_typeck/src/coercion.rs#L339-L464 But for types with errors, we previously only returned the no-op autoderef step (`&{type error}` -> `&{type error}`) and then stopped early. This PR changes autoderef for types with errors to still go through the built-in derefs (e.g. `&&{type error}` -> `&{type error}` -> `{type error}`) and only stop early when it would have to go looking for `Deref` trait impls. fixes rust-lang/rust#120945 r? ``@compiler-errors`` or compiler
Rollup of 11 pull requests Successful merges: - #120765 (Reorder diagnostics API) - #120833 (More internal emit diagnostics cleanups) - #120899 (Gracefully handle non-WF alias in `assemble_alias_bound_candidates_recur`) - #120917 (Remove a bunch of dead parameters in functions) - #120928 (Add test for recently fixed issue) - #120933 (check_consts: fix duplicate errors, make importance consistent) - #120936 (improve `btree_cursors` functions documentation) - #120944 (Check that the ABI of the instance we are inlining is correct) - #120956 (Clean inlined type alias with correct param-env) - #120962 (Add myself to library/std review) - #120972 (fix ICE for deref coercions with type errors) r? `@ghost` `@rustbot` modify labels: rollup
…ler-errors pattern_analysis: track usefulness without interior mutability Because of or-patterns, exhaustiveness needs to be able to lint if a sub-pattern is redundant, e.g. in `Some(_) | Some(true)`. So far the only sane solution I had found was interior mutability. This is a bit of an abstraction leak, and would become a footgun if we ever reused the same `DeconstructedPat`. This PR replaces interior mutability with an address-indexed hashmap, which is logically equivalent.
Merge `impl_polarity` and `impl_trait_ref` queries Hopefully this is perf neutral. I want to finish rust-lang/rust#120835 and stop using the HIR in `coherent_trait`, which should then give us a perf improvement.
Implement sys/thread for UEFI Since UEFI has no concept of threads, most of this module can be ignored. However, implementing parts that make sense. - Implement sleep - Implement available_parallelism
Automatic Rustup
Update cargo 8 commits in ccc84ccec4b7340eb916aefda1cb3e2fe17d8e7b..fc1d58fd0531a57a6b942a14cdcdbcb82ece16f3 2024-02-07 15:37:49 +0000 to 2024-02-09 15:54:29 +0000 - docs(changelog): Clarify lints in virtual workspace error (rust-lang/cargo#13425) - fix(compiler): Clarify Finished message (rust-lang/cargo#13422) - fix(test-support): remove special case for `$message_type` (rust-lang/cargo#13424) - chore(deps): update msrv (1 version) to v1.76.0 (rust-lang/cargo#13420) - chore(bump-check): include rustfix and cargo-util-schemas (rust-lang/cargo#13421) - chore: update to `jobserver` 0.1.28 (rust-lang/cargo#13419) - feat: Add hint for adding members to workspace (rust-lang/cargo#13411) - fix: Don't duplicate comments when editing TOML (rust-lang/cargo#13402) r? weihanglo
Ignore own item bounds in parent alias types in `for_each_item_bound` Fixes #120912 I want to get a vibe check on this approach, which is very obviously a hack, but I believe something that is forwards-compatible with a more thorough solution and "good enough for now". The problem here is that for a really deep rigid associated type, we are now repeatedly considering unrelated item bounds from the parent alias types, meaning we're doing a *lot* of extra work in the MIR inliner for deeply substituted rigid projections. This feels intimately related to #107614. In that PR, we split *supertrait* bounds (bound which share the same `Self` type as the predicate which is being elaborated) and *implied* bounds (anything that is implied by elaborating the predicate). The problem here is related to the fact that we don't maintain the split between these two for `item_bounds`. If we did, then when recursing into a parent alias type, we'd want to consider only the bounds that are given by [`PredicateFilter::All`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/astconv/enum.PredicateFilter.html#variant.SelfOnly) **except** those given by [`PredicateFilter::SelfOnly`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/astconv/enum.PredicateFilter.html#variant.SelfOnly).
This mostly works well, and eliminates a couple of delayed bugs. One annoying thing is that we should really also add an `ErrorGuaranteed` to `proc_macro::bridge::LitKind::Err`. But that's difficult because `proc_macro` doesn't have access to `ErrorGuaranteed`, so we have to fake it.
…=m-ou-se
Document requirements for unsized {Rc,Arc}::from_raw
This seems to be implied due to these types supporting operation-less unsized coercions. Taken together with the [established behavior of a wide to thin pointer cast](rust-lang/reference#1451) it would enable unsafe downcasting of these containers.
Note that the term "data pointer" is adopted from rust-lang/rfcs#3559
See also this [internals thread](https://internals.rust-lang.org/t/can-unsafe-smart-pointer-downcasts-be-correct/20229/2).
Fix BTreeMap's Cursor::remove_{next,prev}
These would incorrectly leave `current` as `None` after a failed attempt to remove an element (due to the cursor already being at the start/end).
…d, r=m-ou-se std::thread update freebsd stack guard handling. up to now, it had been assumed the stack guard setting default is not touched in the field but some user might just want to disable it or increase it. checking it once at runtime should be enough.
Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`. Similar to recent work doing the same for `ExprKind::Err` (#120586) and `TyKind::Err` (#121109). r? `@oli-obk`
Waker::will_wake: Compare vtable address instead of its content Optimize will_wake implementation by comparing vtable address instead of its content. The existing best practice to avoid false negatives from will_wake is to define a waker vtable as a static item. That approach continues to works with the new implementation. While this potentially changes the observable behaviour, the function is documented to work on a best-effort basis. The PartialEq impl for RawWaker remains as it was.
Rollup of 8 pull requests
Successful merges:
- #120449 (Document requirements for unsized {Rc,Arc}::from_raw)
- #120505 (Fix BTreeMap's Cursor::remove_{next,prev})
- #120672 (std::thread update freebsd stack guard handling.)
- #121088 (Implicitly enable evex512 if avx512 is enabled)
- #121104 (Ignore unsized types when trying to determine the size of the original type)
- #121107 (Fix msg for verbose suggestions with confusable capitalization)
- #121113 (Continue compilation even if inherent impl checks fail)
- #121120 (Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.)
r? `@ghost`
`@rustbot` modify labels: rollup
Consider principal trait ref's auto-trait super-traits in dyn upcasting
Given traits like:
```rust
trait Subtrait: Supertrait + Send {}
trait Supertrait {}
```
We should be able to upcast `dyn Subtrait` to `dyn Supertrait + Send`. This is not currently possible, because when upcasting, we look at the list of auto traits in the object type (`dyn Subtrait`, which has no auto traits in its bounds) and compare them to the target's auto traits (`dyn Supertrait + Send`, which has `Send` in its bound).
Since the target has auto traits that are not present in the source, the upcasting fails. This is overly restrictive, since `dyn Subtrait` will always implement `Send` via its built-in object impl. I propose to loosen this restriction here.
r? types
---
### ~~Aside: Fix this in astconv instead?~~
### edit: This causes too many failures. See rust-lang/rust#119825 (comment)
We may also fix this by by automatically elaborating all auto-trait supertraits during `AstConv::conv_object_ty_poly_trait_ref`. That is, we can make it so that `dyn Subtrait` is elaborated into the same type of `dyn Subtrait + Send`.
I'm open to considering this solution instead, but it would break coherence in the following example:
```rust
trait Foo: Send {}
trait Bar {}
impl Bar for dyn Foo {}
impl Bar for dyn Foo + Send {}
//~^ This would begin to be an overlapping impl.
```
Skip coroutines in jump threading to avoid query cycles Fixes #121094
Implement Instant for UEFI - Uses Timestamp Protocol if present. Else use rdtsc for x86 and x86-64
Automatic Rustup
Use generic `NonZero` internally. Tracking issue: rust-lang/rust#120257
Implement intrinsics with fallback bodies fixes #93145 (though we can port many more intrinsics) cc #63585 The way this works is that the backend logic for generating custom code for intrinsics has been made fallible. The only failure path is "this intrinsic is unknown". The `Instance` (that was `InstanceDef::Intrinsic`) then gets converted to `InstanceDef::Item`, which represents the fallback body. A regular function call to that body is then codegenned. This is currently implemented for * codegen_ssa (so llvm and gcc) * codegen_cranelift other backends will need to adjust, but they can just keep doing what they were doing if they prefer (though adding new intrinsics to the compiler will then require them to implement them, instead of getting the fallback body). cc `@scottmcm` `@WaffleLapkin` ### todo * [ ] miri support * [x] default intrinsic name to name of function instead of requiring it to be specified in attribute * [x] make sure that the bodies are always available (must be collected for metadata)
Make File::read_to_end less special Follow-up to #117925
Tell LLVM Vec::len is invariant across growth This allows LLVM to avoid re-loading it from memory.
Stabilize Wasm target features that are in phase 4 and 5 This stabilizes the Wasm target features that are known to be working and in [phase 4 and 5](https://github.com/WebAssembly/proposals/tree/04fa8c810e1dc99ab399e41052a6e427ee988180). Feature stabilized: - [Non-trapping float-to-int conversions](https://github.com/WebAssembly/nontrapping-float-to-int-conversions) - [Import/Export of Mutable Globals](https://github.com/WebAssembly/mutable-global) - [Sign-extension operators](https://github.com/WebAssembly/sign-extension-ops) - [Bulk memory operations](https://github.com/WebAssembly/bulk-memory-operations) - [Extended Constant Expressions](https://github.com/WebAssembly/extended-const) Features not stabilized: - [Multi-value](https://github.com/WebAssembly/multi-value): requires rebuilding `std` #73755. - [Reference Types](https://github.com/WebAssembly/reference-types): no point stabilizing without #103516. - [Threads](https://github.com/webassembly/threads): requires rebuilding `std` #77839. - [Relaxed SIMD](https://github.com/WebAssembly/relaxed-simd): separate PR #117468. - [Multi Memory](https://github.com/WebAssembly/multi-memory): not implemented. See rust-lang/rust#117457 (comment) for more context. Documentation: rust-lang/reference#1420 Tracking issue: rust-lang/rust#44839
Miri subtree update r? `@ghost`
Fix trait solver overflow with `non_local_definitions` lint This PR fixes the trait solver overflow with the `non_local_definitions` lint reported in rust-lang/rust#123573 using the suggestion from `@lcnr:` rust-lang/rust#123573 (comment) to use the next trait solver. ~~I have not (yet) tried to create a minimized repro~~ ``@compiler-errors`` did the minimization (thanks you) but I have manually tested on the `starlark-rust` project that it fixes the issue. Fixes #123573 r? `@lcnr`
…-errors fix normalizing in different `ParamEnv`s with the same `InferCtxt` This PR changes the key of the projection cache from just `AliasTy` to `(AliasTy, ParamEnv)` to allow normalizing in different `ParamEnv`s without resetting caches. Previously, normalizing the same alias in different param envs would always reuse the cached result from the first normalization, which is incorrect if the projection clauses in the param env have changed. Fixing this bug allows us to get rid of `InferCtxt::clear_caches`, which was only used by the `AutoTraitFinder`, because it requires normalizing in different param envs. r? `@fmease`
Fix ICE when there is a non-Unicode entry in the incremental crate directory Fix the ICE that occurs when there is a non-Unicode entry in the incremental crate directory by replacing uses of `to_string_lossy` + `assert_no_characters_lost` with `to_str`. The added test would cause the compiler to ICE before this PR.
…rister Ignore `-C strip` on MSVC tl;dr - Define `-Cstrip` to only ever affect the binary; no other build artifacts. This is necessary to improve cross-platform behavior consistency: if someone wanted debug information to be contained only in separate files on all platforms, they would set `-Cstrip=symbols` and `-Csplit-debuginfo=packed`, but this would result in no PDB files on MSVC. Resolves #114215
Add simple async drop glue generation This is a prototype of the async drop glue generation for some simple types. Async drop glue is intended to behave very similar to the regular drop glue except for being asynchronous. Currently it does not execute synchronous drops but only calls user implementations of `AsyncDrop::async_drop` associative function and awaits the returned future. It is not complete as it only recurses into arrays, slices, tuples, and structs and does not have same sensible restrictions as the old `Drop` trait implementation like having the same bounds as the type definition, while code assumes their existence (requires a future work). This current design uses a workaround as it does not create any custom async destructor state machine types for ADTs, but instead uses types defined in the std library called future combinators (deferred_async_drop, chain, ready_unit). Also I recommend reading my [explainer](https://zetanumbers.github.io/book/async-drop-design.html). This is a part of the [MCP: Low level components for async drop](rust-lang/compiler-team#727) work. Feature completeness: - [x] `AsyncDrop` trait - [ ] `async_drop_in_place_raw`/async drop glue generation support for - [x] Trivially destructible types (integers, bools, floats, string slices, pointers, references, etc.) - [x] Arrays and slices (array pointer is unsized into slice pointer) - [x] ADTs (enums, structs, unions) - [x] tuple-like types (tuples, closures) - [ ] Dynamic types (`dyn Trait`, see explainer's [proposed design](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#async-drop-glue-for-dyn-trait)) - [ ] coroutines (rust-lang/rust#123948) - [x] Async drop glue includes sync drop glue code - [x] Cleanup branch generation for `async_drop_in_place_raw` - [ ] Union rejects non-trivially async destructible fields - [ ] `AsyncDrop` implementation requires same bounds as type definition - [ ] Skip trivially destructible fields (optimization) - [ ] New [`TyKind::AdtAsyncDestructor`](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#adt-async-destructor-types) and get rid of combinators - [ ] [Synchronously undroppable types](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#exclusively-async-drop) - [ ] Automatic async drop at the end of the scope in async context
…h726 `has_typeck_results` doesnt need to be a query self-explanatory
Enable `CrateNum` query feeding via `TyCtxt` Instead of having a magic function that violates some `TyCtxtFeed` invariants, add a `create_def` equivalent for `CrateNum`s. Note that this still isn't tracked by the query system (unlike `create_def`), and that feeding most `CrateNum` queries for crates other than the local one will likely cause performance regressions. These things should be attempted on their own separately, but this PR should stand on its own
Stop using LLVM struct types for alloca The alloca type has no semantic meaning, only the size (and alignment, but we specify it explicitly) matter. Using `[N x i8]` is a more direct way to specify that we want `N` bytes, and avoids relying on LLVM's struct layout. It is likely that a future LLVM version will change to an untyped alloca representation. Split out from #121577. r? `@ghost`
CI: dynamic jobs This PR modifies our CI workflows to be dynamic. This means that when a GitHub event is generated, we will run a Python script (`calculate-job-matrix.py`), which decides which CI jobs should be generated. These jobs are defined in `src/ci/github-actions/jobs.yml`). This should provide a few benefits: - Once the migration to dynamic jobs is complete, we shouldn't need `expand-yaml-anchors` anymore. - The job table on PRs (and also the left job column on auto/try builds) should be much cleaner and contain only the jobs that are actually relevant/executed. - It should be much easier to support dynamic try builds, i.e. to run an arbitrary CI job on a try build. See [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/job.20matrix.20re-ordered.20PR.20list) for more context. r? `@ghost`
And suggest adding the `#[coroutine]` to the closure
Require explicitly marking closures as coroutines instead of relying on patching up the closure to be a coroutine if it happens to contain a `yield` expression. I only do this in the 2024 edition, as the `gen` keyword is only available there.
delegation: Support renaming, and async, const, extern "ABI" and C-variadic functions Also allow delegating to functions with opaque types (`impl Trait`). The delegation item will refer to the original opaque type from the callee, fresh opaque type won't be created, which seems like a reasonable behavior. (Such delegation items will cause query cycles when used in trait impls, but it can be fixed later.) Part of rust-lang/rust#118212.
Set writable and dead_on_unwind attributes for sret arguments Set the `writable` and `dead_on_unwind` attributes for `sret` arguments. This allows call slot optimization to remove more memcpy's. See https://llvm.org/docs/LangRef.html#parameter-attributes for the specification of these attributes. In short, the statement we're making here is that: * The return slot is writable. * The return slot will not be read if the function unwinds. Fixes rust-lang/rust#90595.
Fix some typos in comments
Convert some iter macros to normal functions With all the MIR optimization changes that have happened since these were written, let's see if they still actually matter. \*perf comes back\* Well, it looks like it's not longer relevant for instruction, cycle, nor wall-time perf. Looks like a bunch of things are maybe 10kb bigger in debug, but some are also 50k *smaller* in debug. So I think they should switch to being normal functions as the "greatly improves performance" justification for them being macros seems to no longer be true -- probably thanks to us always building `core` with `-Z inline-mir` so the difference is negligible.
Stabilize `Utf8Chunks` Pending FCP in rust-lang/rust#99543. This PR includes the proposed modification in rust-lang/libs-team#190 as agreed in rust-lang/rust#99543 (comment).
bootstrap: keep all cargo test files in dist rustc-src Cargo tests use some files that we would otherwise exclude, especially the `cargo init` tests that are meant to deal with pre-existing `.git` and `.hg` repos and their ignore files. Keeping these in our dist tarball doesn't take much space, and allows distro builds to run these tests successfully.
rustbot
added
the
S-waiting-on-review
This was referenced Apr 27, 2024
Closed
Merged
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.
Not meant to be merged, just to demo what the history looks like. Cc @lnicola
This still leads to some duplicate commits, such as
Set sysroot-abi flag for proc-macro-cli when in-rust-tree is set. However, these are already duplicated in the rustc repo, so I don't think there is a way to avoid syncing that duplication over to RA. The bug happened when the duplicate was merged into rustc. (Specifically, that was rust-lang/rust#119988. The original version of the commit landed in rust-lang/rust#118861. Something about either the sync-to-ra of the original commit or the sync-to-rustc of the sync-to-ra doesn't seem to have been entirely clean.)