about summary refs log tree commit diff
AgeCommit message (Collapse)AuthorLines
2025-04-04Rollup merge of #139328 - GuillaumeGomez:fix-panic-output-137970, r=fmeaseMatthias Krüger-3/+39
Fix 2024 edition doctest panic output Fixes #137970. The problem was that the output was actually displayed by rustc itself because we're exiting with `Result<(), String>`, and the display is really not great. So instead, we get the output, we print it and then we return an `ExitCode`. r? ````@aDotInTheVoid````
2025-04-04Rollup merge of #139041 - nnethercote:rm-rustc_middle-ty-util-ExplicitSelf, ↵Matthias Krüger-62/+22
r=BoxyUwU Remove `rustc_middle::ty::util::ExplicitSelf`. It's an old (2017 or earlier) type that describes a `self` receiver. It's only used in `rustc_hir_analysis` for two error messages, and much of the complexity isn't used. I suspect it used to be used for more things. This commit removes it, and moves a greatly simplified version of the `determine` method into `rustc_hir_analysis`, renamed as `get_self_string`. The big comment on the method is removed because it no longer seems relevant. r? `@BoxyUwU`
2025-04-04Auto merge of #137869 - ↵bors-43/+46
Noratrieb:Now_I_am_become_death,_the_destroyer_of_i686-pc-windows-gnu, r=workingjubilee Demote i686-pc-windows-gnu to Tier 2 In accordance with [RFC 3771](https://github.com/rust-lang/rfcs/pull/3771). FCP has been completed. tracking issue #138422 I also added a stub doc page for the target and renamed the windows-gnullvm page for consistency.
2025-04-04Auto merge of #139213 - bjorn3:cg_clif_test_coretests, r=jieyouxubors-24/+35
Run coretests and alloctests with cg_clif in CI Part of https://github.com/rust-lang/rustc_codegen_cranelift/issues/1290
2025-04-04Auto merge of #139354 - matthiaskrgr:rollup-04lgx23, r=matthiaskrgrbors-407/+531
Rollup of 8 pull requests Successful merges: - #138949 (Rename `is_like_osx` to `is_like_darwin`) - #139295 (Remove creation of duplicate `AnonPipe`) - #139313 (Deduplicate some `rustc_middle` function bodies by calling the `rustc_type_ir` equivalent) - #139317 (compiletest: Encapsulate all of the code that touches libtest) - #139322 (Add helper function for checking LLD usage to `run-make-support`) - #139335 (Pass correct param-env to `error_implies`) - #139342 (Add a mailmap entry for myself) - #139349 (adt_destructor: sanity-check returned item) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-04Rollup merge of #139349 - meithecatte:destructor-constness, r=compiler-errorsMatthias Krüger-0/+33
adt_destructor: sanity-check returned item Fixes #139278
2025-04-04Rollup merge of #139342 - meithecatte:mailmap, r=compiler-errorsMatthias Krüger-0/+2
Add a mailmap entry for myself
2025-04-04Rollup merge of #139335 - compiler-errors:error-implies, r=oli-obkMatthias Krüger-29/+98
Pass correct param-env to `error_implies` Duplicated comment from the test: In the error reporting code, when reporting fulfillment errors for goals A and B, we try to see if elaborating A will result in another goal that can equate with B. That would signal that B is "implied by" A, allowing us to skip reporting it, which is beneficial for cutting down on the number of diagnostics we report. In the new trait solver especially, but even in the old trait solver through things like defining opaque type usages, this `can_equate` call was not properly taking the param-env of the goals, resulting in nested obligations that had empty param-envs. If one of these nested obligations was a `ConstParamHasTy` goal, then we would ICE, since those goals are particularly strict about the param-env they're evaluated in. This is morally a fix for <https://github.com/rust-lang/rust/issues/139314>, but that repro uses details about how defining usages in the `check_opaque_well_formed` code can spring out of type equality, and will likely stop failing soon coincidentally once we start using `PostBorrowck` mode in that check. Instead, we use lazy normalization to end up generating an alias-eq goal whose nested goals woul trigger the ICE instead, since this is a lot more stable. Fixes https://github.com/rust-lang/rust/issues/139314 r? ``@oli-obk`` or reassign
2025-04-04Rollup merge of #139322 - Kobzol:run-make-lld-refactor, r=jieyouxuMatthias Krüger-119/+69
Add helper function for checking LLD usage to `run-make-support` Extracted out of https://github.com/rust-lang/rust/pull/138645, should be a simple refactoring. r? ``@jieyouxu``
2025-04-04Rollup merge of #139317 - Zalathar:hide-libtest, r=jieyouxuMatthias Krüger-105/+208
compiletest: Encapsulate all of the code that touches libtest Compiletest currently relies on unstable libtest APIs in order to actually execute tests. That's unfortunate, but removing the dependency isn't trivial. However, we can make a small step towards removing the libtest dependency by encapsulating the libtest interactions into a single dedicated module. That makes it easier to see what parts of libtest are actually used. --- As a side-effect of moving the `test_opts` function into that dedicated module, this PR also ends up allowing `--fail-fast` to be passed on the command line, instead of requiring an environment variable. --- There is still (at least) one other aspect of the libtest dependency that this PR does not address, namely the fact that we rely on libtest's output capture (via unstable std APIs) to capture the output that we print during individual tests. I hope to do something about that at some point. r? jieyouxu
2025-04-04Rollup merge of #139313 - oli-obk:push-uzvmpxqyvrzp, r=compiler-errorsMatthias Krüger-99/+67
Deduplicate some `rustc_middle` function bodies by calling the `rustc_type_ir` equivalent Maybe in the future we can use method delegation, but I'd rather avoid that for now (I don't even know if it can do that already)
2025-04-04Rollup merge of #139295 - JakeWharton:jw.duplicate-anon-pipe.2025-04-02, ↵Matthias Krüger-1/+0
r=joboet Remove creation of duplicate `AnonPipe` The `File` is unwrapped to a `Handle` into an `AnonPipe`, and then that `AnonPipe` was unwrapped to a `Handle` into another `AnonPipe`. The second operation is entirely redundant.
2025-04-04Rollup merge of #138949 - madsmtm:rename-to-darwin, r=WaffleLapkinMatthias Krüger-54/+54
Rename `is_like_osx` to `is_like_darwin` Replace `is_like_osx` with `is_like_darwin`, which more closely describes reality (OS X is the pre-2016 name for macOS, and is by now quite outdated; Darwin is the overall name for the OS underlying Apple's macOS, iOS, etc.). ``@rustbot`` label O-apple r? compiler
2025-04-04Auto merge of #139287 - compiler-errors:folder-experiment-1, r=lqdbors-11/+42
Folder experiment: Monomorphize region resolver **NOTE:** This is one of a series of perf experiments that I've come up with while sick in bed. I'm assigning them to lqd b/c you're a good reviewer and you'll hopefully be awake when these experiments finish, lol. r? lqd This is actually two tweaks to the `RegionFolder`, monomorphizing its callback and accounting for flags to avoid folding unnecessarily.
2025-04-04adt_destructor: sanity-check returned itemMaja Kądziołka-0/+33
Fixes #139278
2025-04-04Auto merge of #120706 - Bryanskiy:leak, r=lcnrbors-85/+829
Initial support for auto traits with default bounds This PR is part of ["MCP: Low level components for async drop"](https://github.com/rust-lang/compiler-team/issues/727) Tracking issue: #138781 Summary: https://github.com/rust-lang/rust/pull/120706#issuecomment-1934006762 ### Intro Sometimes we want to use type system to express specific behavior and provide safety guarantees. This behavior can be specified by various "marker" traits. For example, we use `Send` and `Sync` to keep track of which types are thread safe. As the language develops, there are more problems that could be solved by adding new marker traits: - to forbid types with an async destructor to be dropped in a synchronous context a trait like `SyncDrop` could be used [Async destructors, async genericity and completion futures](https://sabrinajewson.org/blog/async-drop). - to support [scoped tasks](https://without.boats/blog/the-scoped-task-trilemma/) or in a more general sense to provide a [destruction guarantee](https://zetanumbers.github.io/book/myosotis.html) there is a desire among some users to see a `Leak` (or `Forget`) trait. - Withoutboats in his [post](https://without.boats/blog/changing-the-rules-of-rust/) reflected on the use of `Move` trait instead of a `Pin`. All the traits proposed above are supposed to be auto traits implemented for most types, and usually implemented automatically by compiler. For backward compatibility these traits have to be added implicitly to all bound lists in old code (see below). Adding new default bounds involves many difficulties: many standard library interfaces may need to opt out of those default bounds, and therefore be infected with confusing `?Trait` syntax, migration to a new edition may contain backward compatibility holes, supporting new traits in the compiler can be quite difficult and so forth. Anyway, it's hard to evaluate the complexity until we try the system on a practice. In this PR we introduce new optional lang items for traits that are added to all bound lists by default, similarly to existing `Sized`. The examples of such traits could be `Leak`, `Move`, `SyncDrop` or something else, it doesn't matter much right now (further I will call them `DefaultAutoTrait`'s). We want to land this change into rustc under an option, so it becomes available in bootstrap compiler. Then we'll be able to do standard library experiments with the aforementioned traits without adding hundreds of `#[cfg(not(bootstrap))]`s. Based on the experiments, we can come up with some scheme for the next edition, in which such bounds are added in a more targeted way, and not just everywhere. Most of the implementation is basically a refactoring that replaces hardcoded uses of `Sized` with iterating over a list of traits including both `Sized` and the new traits when `-Zexperimental-default-bounds` is enabled (or just `Sized` as before, if the option is not enabled). ### Default bounds for old editions All existing types, including generic parameters, are considered `Leak`/`Move`/`SyncDrop` and can be forgotten, moved or destroyed in generic contexts without specifying any bounds. New types that cannot be, for example, forgotten and do not implement `Leak` can be added at some point, and they should not be usable in such generic contexts in existing code. To both maintain this property and keep backward compatibility with existing code, the new traits should be added as default bounds _everywhere_ in previous editions. Besides the implicit `Sized` bound contexts that includes supertrait lists and trait lists in trait objects (`dyn Trait1 + ... + TraitN`). Compiler should also generate implicit `DefaultAutoTrait` implementations for foreign types (`extern { type Foo; }`) because they are also currently usable in generic contexts without any bounds. #### Supertraits Adding the new traits as supertraits to all existing traits is potentially necessary, because, for example, using a `Self` param in a trait's associated item may be a breaking change otherwise: ```rust trait Foo: Sized { fn new() -> Option<Self>; // ERROR: `Option` requires `DefaultAutoTrait`, but `Self` is not `DefaultAutoTrait` } // desugared `Option` enum Option<T: DefaultAutoTrait + Sized> { Some(T), None, } ``` However, default supertraits can significantly affect compiler performance. For example, if we know that `T: Trait`, the compiler would deduce that `T: DefaultAutoTrait`. It also implies proving `F: DefaultAutoTrait` for each field `F` of type `T` until an explicit impl is be provided. If the standard library is not modified, then even traits like `Copy` or `Send` would get these supertraits. In this PR for optimization purposes instead of adding default supertraits, bounds are added to the associated items: ```rust // Default bounds are generated in the following way: trait Trait { fn foo(&self) where Self: DefaultAutoTrait {} } // instead of this: trait Trait: DefaultAutoTrait { fn foo(&self) {} } ``` It is not always possible to do this optimization because of backward compatibility: ```rust pub trait Trait<Rhs = Self> {} pub trait Trait1 : Trait {} // ERROR: `Rhs` requires `DefaultAutoTrait`, but `Self` is not `DefaultAutoTrait` ``` or ```rust trait Trait { type Type where Self: Sized; } trait Trait2<T> : Trait<Type = T> {} // ERROR: `???` requires `DefaultAutoTrait`, but `Self` is not `DefaultAutoTrait` ``` Therefore, `DefaultAutoTrait`'s are still being added to supertraits if the `Self` params or type bindings were found in the trait header. #### Trait objects Trait objects requires explicit `+ Trait` bound to implement corresponding trait which is not backward compatible: ```rust fn use_trait_object(x: Box<dyn Trait>) { foo(x) // ERROR: `foo` requires `DefaultAutoTrait`, but `dyn Trait` is not `DefaultAutoTrait` } // implicit T: DefaultAutoTrait here fn foo<T>(_: T) {} ``` So, for a trait object `dyn Trait` we should add an implicit bound `dyn Trait + DefaultAutoTrait` to make it usable, and allow relaxing it with a question mark syntax `dyn Trait + ?DefaultAutoTrait` when it's not necessary. #### Foreign types If compiler doesn't generate auto trait implementations for a foreign type, then it's a breaking change if the default bounds are added everywhere else: ```rust // implicit T: DefaultAutoTrait here fn foo<T: ?Sized>(_: &T) {} extern "C" { type ExternTy; } fn forward_extern_ty(x: &ExternTy) { foo(x); // ERROR: `foo` requires `DefaultAutoTrait`, but `ExternTy` is not `DefaultAutoTrait` } ``` We'll have to enable implicit `DefaultAutoTrait` implementations for foreign types at least for previous editions: ```rust // implicit T: DefaultAutoTrait here fn foo<T: ?Sized>(_: &T) {} extern "C" { type ExternTy; } impl DefaultAutoTrait for ExternTy {} // implicit impl fn forward_extern_ty(x: &ExternTy) { foo(x); // OK } ``` ### Unresolved questions New default bounds affect all existing Rust code complicating an already complex type system. - Proving an auto trait predicate requires recursively traversing the type and proving the predicate for it's fields. This leads to a significant performance regression. Measurements for the stage 2 compiler build show up to 3x regression. - We hope that fast path optimizations for well known traits could mitigate such regressions at least partially. - New default bounds trigger some compiler bugs in both old and new trait solver. - With new default bounds we encounter some trait solver cycle errors that break existing code. - We hope that these cases are bugs that can be addressed in the new trait solver. Also migration to a new edition could be quite ugly and enormous, but that's actually what we want to solve. For other issues there's a chance that they could be solved by a new solver.
2025-04-04Add a mailmap entry for myselfMaja Kądziołka-0/+2
2025-04-03Auto merge of #139336 - matthiaskrgr:rollup-zsi8pgf, r=matthiaskrgrbors-598/+806
Rollup of 9 pull requests Successful merges: - #138017 (Tighten up assignment operator representations.) - #138462 (Dedup `&mut *` reborrow suggestion in loops) - #138610 (impl !PartialOrd for HirId) - #138767 (Allow boolean literals in `check-cfg`) - #139068 (io: Avoid marking some bytes as uninit) - #139255 (Remove unused variables generated in merged doctests) - #139270 (Add a mailmap entry for myself) - #139303 (Put Noratrieb on vacation) - #139312 (add Marco Ieni to mailmap) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-03Rollup merge of #139312 - marcoieni:marco-mailmap, r=KobzolMatthias Krüger-0/+1
add Marco Ieni to mailmap
2025-04-03Rollup merge of #139303 - Noratrieb:Noratrieb-patch-3, r=NoratriebMatthias Krüger-0/+1
Put Noratrieb on vacation My review queue has gotten a bit out of hand. I'll work on reviewing those PRs before taking up new ones.
2025-04-03Rollup merge of #139270 - RossSmyth:mailmap, r=NoratriebMatthias Krüger-1/+4
Add a mailmap entry for myself Turns out I have not been at all consistent. Oops.
2025-04-03Rollup merge of #139255 - GuillaumeGomez:unused-var-merged-doctest, r=fmeaseMatthias Krüger-1/+0
Remove unused variables generated in merged doctests The variable is unused so no need to keep it around. cc `@notriddle` r? `@camelid`
2025-04-03Rollup merge of #139068 - a1phyr:less_uninit, r=joboetMatthias Krüger-2/+4
io: Avoid marking some bytes as uninit These bytes were marked as uninit, which would cause them to be initialized multiple times even though it was not necessary.
2025-04-03Rollup merge of #138767 - clubby789:check-cfg-bool, r=UrgauMatthias Krüger-24/+31
Allow boolean literals in `check-cfg` https://github.com/rust-lang/rust/pull/138632#issuecomment-2738114495 This makes it consistent with `--cfg` We could alternatively add a forward-compatible lint against `--cfg true/false` r? `@Urgau`
2025-04-03Rollup merge of #138610 - oli-obk:no-sort-hir-ids, r=compiler-errorsMatthias Krüger-240/+295
impl !PartialOrd for HirId revive of https://github.com/rust-lang/rust/pull/92233 Another checkbox of https://github.com/rust-lang/rust/issues/90317, another small step in making incremental less likely to die in horrible ways
2025-04-03Rollup merge of #138462 - ShE3py:mut-borrow-in-loop, r=oli-obkMatthias Krüger-17/+0
Dedup `&mut *` reborrow suggestion in loops #73534 added a reborrow suggestion in loops; #127579 generalized this to generic parameters, making the suggestion triggers twice: ```rs use std::io::Read; fn decode_scalar(_reader: impl Read) {} fn decode_array(reader: &mut impl Read) { for _ in 0.. { decode_scalar(reader); } } ``` ``` error[E0382]: use of moved value: `reader` --> src/lib.rs:6:23 | 4 | fn decode_array(reader: &mut impl Read) { | ------ move occurs because `reader` has type `&mut impl Read`, which does not implement the `Copy` trait 5 | for _ in 0.. { | ------------ inside of this loop 6 | decode_scalar(reader); | ^^^^^^ value moved here, in previous iteration of loop | help: consider creating a fresh reborrow of `reader` here | 6 | decode_scalar(&mut *reader); | ++++++ help: consider creating a fresh reborrow of `reader` here | 6 | decode_scalar(&mut *reader); | ++++++ ``` This PR removes the suggestion in loops, as it requires generic parameters anyway (i.e., the reborrow is automatic if there is no generic params). `@rustbot` label +A-borrow-checker +A-diagnostics +A-suggestion-diagnostics +D-papercut
2025-04-03Rollup merge of #138017 - nnethercote:tighten-assignment-op, r=spastorinoMatthias Krüger-313/+470
Tighten up assignment operator representations. This is step 3 of [MCP 831](https://github.com/rust-lang/compiler-team/issues/831). r? `@spastorino`
2025-04-03Auto merge of #132527 - DianQK:gvn-stmt-iter, r=oli-obkbors-573/+566
gvn: Invalid dereferences for all non-local mutations Fixes #132353. This PR removes the computation value by traversing SSA locals through `for_each_assignment_mut`. Because the `for_each_assignment_mut` traversal skips statements which have side effects, such as dereference assignments, the computation may be unsound. Instead of `for_each_assignment_mut`, we compute values by traversing in reverse postorder. Because we compute and use the symbolic representation of values on the fly, I invalidate all old values when encountering a dereference assignment. The current approach does not prevent the optimization of a clone to a copy. In the future, we may add an alias model, or dominance information for dereference assignments, or SSA form to help GVN. r? cjgillot cc `@jieyouxu` #132356 cc `@RalfJung` #133474
2025-04-03Pass correct param-env to error_impliesMichael Goulet-29/+98
2025-04-03Use `eprint!` instead of `eprintln!`Guillaume Gomez-33/+23
2025-04-03Deduplicate some `rustc_middle` function bodies by calling the ↵Oli Scherer-99/+67
`rustc_type_ir` equivalent
2025-04-03Auto merge of #139301 - matthiaskrgr:rollup-sa6ali8, r=matthiaskrgrbors-506/+737
Rollup of 7 pull requests Successful merges: - #139080 (Experimental feature gate for `super let`) - #139145 (slice: Remove some uses of unsafe in first/last chunk methods) - #139149 (unstable book: document import_trait_associated_functions) - #139273 (Apply requested API changes to `cell_update`) - #139282 (rustdoc: make settings checkboxes always square) - #139283 (Rustc dev guide subtree update) - #139294 (Fix the `f16`/`f128` feature gates on integer literals) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-03Fix testing with randomized layouts enabledbjorn3-2/+3
2025-04-03Add regression test for #137970Guillaume Gomez-0/+44
2025-04-03Fix 2024 edition doctest panic outputGuillaume Gomez-3/+5
2025-04-03Invalid dereferences for all non-local mutationsdianqk-36/+75
2025-04-03Only preserving derefs for trivial terminators like SwitchInt and Gotodianqk-2/+8
2025-04-03Remove `unsound-mir-opts` for `simplify_aggregate_to_copy`dianqk-71/+65
2025-04-03Move `link-self-contained-consistency` test to a more reasonable locationJakub Beránek-1/+1
2025-04-03Add a helper function for checking if LLD was used to `run-make-support`Jakub Beránek-118/+68
2025-04-03compiletest: Encapsulate all of the code that touches libtestZalathar-98/+194
2025-04-03Run coretests and alloctests with cg_clif in CIbjorn3-22/+28
2025-04-03Auto merge of #139137 - petrochenkov:errwhere2, r=jieyouxubors-533/+681
compiletest: Require `//~` annotations even if `error-pattern` is specified This is continuation of #138865 with some help from #139100. `error-pattern` annotations that duplicate the newly added `//~` annotations are removed, other `error-pattern`s are not touched yet. In exceptional cases `//@ compile-flags: --error-format=human` can be used to opt out of these checks. In this PR I only had to use the opt out 3 times: - `tests/ui/parser/utf16-{be,le}-without-bom.rs` - there are too many errors that are nearly identical (modulo location), because an error is reported on every second symbol - `tests/ui-fulldeps/missing-rustc-driver-error.rs` - the errors list various rustc crate dependencies and may unexpectedly invalidate on random rustc changes
2025-04-03Initial support for auto traits with default boundsBryanskiy-85/+829
2025-04-03compiletest: Allow `--fail-fast` as a command-line optionZalathar-8/+15
2025-04-03add Marco Ieni to mailmapMarcoIeni-0/+1
2025-04-03Allow boolean literals in `check-cfg`clubby789-24/+31
2025-04-03impl !PartialOrd for HirIdOli Scherer-32/+44
2025-04-03impl !PartialOrd for UpvarMigrationInfoOli Scherer-3/+8
2025-04-03Upvars HirIds always have the same owner, thus just use an ItemLocalIdOli Scherer-3/+7