Integrate with Josh #1617
Open
Integrate with Josh #1617
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
…mann Remove unused argument `features` from `eval_config_entry`
…ivooeo Use the current lint note id when parsing `cfg!()`
Rollup of 22 pull requests Successful merges: - rust-lang/rust#128666 (Add `overflow_checks` intrinsic) - rust-lang/rust#146305 (Add correct suggestion for multi-references for self type in method) - rust-lang/rust#147179 ([DebugInfo] Fix container types failing to find template args) - rust-lang/rust#147743 (Show packed field alignment in mir_transform_unaligned_packed_ref) - rust-lang/rust#148079 (Rename `downcast_[ref|mut]_unchecked` -> `downcast_unchecked_[ref|mut]`) - rust-lang/rust#148084 (Optimize path components iteration on platforms that don't have prefixes) - rust-lang/rust#148126 (Fix rust stdlib build failing for VxWorks) - rust-lang/rust#148204 (Modify contributor email entries in .mailmap) - rust-lang/rust#148279 (rustc_builtin_macros: rename bench parameter to avoid collisions with user-defined function names) - rust-lang/rust#148333 (constify result unwrap unchecked) - rust-lang/rust#148539 (Add Allocator proxy impls for Box, Rc, and Arc) - rust-lang/rust#148601 (`invalid_atomic_ordering`: also lint `update` & `try_update`) - rust-lang/rust#148612 (Add note for identifier with attempted hygiene violation) - rust-lang/rust#148613 (Switch hexagon targets to rust-lld) - rust-lang/rust#148619 (Enable std locking functions on AIX) - rust-lang/rust#148644 ([bootstrap] Make `--open` option work with `doc src/tools/error_index_generator`) - rust-lang/rust#148649 (don't completely reset `HeadUsages`) - rust-lang/rust#148673 (Remove a remnant of `dyn*` from the parser) - rust-lang/rust#148675 (Remove eslint-js from npm dependencies) - rust-lang/rust#148680 (Recover `[T: N]` as `[T; N]`) - rust-lang/rust#148688 (Remove unused argument `features` from `eval_config_entry`) - rust-lang/rust#148711 (Use the current lint note id when parsing `cfg!()`) r? `@ghost` `@rustbot` modify labels: rollup
Encode cfg trace, not its early counterpart to fix cross-crate `doc(auto_cfg)` Fixes rust-lang/rust#141301. <details><summary>Rambling about <code>target_feature</code> which I didn't touch here</summary> Regarding rust-lang/rust#141301 (comment) (`#[target_feature(enable = …)]` on inlined cross-crate re-exports), it has the same underlying cause (namely, we neither encode `target_feature` nor `AttributeKind::TargetFeature` in the crate metadata). However, I didn't make that change because I first want to experiment with querying `TyCtxt::codegen_fn_attrs` in rustdoc instead which already works cross-crate (and also use to it for reconstructing `no_mangle`, `export_name`, `link_section` to avoid encoding these attributes unnecessarily (basically reverting rust-lang/rust#144050) as suggested in rust-lang/rust#144004 (comment)). </details> r? GuillaumeGomez
…ieyouxu Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2 Implement the [MCP 932](rust-lang/compiler-team#932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools. Closes rust-lang/rust#148353. Changes: - Update target tier from 3 to 2 in target specification - Update platform documentation - Add CI/CD support for automatic building and distribution via rustup r? jieyouxu cc `@davidtwco` `@Noratrieb`
Update LLVM to 21.1.5 Includes some fixes for BPF.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 8401398e1f14a24670ee1a3203713dc2f0f8b3a8 Filtered ref: f9e99a8e85fa360f0e820dc75d46cb4583b4300d Upstream diff: rust-lang/rust@73e6c9e...8401398 This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 8401398e1f14a24670ee1a3203713dc2f0f8b3a8 Filtered ref: 52a911b7100ca6a6ed84159c51ce514a98ae9cf5 Upstream diff: rust-lang/rust@c5dabe8...8401398 This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 8401398e1f14a24670ee1a3203713dc2f0f8b3a8 Filtered ref: 9c097c092eaa8dd786fa7c138a3ecd67b4568d00 Upstream diff: rust-lang/rust@ceb7df7...8401398 This merge was created using https://github.com/rust-lang/josh-sync.
compiletest: Run the `lldb_batchmode.py` script in LLDB's embedded Python Historically, LLDB debuginfo tests have used a Python script to control LLDB via its Python API, instead of invoking the `lldb` command directly. Unfortunately, this requires us to find and use a version of Python that is compatible with LLDB's Python bindings. However, it turns out that there is a simpler way to find a compatible Python interpreter: use the one that is embedded in LLDB itself, via the `script` command.
Automatic Rustup
Rustc pull update
epoll: do proper edge detection inside the epoll system
stop specializing on `Copy` fixes rust-lang/rust#132442 `std` specializes on `Copy` to optimize certain library functions such as `clone_from_slice`. This is unsound, however, as the `Copy` implementation may not be always applicable because of lifetime bounds, which specialization does not take into account; the result being that values are copied even though they are not `Copy`. For instance, this code: ```rust struct SometimesCopy<'a>(&'a Cell<bool>); impl<'a> Clone for SometimesCopy<'a> { fn clone(&self) -> Self { self.0.set(true); Self(self.0) } } impl Copy for SometimesCopy<'static> {} let clone_called = Cell::new(false); // As SometimesCopy<'clone_called> is not 'static, this must run `clone`, // setting the value to `true`. let _ = [SometimesCopy(&clone_called)].clone(); assert!(clone_called.get()); ``` should not panic, but does ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6be7a48cad849d8bd064491616fdb43c)). To solve this, this PR introduces a new `unsafe` trait: `TrivialClone`. This trait may be implemented whenever the `Clone` implementation is equivalent to copying the value (so e.g. `fn clone(&self) -> Self { *self }`). Because of lifetime erasure, there is no way for the `Clone` implementation to observe lifetime bounds, meaning that even if the `TrivialClone` has stricter bounds than the `Clone` implementation, its invariant still holds. Therefore, it is sound to specialize on `TrivialClone`. I've changed all `Copy` specializations in the standard library to specialize on `TrivialClone` instead. Unfortunately, the unsound `#[rustc_unsafe_specialization_marker]` attribute on `Copy` cannot be removed in this PR as `hashbrown` still depends on it. I'll make a PR updating `hashbrown` once this lands. With `Copy` no longer being considered for specialization, this change alone would result in the standard library optimizations not being applied for user types unaware of `TrivialClone`. To avoid this and restore the optimizations in most cases, I have changed the expansion of `#[derive(Clone)]`: Currently, whenever both `Clone` and `Copy` are derived, the `clone` method performs a copy of the value. With this PR, the derive macro also adds a `TrivialClone` implementation to make this case observable using specialization. I anticipate that most users will use `#[derive(Clone, Copy)]` whenever both are applicable, so most users will still profit from the library optimizations. Unfortunately, Hyrum's law applies to this PR: there are some popular crates which rely on the precise specialization behaviour of `core` to implement "specialization at home", e.g. [`libAFL`](https://github.com/AFLplusplus/LibAFL/blob/89cff637025c1652c24e8d97a30a2e3d01f187a4/libafl_bolts/src/tuples.rs#L27-L49). I have no remorse for breaking such horrible code, but perhaps we should open other, better ways to satisfy their needs – for example by dropping the `'static` bound on `TypeId::of`...
Rustc pull update
Implement IsZero for (), and optimize `IsZero::is_zero` for arrays
These are probably not super useful optimizations, but they make it so that `vec![expr; LARGE_LENGTH]` has better performance for some `expr`s, e.g.
* array of length zero in debug mode
* tuple containing `()` and zero-valued integers in debug and release mode
* array of `()` or other zero-sized `IsZero` type in debug mode
<details> <summary>very rough benchmarks</summary>
```Rust
use std::time::Instant;
use std::sync::atomic::{AtomicUsize, Ordering::Relaxed};
struct NonCopyZst;
static COUNTER: AtomicUsize = AtomicUsize::new(0);
impl Clone for NonCopyZst {
fn clone(&self) -> Self {
COUNTER.fetch_add(1, Relaxed);
Self
}
}
macro_rules! timeit {
($e:expr) => {
let start = Instant::now();
_ = $e;
println!("{:56}: {:?}", stringify!($e), start.elapsed());
};
}
fn main() {
timeit!(vec![[String::from("hello"); 0]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![(0u8, (), 0u16); 1_000_000_000]); // gets a lot better in debug *and* release mode
timeit!(vec![[[(); 37]; 1_000_000_000]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![[NonCopyZst; 0]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![[[1u8; 0]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
timeit!(vec![[[(); 37]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
timeit!(vec![[[1u128; 0]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
// check that we don't regress existing optimizations
timeit!(vec![(0u8, 0u16); 1_000_000_000]); // about the same time
timeit!(vec![0u32; 1_000_000_000]); // about the same time
// check that we still call clone for non-IsZero ZSTs
timeit!(vec![[const { NonCopyZst }; 2]; 1_000]); // about the same time
assert_eq!(COUNTER.load(Relaxed), 1998);
timeit!(vec![NonCopyZst; 10_000]); // about the same time
assert_eq!(COUNTER.load(Relaxed), 1998 + 9_999);
}
```
```rs
$ cargo +nightly run
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 11.13999724s
vec![(0u8, (), 0u16); 1_000_000_000] : 5.254646651s
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 2.738062531s
vec![[NonCopyZst; 0]; 1_000_000_000] : 9.483690922s
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 2.919236ms
vec![[[(); 37]; 1_000_000]; 1_000_000] : 2.927755ms
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 2.931486ms
vec![(0u8, 0u16); 1_000_000_000] : 19.46µs
vec![0u32; 1_000_000_000] : 9.34µs
vec![[const { NonCopyZst }; 2]; 1_000] : 31.88µs
vec![NonCopyZst; 10_000] : 36.519µs
```
```rs
$ cargo +dev run
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 4.12µs
vec![(0u8, (), 0u16); 1_000_000_000] : 16.299µs
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 210ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 210ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 170ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 110ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 140ns
vec![(0u8, 0u16); 1_000_000_000] : 11.56µs
vec![0u32; 1_000_000_000] : 10.71µs
vec![[const { NonCopyZst }; 2]; 1_000] : 36.08µs
vec![NonCopyZst; 10_000] : 73.21µs
```
(checking release mode to make sure this doesn't regress perf there)
```rs
$ cargo +nightly run --release
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 70ns
vec![(0u8, (), 0u16); 1_000_000_000] : 1.269457501s
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 10ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 20ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 10ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 20ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 20ns
vec![(0u8, 0u16); 1_000_000_000] : 20ns
vec![0u32; 1_000_000_000] : 20ns
vec![[const { NonCopyZst }; 2]; 1_000] : 2.66µs
vec![NonCopyZst; 10_000] : 13.39µs
```
```rs
$ cargo +dev run --release
vec![[String::from("hello"); 0]; 1_000_000_000] : 90ns
vec![(0u8, (), 0u16); 1_000_000_000] : 30ns
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 20ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 30ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 20ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 20ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 20ns
vec![(0u8, 0u16); 1_000_000_000] : 30ns
vec![0u32; 1_000_000_000] : 20ns
vec![[const { NonCopyZst }; 2]; 1_000] : 3.52µs
vec![NonCopyZst; 10_000] : 17.13µs
```
</details>
The specific expression I ran into a perf issue that this PR addresses is `vec![[(); LARGE]; LARGE]`, as I was trying to demonstrate `Vec::into_flattened` panicking on length overflow in the playground, but got a timeout error instead since `vec![[(); LARGE]; LARGE]` took so long to run in debug mode (it runs fine on the playground in release mode)
std: support `RwLock` and thread parking on TEEOS Since TEEOS supports pthread mutexes and condvars, it can share the pthread-based thread parking implementation and thus also the queue-based `RwLock` implementation used on other platforms. CC ``@petrochenkov`` ``@Sword-Destiny``
rustc_target: hide TargetOptions::vendor Discussed in rust-lang/rust#148531 (comment). r? `````@bjorn3`````
IAT: Reinstate early bailout Apparently, some people are already using IATs in their projects and get blocked by rust-lang/rust#142006 (comment) (cc dupes rust-lang/rust#143952 & rust-lang/rust#148535). Since the (temporary) fix is so trivial, let's just do it. Addresses rust-lang/rust#142006 (comment). cc ```@luissantosHCIT``` (rust-lang/rust#148535). r? ```@BoxyUwU```
Fix a typo in the documentation for the strict_shr function fix: rust-lang/rust#148761
…ercote
Implement DynSend and DynSync for std::panic::Location.
Allows the compiler to build with the `debug_refcell` stdlib cargo feature.
With `rust.std-features = ["debug_refcell"]` in bootstrap.toml, `./x.py build --stage 2` fails before this patch, and succeeds afterwards.
<details> <summary>error for `./x.py build --stage 2` before this patch</summary>
```Rust
error[E0277]: `NonNull<str>` doesn't implement `DynSync`. Add it to `rustc_data_structures::marker` or use `IntoDynSyncSend` if it's already `Sync`
--> compiler/rustc_query_system/src/dep_graph/serialized.rs:719:33
|
719 | let results = broadcast(|_| {
| _______________________---------_^
| | |
| | required by a bound introduced by this call
720 | | let mut local = self.local.borrow_mut();
... |
734 | | });
| |_________^ within `Location<'static>`, the trait `DynSync` is not implemented for `NonNull<str>`
|
note: required because it appears within the type `Location<'static>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/panic/location.rs:39:12
|
39 | pub struct Location<'a> {
| ^^^^^^^^
= note: required for `&'static Location<'static>` to implement `DynSend`
note: required because it appears within the type `std::option::Option<&'static Location<'static>>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/option.rs:599:10
|
599 | pub enum Option<T> {
| ^^^^^^
note: required because it appears within the type `std::cell::UnsafeCell<std::option::Option<&'static Location<'static>>>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/cell.rs:2289:12
|
2289 | pub struct UnsafeCell<T: ?Sized> {
| ^^^^^^^^^^
note: required because it appears within the type `Cell<std::option::Option<&'static Location<'static>>>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/cell.rs:313:12
|
313 | pub struct Cell<T: ?Sized> {
| ^^^^
note: required because it appears within the type `RefCell<LocalEncoderState>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/cell.rs:822:12
|
822 | pub struct RefCell<T: ?Sized> {
| ^^^^^^^
= note: required for `rustc_data_structures::sync::WorkerLocal<RefCell<LocalEncoderState>>` to implement `DynSync`
note: required because it appears within the type `EncoderState<D>`
--> compiler/rustc_query_system/src/dep_graph/serialized.rs:546:8
|
546 | struct EncoderState<D: Deps> {
| ^^^^^^^^^^^^
= note: required because it appears within the type `&EncoderState<D>`
note: required because it's used within this closure
--> compiler/rustc_query_system/src/dep_graph/serialized.rs:719:33
|
719 | let results = broadcast(|_| {
| ^^^
note: required by a bound in `rustc_data_structures::sync::broadcast`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/compiler/rustc_data_structures/src/sync/parallel.rs:239:56
|
239 | pub fn broadcast<R: DynSend>(op: impl Fn(usize) -> R + DynSync) -> Vec<R> {
| ^^^^^^^ required by this bound in `broadcast`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `rustc_query_system` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Build completed unsuccessfully in 0:02:04
```
</details>
[rustdoc] Remove unneeded `allow(rustc::potential_query_instability)` Originally replaced it with an `expect` and since it failed compilation because it wasn't triggered, I removed it.
add test for assoc type norm wf check This is soundness critical 😁 sure is helpful to have tests for that. cc ``@rust-lang/types`` r? ``@BoxyUwU``
Replace `master` branch references with `main` Additional work on branch name changes r? ```@Kobzol``` related pr: rust-lang/rust#148564
fix "is_closure_like" doc comment Noticed that the [docs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.is_closure_like) stopped in the middle of the sentence. The text exists, but wasn't rendered because it was a regular comment.
Prefer to use file.stable_id over file.name from source map From rust-lang/rust#148735 (comment) r? `@Muscraft`
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to rust-lang/rustc-dev-guide@02ba22e. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
Document (and test) a problem with `Clone`/`Copy` deriving. I think this is useful information. I have worked on `derive` impls quite a bit and didn't know about this issue until today. r? `@saethlin`
Rollup of 13 pull requests Successful merges: - rust-lang/rust#148694 (std: support `RwLock` and thread parking on TEEOS) - rust-lang/rust#148712 (Port `cfg_select!` to the new attribute parsing system) - rust-lang/rust#148760 (rustc_target: hide TargetOptions::vendor) - rust-lang/rust#148771 (IAT: Reinstate early bailout) - rust-lang/rust#148775 (Fix a typo in the documentation for the strict_shr function) - rust-lang/rust#148779 (Implement DynSend and DynSync for std::panic::Location.) - rust-lang/rust#148781 ([rustdoc] Remove unneeded `allow(rustc::potential_query_instability)`) - rust-lang/rust#148783 (add test for assoc type norm wf check) - rust-lang/rust#148785 (Replace `master` branch references with `main`) - rust-lang/rust#148791 (fix "is_closure_like" doc comment) - rust-lang/rust#148792 (Prefer to use file.stable_id over file.name from source map) - rust-lang/rust#148805 (rustc-dev-guide subtree update) - rust-lang/rust#148807 (Document (and test) a problem with `Clone`/`Copy` deriving.) r? `@ghost` `@rustbot` modify labels: rollup
…uwer Rollup of 4 pull requests Successful merges: - rust-lang/rust#149840 (Update comment for `STAGE0_MISSING_TARGETS`) - rust-lang/rust#150109 (crash test readme: point to rustc-dev-guide) - rust-lang/rust#150204 (Port `#[cfi_encoding]` to attribute parser) - rust-lang/rust#150237 (Skip tidy target-specific check for `run-make-cargo` too) r? `@ghost` `@rustbot` modify labels: rollup
interpreter/visitor: always iterate in in-memory order Now that this is directly available in the type, there's no reason to ever iterate in any other order.
…umeGomez rustdoc: upgrade to stringdex 0.0.4 - code cleanup - smaller encoding for runs - fast path for the common encoding case
remove llvm_enzyme and enzyme fallbacks from most places Using dlopen to get symbols has the nice benefit that rustc itself doesn't depend on libenzyme symbols anymore. We can therefore delete most fallback implementations in the backend (independently of whether we enable enzyme or not). When trying to use autodiff on nightly, we will now fail with a nice error if and only if we fail to load libEnzyme-21.so in our backend. Verified: Build as nightly, without Enzyme Build as nightly, with Enzyme Build as stable (without Enzyme) With this PR we will now run `tests/ui/autodiff` on nightly, the tests are passing. r? `@kobzol`
std: Use `usleep` temporarily on WASI targets This fixes some fallout from rust-lang/rust#147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to rust-lang/rust#149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release. Closes rust-lang/rust#150290
Subtree sync for rustc_codegen_cranelift The main highlight this time is a Cranelift update. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
MGCA: Support struct expressions without intermediary anon consts r? oli-obk tracking issue: rust-lang/rust#132980 Fixes rust-lang/rust#127972 Fixes rust-lang/rust#137888 Fixes rust-lang/rust#140275 due to delaying a bug instead of ICEing in HIR ty lowering. ### High level goal Under `feature(min_generic_const_args)` this PR adds another kind of const argument. A struct/variant construction const arg kind. We represent the values of the fields as themselves being const arguments which allows for uses of generic parameters subject to the existing restrictions present in `min_generic_const_args`: ```rust fn foo<const N: Option<u32>>() {} trait Trait { #[type_const] const ASSOC: usize; } fn bar<T: Trait, const N: u32>() { // the initializer of `_0` is a `N` which is a legal const argument // so this is ok. foo::<{ Some::<u32> { 0: N } }>(); // this is allowed as mgca supports uses of assoc consts in the // type system. ie `<T as Trait>::ASSOC` is a legal const argument foo::<{ Some::<u32> { 0: <T as Trait>::ASSOC } }>(); // this on the other hand is not allowed as `N + 1` is not a legal // const argument foo::<{ Some::<u32> { 0: N + 1 } }>(); } ``` This PR does not support uses of const ctors, e.g. `None`. And also does not support tuple constructors, e.g. `Some(N)`. I believe that it would not be difficult to add support for such functionality after this PR lands so have left it out deliberately. We currently require that all generic parameters on the type being constructed be explicitly specified. I haven't really looked into why that is but it doesn't seem desirable to me as it should be legal to write `Some { ... }` in a const argument inside of a body and have that desugar to `Some::<_> { ... }`. Regardless this can definitely be a follow-up PR and I assume this is some underlying consistency with the way that elided args are handled with type paths elsewhere. This PRs implementation of supporting struct expressions is somewhat incomplete. We don't handle `Foo { ..expr }` at all and aren't handling privacy/stability. The printing of `ConstArgKind::Struct` HIR nodes doesn't really exist either :') I've tried to keep the implementation here somewhat deliberately incomplete as I think a number of these issues are actually quite small and self contained after this PR lands and I'm hoping it could be a good set of issues to mentor newer contributors on 🤔 I just wanted the "bare minimum" required to actually demonstrate that the previous changes are "necessary". ### `ValTree` now recurse through `ty::Const` In order to actually represent struct/variant construction in `ty::Const` without going through an anon const we would need to introduce some new `ConstKind` variant. Let's say some hypothetical `ConstKind::ADT(Ty<'tcx>, List<Const<'tcx>>)`. This variant would represent things the same way that `ValTree` does with the first element representing the `VariantIdx` of the enum (if its an enum), and then followed by a list of field values in definition order. This *could* work but there are a few reasons why it's suboptimal. First it would mean we have a second kind of `Const` that can be normalized. Right now we only have `ConstKind::Unevaluated` which possibly needs normalization. Similarly with `TyKind` we *only* have `TyKind::Alias`. If we introduced `ConstKind::ADT` it would need to be normalized to a `ConstKind::Value` eventually. This feels to me like it has the potential to cause bugs in the long run where only `ConstKind::Unevaluated` is handled by some code paths. Secondly it would make type equality/inference be kind of... weird... It's desirable for `Some { 0: ?x } eq Some { 0: 1_u32 }` to result in `?x=1_u32`. I can't see a way for this to work with this `ConstKind::ADT` design under the current architecture for how we represent types/consts and generally do equality operations. We would need to wholly special case these two variants in type equality and have a custom recursive walker separate from the existing architecture for doing type equality. It would also be somewhat unique in that it's a non-rigid `ty::Const` (it can be normalized more later on in type inference) while also having somewhat "structural" equality behaviour. Lastly, it's worth noting that its not *actually* `ConstKind::ADT` that we want. It's desirable to extend this setup to also support tuples and arrays, or even references if we wind up supporting those in const generics. Therefore this isn't really `ConstKind::ADT` but a more general `ConstKind::ShallowValue` or something to that effect. It represents at least one "layer" of a types value :') Instead of doing this implementation choice we instead change `ValTree::Branch`: ```rust enum ValTree<'tcx> { Leaf(ScalarInt), // Before this PR: Branch(Box<[ValTree<'tcx>]>), // After this PR Branch(Box<[Const<'tcx>]>), } ``` The representation for so called "shallow values" is now the same as the representation for the *entire* full value. The desired inference/type equality behaviour just falls right out of this. We also don't wind up with these shallow values actually being non-rigid. And `ValTree` *already* supports references/tuples/arrays so we can handle those just fine. I think in the future it might be worth considering inlining `ValTree` into `ty::ConstKind`. E.g: ```rust enum ConstKind { Scalar(Ty<'tcx>, ScalarInt), ShallowValue(Ty<'tcx>, List<Const<'tcx>>), Unevaluated(UnevaluatedConst<'tcx>), ... } ``` This would imply that the usage of `ValTree`s in patterns would now be using `ty::Const` but they already kind of are anyway and I think that's probably okay in the long run. It also would mean that the set of things we *could* represent in const patterns is greater which may be desirable in the long run for supporting things such as const patterns of const generic parameters. Regardless, this PR doesn't actually inline `ValTree` into `ty::ConstKind`, it only changes `Branch` to recurse through `Const`. This change could be split out of this PR if desired. I'm not sure if there'll be a perf impact from this change. It's somewhat plausible as now all const pattern values that have nesting will be interning a lot more `Ty`s. We shall see :> ### Forbidding generic parameters under mgca Under mgca we now allow all const arguments to resolve paths to generic parameters. We then *later* actually validate that the const arg should be allowed to access generic parameters if it did wind up resolving to any. This winds up just being a lot simpler to implement than trying to make name resolution "keep track" of whether we're inside of a non-anon-const const arg and then encounter a `const { ... }` indicating we should now stop allowing resolving to generic parameters. It's also somewhat in line with what we'll need for a `feature(generic_const_args)` where we'll want to decide whether an anon const should have any generic parameters based off syntactically whether any generic parameters were used. Though that design is entirely hypothetical at this point :) ### Followup Work - Make HIR ty lowering check whether lowering generic parameters is supported and if not lower to an error type/const. Should make the code cleaner, fix some other bugs, and maybe(?) recover perf since we'll be accessing less queries which I think is part of the perf regression of this PR - Make the ValTree setup less scuffed. We should find a new name for `ConstKind::Value` and the `Val` part of `ValTree` and `ty::Value` as they no longer correspond to a fully normalized structure. It may also be worth looking into inlining `ValTreeKind` into `ConstKind` or atleast into `ty::Value` or sth 🤔 - Support tuple constructors and const constructors not just struct expressions. - Reduce code duplication between HIR ty lowering's handling of struct expressions, and HIR typeck's handling of struct expressions - Try fix perf rust-lang/rust#149114 (comment). Maybe this will clear up once we clean up `ValTree` a bit and stop doing double interning and whatnot
Fix ICE in normalization during closure capture analysis (#149746) This fixes an internal compiler error that occurred when normalizing associated types during closure capture analysis. The Fix: Modified rustc_middle/src/ty/normalize_erasing_regions.rs to gracefully handle projection normalization failures instead of panicking when analyzing closure captures. Regression Test: Added tests/ui/associated-types/normalization-ice-issue-149746.rs, a reproduction case involving complex associated type projections (<() as Owner>::Ty<T>) that previously crashed the compiler. Verified it now emits a standard type error (E0277). Fixes rust-lang/rust#149746
Don't export upstream monomorphizations from compiler-builtins
Tidying up tests/ui/issues 15 tests [6/N] > [!NOTE] > Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge. part of rust-lang/rust#133895 r? Kivooeo
Update bors configuration Updates the configuration of bors to bring it up to speed with homu, in preparation for rust-lang/infra-team#168. Mirrors configuration from homu's [configuration file](https://github.com/rust-lang/homu/blob/master/cfg.production.toml#L46). This PR also enables reporting of merge conflicts, so that we can test this part of bors on `rust-lang/rust`. The merge conflict reports will be duplicated (until/unless we disable it in homu), but that hopefully shouldn't be such a big deal. r? ``@marcoieni``
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to rust-lang/rustc-dev-guide@1127d2a. Created using https://github.com/rust-lang/josh-sync. r? ``@ghost``
use new term in description of --target this changes _triple_ to _tuple_ in `--target` description
Rollup of 6 pull requests Successful merges: - rust-lang/rust#149800 (Fix ICE in normalization during closure capture analysis (rust-lang/rust#149746)) - rust-lang/rust#150182 (Don't export upstream monomorphizations from compiler-builtins) - rust-lang/rust#150216 (Tidying up tests/ui/issues 15 tests [6/N]) - rust-lang/rust#150308 (Update bors configuration) - rust-lang/rust#150314 (rustc-dev-guide subtree update) - rust-lang/rust#150319 (use new term in description of --target) r? `@ghost` `@rustbot` modify labels: rollup
Remap both absolute and relative paths when building `rustc` and `std` Turns out [#150110](rust-lang/rust#150110) didn't work as expected, because when the standard library sources are present, we [helpfully un-remap the paths](https://github.com/rust-lang/rust/blob/e951f470d76febcc6f0a5b409c509eb77450a336/compiler/rustc_metadata/src/rmeta/decoder.rs#L1656-L1702) to the local directory of the user, including when we are building the compiler and standard library it-self (duh!), and since those paths are absolute (not relative), our purely relative remapping didn't pick them up. This behavior wasn't a issue before because the un-remap logic immediately tries to remap them again, and since we had the absolute remapping we would just remap them to the the same thing. To fix that issue I've adjusted our remapping to remap both the absolute and relative paths when building `rustc` and `std`, as well as added a run-make to make sure we don't regress it again (with a new `needs-std-remap-debuginfo` directive). r? `@jieyouxu`
For some reason git-subtree incorrectly synced those changes.
Misc cleanups from reading some borrowck code title r? lcnr
Fix compile issue in Vita libstd Unfortunately it looks like the Vita libc does not support the "utimensat" function, which is needed for setting file times. To fix the build, this commit marks Vita as unsupported for the function that sets the file times.
Fix some divergences with the cg_clif subtree For some reason git-subtree incorrectly synced those changes. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
…uwer Rollup of 3 pull requests Successful merges: - rust-lang/rust#150141 (Misc cleanups from reading some borrowck code) - rust-lang/rust#150297 (Fix compile issue in Vita libstd) - rust-lang/rust#150341 (Fix some divergences with the cg_clif subtree) r? `@ghost` `@rustbot` modify labels: rollup
This version contains the 150313 rustc pull request.
This updates the rust-version file to e7d44143a12a526488e4f0c0d7ea8e62a4fe9354.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: e7d44143a12a526488e4f0c0d7ea8e62a4fe9354 Filtered ref: 604735b Upstream diff: rust-lang/rust@...e7d4414 This merge was created using https://github.com/rust-lang/josh-sync.
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 performs the first josh-sync pull. It pulls from rustc nightly-2025-12-25, which is commit rust-lang/rust@e7d4414, which contains rust-lang/rust#150341.
The last clif version synced with git subtree is 6f3f6bd, which was synced in rust-lang/rust#150313.