| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Temporarily bring back `Rvalue::Len`
r? `@compiler-errors` as requested in https://github.com/rust-lang/rust/issues/135671#issuecomment-2599580364
> However, in the mean time, I'd rather we not crunch trying to find and more importantly validate the soundness of a solution 🤔
Agreed. To fix the IMO P-critical #135671 for which we somehow didn't have test coverage, this PR temporarily reverts:
- https://github.com/rust-lang/rust/pull/133734
- its bugfix https://github.com/rust-lang/rust/pull/134371
- https://github.com/rust-lang/rust/pull/134330
cc `@scottmcm`
I added the few samples from that issue as a test, but we can add more in the future, in particular it seems `@steffahn` [will work on that](https://github.com/rust-lang/rust/issues/135671#issuecomment-2599714354).
Fixes #135671. And if we want to land this, it should also be nominated for beta backport.
|
|
Rollup of 4 pull requests
Successful merges:
- #135641 ([rustdoc] Replace module list items `ul`/`li` with `dl`/`dd`/`dt` elements)
- #135703 (Disallow `A { .. }` if `A` has no fields)
- #135705 (Consolidate ad-hoc MIR lints into real pass-manager-based MIR lints)
- #135708 (Some random compiler nits)
Failed merges:
- #135685 (Remove unused `item-row` CSS class)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Get rid of `ToPolyTraitRef`
It's generally a footgun, since it throws away `PredicatePolarity`.
This PR doesn't attempt to fix any related bugs having to do with binders or polarity; it just tries to pass through `TraitPredicate`s around instead of `TraitRef`s. There should be basically no functional changes.
|
|
r=davidtwco,RalfJung"
This reverts commit b57d93d8b9525fa261404b4cd9c0670eeb1264b8, reversing
changes made to 0aeaa5eb22180fdf12a8489e63c4daa18da6f236.
|
|
This reverts commit e108481f74ff123ad98a63bd107a18d13035b275, reversing
changes made to 303e8bd768526a5812bb1776e798e829ddb7d3ca.
|
|
|
|
|
|
Making these separate types from `CovTerm` and `Expression` was historically
very helpful, but now that most of the counter-creation work is handled by
`node_flow` they are no longer needed.
|
|
Add gpu-kernel calling convention
The amdgpu-kernel calling convention was reverted in commit f6b21e90d1ec01081bc2619efb68af6788a63d65 (#120495 and https://github.com/rust-lang/rust-analyzer/pull/16463) due to inactivity in the amdgpu target.
Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for.
Tracking issue: #135467
amdgpu target tracking issue: #135024
|
|
Rollup of 7 pull requests
Successful merges:
- #134754 (Implement `use` associated items of traits)
- #135481 (coverage: Completely overhaul counter assignment, using node-flow graphs)
- #135504 (Allow coercing safe-to-call target_feature functions to safe fn pointers)
- #135561 (Update docs for `-Clink-dead-code` to discourage its use)
- #135574 (ci: mirror ubuntu:22.04 to ghcr.io)
- #135585 (resolve symlinks of LLVM tool binaries before copying them)
- #135588 (Add license-metadata.json to rustc-src tarball.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use trait definition cycle detection for trait alias definitions, too
fixes #133901
In general doing this for `All` is not right, but this code path is specifically for traits and trait aliases, and there we only ever use `All` for trait aliases.
|
|
Allow coercing safe-to-call target_feature functions to safe fn pointers
r? oli-obk
`@oli-obk:` this is based on your PR #134353 :-)
See https://github.com/rust-lang/rust/pull/134090#issuecomment-2539422624 for the motivation behind this change.
|
|
|
|
The amdgpu-kernel calling convention was reverted in commit
f6b21e90d1ec01081bc2619efb68af6788a63d65 due to inactivity in the amdgpu
target.
Introduce a `gpu-kernel` calling convention that translates to
`ptx_kernel` or `amdgpu_kernel`, depending on the target that rust
compiles for.
|
|
r=davidtwco
deprecate `std::intrinsics::transmute` etc, use `std::mem::*` instead
The `rustc_allowed_through_unstable_modules` attribute lets users call `std::mem::transmute` as `std::intrinsics::transmute`. The former is a reexport of the latter, and for a long time we didn't properly check stability for reexports, so making this a hard error now would be a breaking change for little gain. But at the same time, `std::intrinsics::transmute` is not the intended path for this function, so I think it is a good idea to show a deprecation warning when that path is used. This PR implements that, for all the functions in `std::intrinsics` that carry the attribute.
I assume this will need ``@rust-lang/libs-api`` FCP.
|
|
r=wesleywiser
Treat safe target_feature functions as unsafe by default [less invasive variant]
This unblocks
* #134090
As I stated in https://github.com/rust-lang/rust/pull/134090#issuecomment-2541332415 I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions.
This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
|
|
|
|
|
|
|
|
Exclude dependencies of `std` for diagnostics
Currently crates in the sysroot can show up in diagnostic suggestions, such as in https://github.com/rust-lang/rust/issues/135232. To prevent this, duplicate `all_traits` into `visible_traits` which only shows traits in non-private crates.
Setting `#![feature(rustc_private)]` overrides this and makes items in private crates visible as well, since `rustc_private` enables use of `std`'s private dependencies.
This may be reviewed per-commit.
Fixes: https://github.com/rust-lang/rust/issues/135232
|
|
|
|
Add an alternative to `tcx.all_traits()` that only shows traits that the
user might be able to use, for diagnostic purposes. With this available,
make use of it for diagnostics including associated type errors, which
is part of the problem with [1].
Includes a few comment updates for related API.
[1]: https://github.com/rust-lang/rust/issues/135232
|
|
Really this is always-visible override only needs to happen when the
crate is a dependency of itself. However, this is a very internal
feature, so it doesn't seem worth doing any additional filtering here.
|
|
Remove code duplication when hashing query result and interning node
Refactored the duplicated code into a function.
`with_feed_task` currently passes the query key to `debug_assert!`. I believe that's a mistake, since `with_task` prints the `DepNode` which is more sensible, so this commit changes that, so it debug prints the `DepNode`.
|
|
Rollup of 10 pull requests
Successful merges:
- #134498 (Fix cycle error only occurring with -Zdump-mir)
- #134977 (Detect `mut arg: &Ty` meant to be `arg: &mut Ty` and provide structured suggestion)
- #135390 (Re-added regression test for #122638)
- #135393 (uefi: helpers: Introduce OwnedDevicePath)
- #135440 (rm unnecessary `OpaqueTypeDecl` wrapper)
- #135441 (Make sure to mark `IMPL_TRAIT_REDUNDANT_CAPTURES` as `Allow` in edition 2024)
- #135444 (Update books)
- #135450 (Fix emscripten-wasm-eh with unwind=abort)
- #135452 (bootstrap: fix outdated feature name in comment)
- #135454 (llvm: Allow sized-word rather than ymmword in tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix cycle error only occurring with -Zdump-mir
fixes #134205
During mir dumping, we evaluate static items to render their allocations. If a static item refers to itself, its own MIR will have a reference to itself, so during mir dumping we end up evaluating the static again, causing us to try to build MIR again (mir dumping happens during MIR building).
Thus I disabled evaluation of statics during MIR dumps in case the MIR body isn't far enough along yet to be able to be guaranteed cycle free.
|
|
Refactored the duplicated code into a function.
`with_feed_task` currently passes the query key to `debug_assert!`.
This commit changes that, so it debug prints the `DepNode`, as in
`with_task`.
|
|
Assert that `Instance::try_resolve` is only used on body-like things
`Instance::resolve` is not set up to resolve items that are not body-like things. The logic in `resolve_associated_item` very much encodes this assumption:
https://github.com/rust-lang/rust/blob/e7ad3ae331bf2716389c10e01612e201a7f98c8d/compiler/rustc_ty_utils/src/instance.rs#L96-L386
However, some diagnostics were using `Instance::resolve` on an associated type, and it was simply a lucky coicidence that nothing went wrong.
This PR adds an assertion to make sure we won't do this again in the future, and fixes two callsites:
1. `call_kind` which returns a `CallKind` enum to categorize what a call in MIR comes from, and was using `Instance::resolve` to point at the associated type `Deref::Target` for a specific self ty.
2. `MirBorrowckCtxt::explain_deref_coercion`, which was doing the same thing.
The logic was replaced with `specialization_graph::assoc_def`, which is the proper way of fetching the right `AssocItem` for a given impl.
r? `@lcnr` or re-roll :)
|
|
Depth limit const eval query
Currently the const-eval query doesn't have a recursion limit or timeout, causing the complier to freeze in an infinite loop, see #125718. This PR depth limits the `eval_to_const_value_raw` query (with the [`recursion_limit`](https://doc.rust-lang.org/reference/attributes/limits.html) attribute) and improves the diagnostics for query overflow errors, so spans are reported for other dep kinds than `layout_of` (e.g. `eval_to_const_value_raw`).
fixes #125718
fixes #114192
|
|
|
|
De-abstract tagged ptr and make it covariant
In #135272 I needed to use a tagged ptr in `hir::TyKind` in order to not regress hir type sizes. Unfortunately the existing `CopyTaggedPtr` abstraction is insufficient as it makes the `'hir` lifetime invariant.
I spent some time trying to keep existing functionality while making it covariant but in the end I realised that actually we dont use *any* of this code *anywhere* in rustc, so I've just removed everything and replaced it with a much less general abstraction that is suitable for what I need in #135272.
Idk if anyone has a preference for just keeping all the abstractions here in case anyone needs them in the future :woman_shrugging:
|
|
|
|
Remove a bunch of diagnostic stashing that doesn't do anything
#121669 removed a bunch of conditional diagnostic stashing/canceling, but left around the `steal` calls which just emitted the error eagerly instead of canceling the diagnostic. I think that these no-op `steal` calls don't do much and are confusing to encounter, so let's remove them.
The net effect is:
1. We emit more duplicated errors, since stashing has the side effect of duplicating diagnostics. This is not a big deal, since outside of `-Zdeduplicate-diagnostics=no`, the errors are already being deduplicated by the compiler.
2. It changes the order of diagnostics, since we're no longer stashing and then later stealing the errors. I don't think this matters much for the changes that the UI test suite manifests, and it makes these errors less order dependent.
|
|
|
|
Eagerly collect mono items for non-generic closures
This allows users to use `-Zprint-mono-items=eager` to eagerly monomorphize closures and coroutine bodies, in case they want to inspect the LLVM or ASM for those items.
`-Zprint-mono-items`, which used to be called `-Zprint-trans-items`, was originally added in https://github.com/rust-lang/rust/pull/30900:
> Eager mode is meant to be used in conjunction with incremental compilation
> where a stable set of translation items is more important than a minimal
> one. Thus, eager mode will instantiate drop-glue for every drop-able type
> in the crate, even of no drop call for that type exists (yet). It will
> also instantiate default implementations of trait methods, something that
> otherwise is only done on demand.
Although it remains an unstable option, its purpose has somewhat expanded since then, and as far as I can tell it's generally useful for cases when you want to monomorphize as many items as possible, even if they're unreachable. Specifically, it's useful for debugging since you can look at the codegen'd body of a function, since we don't emit items that are not reachable in monomorphization.
And even more specifically, it would be very to monomorphize the coroutine body of an async fn, since those you can't easily call those without a runtime. This PR enables this usecase since we now monomorphize `DefKind::Closure`.
|
|
This should make it clearer that this bitset is dense, with the
advantages and disadvantages that it entails.
|
|
Adds `#[rustc_force_inline]` which is similar to always inlining but
reports an error if the inlining was not possible, and which always
attempts to inline annotated items, regardless of optimisation levels.
It can only be applied to free functions to guarantee that the MIR
inliner will be able to resolve calls.
|
|
|
|
`-Zrandomize-layout` harder. `Foo<T> != Foo<U>`
Tracking issue: #106764
Previously randomize-layout only used a deterministic shuffle based on the seed stored in an Adt's ReprOptions, meaning that `Foo<T>` and `Foo<U>` were shuffled by the same seed. This change adds a similar seed to each calculated LayoutData so that a struct can be randomized both based on the layout of its fields and its per-type seed.
Primitives start with simple seed derived from some of their properties. Though some types can no longer be distinguished at that point, e.g. usize and u64 will still be treated the same.
|
|
|
|
previously field ordering was using the same seed for all instances of Foo,
now we pass seed values through the layout tree so that not only
the struct itself affects layout but also its fields
|
|
r=oli-obk
Account for identity substituted items in symbol mangling
See the inline comment.
r? oli-obk
Fixes #135235
|
|
|
|
`Ty::new` wasn't used anywhere outside this module
`Ty::new_adt` shouldn't ever be used for anything but adts. This hasn't caught any bugs, but seems good to check anyway
|
|
|
|
|
|
Implement `const Destruct` in old solver
Self-explanatory. Not totally settled that this is the best structure for built-in trait impls for effect goals in the new solver, but it's almost certainly the simplest.
r? lcnr or re-roll
|
|
Suggest Replacing Comma with Semicolon in Incorrect Repeat Expressions
Fixes #80173
This PR detects typos in repeat expressions like `["_", 10]` and `vec![String::new(), 10]` and suggests replacing comma with semicolon.
Also, improves code in other place by adding doc comments and making use of a helper function to check if a type implements `Clone`.
References:
1. For `vec![T; N]`: https://doc.rust-lang.org/std/macro.vec.html
2. For `[T; N]`: https://doc.rust-lang.org/std/primitive.array.html
|
|
|
|
Exhaustively handle expressions in patterns
We currently have this invariant in HIR that a `PatKind::Lit` or a `PatKind::Range` only contains
* `ExprKind::Lit`
* `ExprKind::UnOp(Neg, ExprKind::Lit)`
* `ExprKind::Path`
* `ExprKind::ConstBlock`
So I made `PatKind::Lit` and `PatKind::Range` stop containing `Expr`, and instead created a `PatLit` type whose `kind` enum only contains those variants.
The only place code got more complicated was in clippy, as it couldn't share as much anymore with `Expr` handling
It may be interesting on merging `ExprKind::{Path,Lit,ConstBlock}` in the future and using the same `PatLit` type (under a new name).
Then it should also be easier to eliminate any and all `UnOp(Neg, Lit) | Lit` matching that we have across the compiler. Some day we should fold the negation into the literal itself and just store it on the numeric literals
|
