2745 Commits

Author SHA1 Message Date
Michael Goulet
b02eac37ff Restrict bevy hack 2025-02-19 03:58:31 +00:00
Matthias Krüger
a66ef2f40e
Rollup merge of #137206 - estebank:e0599-structured, r=jieyouxu
Make E0599 a structured error
2025-02-18 18:40:54 +01:00
Matthias Krüger
c8d904125e
Rollup merge of #137000 - compiler-errors:deeply-normalize-item-bounds, r=lcnr
Deeply normalize item bounds in new solver

Built on #136863.

Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/142.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/151.

cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/116

First commit reworks candidate preference for projection bounds to prefer param-env projection clauses even if the corresponding trait ref doesn't come from the param-env.

Second commit adjusts the associated type item bounds check to deeply normalize in the new solver. This causes some test fallout which I will point out.

r? lcnr
2025-02-18 18:40:51 +01:00
Esteban Küber
693f7035f1 Make E0599 a structured error 2025-02-18 04:50:33 +00:00
Nicholas Nethercote
fd7b4bf4e1 Move methods from Map to TyCtxt, part 2.
Continuing the work started in #136466.

Every method gains a `hir_` prefix, though for the ones that already
have a `par_` or `try_par_` prefix I added the `hir_` after that.
2025-02-18 10:17:44 +11:00
Michael Goulet
b002b5cc82 Deeply normalize associated type bounds before proving them 2025-02-17 17:21:24 +00:00
bors
2162e9d4b1 Auto merge of #137164 - matthiaskrgr:rollup-dj5826k, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #137095 (Replace some u64 hashes with Hash64)
 - #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses)
 - #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.)
 - #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows)
 - #137125 (Re-add missing empty lines in the releases notes)
 - #137145 (use add-core-stubs / minicore for a few more tests)
 - #137149 (Remove SSE ABI from i586-pc-windows-msvc)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-17 11:18:33 +00:00
Nicholas Nethercote
661f99ba03 Overhaul the intravisit::Map trait.
First of all, note that `Map` has three different relevant meanings.
- The `intravisit::Map` trait.
- The `map::Map` struct.
- The `NestedFilter::Map` associated type.

The `intravisit::Map` trait is impl'd twice.
- For `!`, where the methods are all unreachable.
- For `map::Map`, which gets HIR stuff from the `TyCtxt`.

As part of getting rid of `map::Map`, this commit changes `impl
intravisit::Map for map::Map` to `impl intravisit::Map for TyCtxt`. It's
fairly straightforward except various things are renamed, because the
existing names would no longer have made sense.

- `trait intravisit::Map` becomes `trait intravisit::HirTyCtxt`, so named
  because it gets some HIR stuff from a `TyCtxt`.
- `NestedFilter::Map` assoc type becomes `NestedFilter::MaybeTyCtxt`,
  because it's always `!` or `TyCtxt`.
- `Visitor::nested_visit_map` becomes `Visitor::maybe_tcx`.

I deliberately made the new trait and associated type names different to
avoid the old `type Map: Map` situation, which I found confusing. We now
have `type MaybeTyCtxt: HirTyCtxt`.
2025-02-17 13:21:35 +11:00
Nicholas Nethercote
f86f7ad5f2 Move some Map methods onto TyCtxt.
The end goal is to eliminate `Map` altogether.

I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
2025-02-17 13:21:02 +11:00
León Orell Valerian Liehr
84bdc5de6e
HIR analysis: Remove unnecessary abstraction over list of clauses 2025-02-15 23:54:53 +01:00
bors
c241e14650 Auto merge of #136593 - lukas-code:ty-value-perf, r=oli-obk
valtree performance tuning

Summary: This PR makes type checking of code with many type-level constants faster.

After https://github.com/rust-lang/rust/pull/136180 was merged, we observed a small perf regression (https://github.com/rust-lang/rust/pull/136318#issuecomment-2635562821). This happened because that PR introduced additional copies in the fast reject code path for consts, which is very hot for certain crates: 6c1d960d88/compiler/rustc_type_ir/src/fast_reject.rs (L486-L487)

This PR improves the performance again by properly interning the valtrees so that copying and comparing them becomes faster. This will become especially useful with `feature(adt_const_params)`, so the fast reject code doesn't have to do a deep compare of the valtrees.

Note that we can't just compare the interned consts themselves in the fast reject, because sometimes `'static` lifetimes in the type are be replaced with inference variables (due to canonicalization) on one side but not the other.

A less invasive alternative that I considered is simply avoiding copies introduced by https://github.com/rust-lang/rust/pull/136180 and comparing the valtrees it in-place (see commit: 9e91e50ac5 / perf results: https://github.com/rust-lang/rust/pull/136593#issuecomment-2642303245), however that was still measurably slower than interning.

There are some minor regressions in secondary benchmarks: These happen due to changes in memory allocations and seem acceptable to me. The crates that make heavy use of valtrees show no significant changes in memory usage.
2025-02-13 15:27:30 +00:00
bors
54cdc751df Auto merge of #136965 - jhpratt:rollup-bsnqvmf, r=jhpratt
Rollup of 8 pull requests

Successful merges:

 - #134999 (Add cygwin target.)
 - #136559 (Resolve named regions when reporting type test failures in NLL)
 - #136660 (Use a trait to enforce field validity for union fields + `unsafe` fields + `unsafe<>` binder types)
 - #136858 (Parallel-compiler-related cleanup)
 - #136881 (cg_llvm: Reduce visibility of all functions in the llvm module)
 - #136888 (Always perform discr read for never pattern in EUV)
 - #136948 (Split out the `extern_system_varargs` feature)
 - #136949 (Fix import in bench for wasm)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-13 11:45:11 +00:00
Jacob Pratt
36d37966df
Rollup merge of #136948 - workingjubilee:split-off-extern-system-varargs, r=compiler-errors
Split out the `extern_system_varargs` feature

After the stabilization PR was opened, `extern "system"` functions were added to `extended_varargs_abi_support`. This has a number of questions regarding it that were not discussed and were somewhat surprising. It deserves to be considered as its own feature, separate from `extended_varargs_abi_support`.

Tracking issue:
- https://github.com/rust-lang/rust/issues/136946
2025-02-13 03:53:32 -05:00
Jacob Pratt
4ea261018a
Rollup merge of #136660 - compiler-errors:BikeshedGuaranteedNoDrop, r=lcnr
Use a trait to enforce field validity for union fields + `unsafe` fields + `unsafe<>` binder types

This PR introduces a new, internal-only trait called `BikeshedGuaranteedNoDrop`[^1] to faithfully model the field check that used to be implemented manually by `allowed_union_or_unsafe_field`.

942db6782f/compiler/rustc_hir_analysis/src/check/check.rs (L84-L115)

Copying over the doc comment from the trait:

```rust
/// Marker trait for the types that are allowed in union fields, unsafe fields,
/// and unsafe binder types.
///
/// Implemented for:
/// * `&T`, `&mut T` for all `T`,
/// * `ManuallyDrop<T>` for all `T`,
/// * tuples and arrays whose elements implement `BikeshedGuaranteedNoDrop`,
/// * or otherwise, all types that are `Copy`.
///
/// Notably, this doesn't include all trivially-destructible types for semver
/// reasons.
///
/// Bikeshed name for now.
```

As far as I am aware, there's no new behavior being guaranteed by this trait, since it operates the same as the manually implemented check. We could easily rip out this trait and go back to using the manually implemented check for union fields, however using a trait means that this code can be shared by WF for `unsafe<>` binders too. See the last commit.

The only diagnostic changes are that this now fires false-negatives for fields that are ill-formed. I don't consider that to be much of a problem though.

r? oli-obk

[^1]: Please let's not bikeshed this name lol. There's no good name for `ValidForUnsafeFieldsUnsafeBindersAndUnionFields`.
2025-02-13 03:53:30 -05:00
Michael Goulet
72b4df3772 Implement lint for definition site item shadowing too 2025-02-13 05:45:53 +00:00
Jubilee Young
4bb0c3da2c Split out the extern_system_varargs feature
After the stabilization PR was opened, `extern "system"` functions were
added to `extended_varargs_abi_support`. This has a number of questions
regarding it that were not discussed and were somewhat surprising.
It deserves to be considered as its own feature, separate from
`extended_varargs_abi_support`.
2025-02-12 19:57:45 -08:00
Michael Goulet
516afd557c Implement and use BikeshedGuaranteedNoDrop for union/unsafe field validity 2025-02-13 03:45:04 +00:00
Jacob Pratt
03e2d7ebc5
Rollup merge of #136806 - adwinwhite:cycle-in-pretty-print-rpitit, r=compiler-errors
Fix cycle when debug-printing opaque types from RPITIT

Extend #66594 to opaque types from RPITIT.

Before this PR, enabling debug logging like `RUSTC_LOG="[check_type_bounds]"` for code containing RPITIT produces a query cycle of `explicit_item_bounds`, as pretty printing for opaque type calls [it](d9a4a47b8b/compiler/rustc_middle/src/ty/print/pretty.rs (L1001)).
2025-02-12 20:09:59 -05:00
Jacob Pratt
6b9b0a0ce8
Rollup merge of #135841 - oli-obk:push-qxlnokwrkkym, r=compiler-errors
Reject `?Trait` bounds in various places where we unconditionally warned since 1.0

fixes #135730
fixes #135809

Also a breaking change, so let's see what crater says.

This has been an unconditional warning since *before* 1.0
2025-02-12 20:09:57 -05:00
Lukas Markeffsky
885e0f1b96 intern valtrees 2025-02-13 00:38:17 +01:00
bors
552a959051 Auto merge of #136918 - GuillaumeGomez:rollup-f6h21gg, r=GuillaumeGomez
Rollup of 8 pull requests

Successful merges:

 - #134981 ( Explain that in paths generics can't be set on both the enum and the variant)
 - #136698 (Replace i686-unknown-redox target with i586-unknown-redox)
 - #136767 (improve host/cross target checking)
 - #136829 ([rustdoc] Move line numbers into the `<code>` directly)
 - #136875 (Rustc dev guide subtree update)
 - #136900 (compiler: replace `ExternAbi::name` calls with formatters)
 - #136913 (Put kobzol back on review rotation)
 - #136915 (documentation fix: `f16` and `f128` are not double-precision)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-12 12:42:25 +00:00
Guillaume Gomez
30bd1b53b3
Rollup merge of #136900 - workingjubilee:format-externabi-directly, r=oli-obk
compiler: replace `ExternAbi::name` calls with formatters

Most of these just format the ABI string, so... just format ExternAbi? This makes it more consistent and less jank when we can do it.
2025-02-12 10:46:40 +01:00
Guillaume Gomez
262079b52a
Rollup merge of #134981 - estebank:issue-93993, r=BoxyUwU
Explain that in paths generics can't be set on both the enum and the variant

```
error[E0109]: type arguments are not allowed on tuple variant `TSVariant`
  --> $DIR/enum-variant-generic-args.rs:54:29
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |                 ---------   ^^ type argument not allowed
   |                 |
   |                 not allowed on tuple variant `TSVariant`
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
help: remove the generics arguments from one of the path segments
   |
LL -     Enum::<()>::TSVariant::<()>(());
LL +     Enum::TSVariant::<()>(());
   |
LL -     Enum::<()>::TSVariant::<()>(());
LL +     Enum::<()>::TSVariant(());
   |
```

Fix #93993.
2025-02-12 10:46:36 +01:00
bors
021fb9c09a Auto merge of #136897 - workingjubilee:revert-unfcped-stab, r=WaffleLapkin
Revert "Stabilize `extended_varargs_abi_support`"

I cannot find an FCP for this, despite it being a stabilization PR which normally means we do an FCP of some kind? It would seem reasonable for _either_ compiler or lang to have FCPed it? I am thus opening a revert PR, which mostly-cleanly applies, so that we can later actually land this properly with a stability report and FCP.

- https://github.com/rust-lang/rust/issues/136896
- https://github.com/rust-lang/rust/pull/116161
- https://github.com/rust-lang/rust/issues/100189
2025-02-12 09:44:30 +00:00
Matthias Krüger
77a1d6b266
Rollup merge of #136891 - compiler-errors:unconstrained-anon-lt, r=lqd
Check sig for errors before checking for unconstrained anonymous lifetime

Fixes #136841
2025-02-12 06:07:40 +01:00
Jubilee Young
32fd1a7b72 compiler: replace ExternAbi::name calls with formatters
Most of these just format the ABI string, so... just format ExternAbi?
This makes it more consistent and less jank when we can do it.
2025-02-11 19:42:47 -08:00
Jubilee Young
d97bde059a Revert "Stabilize extended_varargs_abi_support"
This reverts commit 685f189b4307435b83d625fea397ef36dff4e955.
2025-02-11 17:22:27 -08:00
Esteban Küber
23daa8c724 Remove some the spans pointing at the enum in the path and its generic args
```
error[E0109]: type arguments are not allowed on tuple variant `TSVariant`
  --> $DIR/enum-variant-generic-args.rs:54:29
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |                 ---------   ^^ type argument not allowed
   |                 |
   |                 not allowed on tuple variant `TSVariant`
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
help: remove the generics arguments from one of the path segments
   |
LL -     Enum::<()>::TSVariant::<()>(());
LL +     Enum::<()>::TSVariant(());
   |
```
2025-02-11 23:47:56 +00:00
Esteban Küber
1b98d0ed13 Explain that in paths generics can't be set on both the enum and the variant
```
error[E0109]: type arguments are not allowed on enum `Enum` and tuple variant `TSVariant`
  --> $DIR/enum-variant-generic-args.rs:54:12
   |
LL |     Enum::<()>::TSVariant::<()>(());
   |     ----   ^^   ---------   ^^ type argument not allowed
   |     |           |
   |     |           not allowed on tuple variant `TSVariant`
   |     not allowed on enum `Enum`
   |
   = note: generic arguments are not allowed on both an enum and its variant's path segments simultaneously; they are only valid in one place or the other
help: remove the generics arguments from one of the path segments
   |
LL -     Enum::<()>::TSVariant::<()>(());
LL +     Enum::<()>::TSVariant(());
   |
```

Fix #93993.
2025-02-11 23:30:07 +00:00
Michael Goulet
6ffe6dd826 Check sig for errors before checking for unconstrained anonymous lifetime 2025-02-11 22:59:57 +00:00
Michael Goulet
f0cb746480 Lower fn items as ZST valtrees and delay a bug 2025-02-11 19:16:12 +00:00
Oli Scherer
c294da3310 Reject impl Trait bounds in various places where we unconditionally warned since 1.0 2025-02-11 09:19:37 +00:00
Adwin White
a634246b66 reduce query calls in pretty printing when finding bounds of
associated types
2025-02-11 12:30:16 +08:00
Matthias Krüger
af3c51d849
Rollup merge of #136107 - dingxiangfei2009:coerce-pointee-wellformed, r=compiler-errors
Introduce CoercePointeeWellformed for coherence checks at typeck stage

Fix #135206

This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.

This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.

A following series of patch will arrive later to address the following concern.
1. #135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.

**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.

``@rustbot`` label F-derive_coerce_pointee
2025-02-11 02:53:42 +01:00
Ding Xiang Fei
b9435056a7
move repr(transparent) checks to coherence 2025-02-09 20:40:43 +08:00
Ding Xiang Fei
c067324637
rename the trait to validity and place a feature gate afront 2025-02-09 20:40:42 +08:00
Ding Xiang Fei
de405dcb8f
introduce CoercePointeeWellformed for coherence checks at typeck stage 2025-02-09 20:40:41 +08:00
bjorn3
1fcae03369 Rustfmt 2025-02-08 22:12:13 +00:00
Matthias Krüger
7ca29360a7
Rollup merge of #136073 - compiler-errors:recursive-coro-always, r=oli-obk
Always compute coroutine layout for eagerly emitting recursive layout errors

Detect recursive coroutine layouts even if we don't detect opaque type recursion in the new solver. This is for two reasons:
1. It helps us detect (bad) recursive async function calls in the new solver, which due to its approach to normalization causes us to not detect this via a recursive RPIT (since the opaques are more eagerly revealed in the opaque body).
    * Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/137.
2. It helps us detect (bad) recursive async functions behind AFITs. See the AFIT test that changed for the old solver too.
3. It also greatly simplifies the recursive impl trait check, since I can remove some jankness around how it handles coroutines.
2025-02-06 13:09:57 +01:00
Jubilee
1361ef37ff
Rollup merge of #136550 - compiler-errors:rpitit-empty-body, r=oli-obk
Fix `rustc_hidden_type_of_opaques` for RPITITs with no default body

Needed this when debugging something
2025-02-05 19:53:47 -08:00
Michael Goulet
d0b0b028a6 Eagerly detect coroutine recursion pre-mono when possible 2025-02-05 18:36:17 +00:00
León Orell Valerian Liehr
d81701b610
Rollup merge of #128045 - pnkfelix:rustc-contracts, r=oli-obk
#[contracts::requires(...)]  + #[contracts::ensures(...)]

cc https://github.com/rust-lang/rust/issues/128044

Updated contract support: attribute syntax for preconditions and postconditions, implemented via a series of desugarings  that culminates in:
1. a compile-time flag (`-Z contract-checks`) that, similar to `-Z ub-checks`, attempts to ensure that the decision of enabling/disabling contract checks is delayed until the end user program is compiled,
2. invocations of lang-items that handle invoking the precondition,  building a checker for the post-condition, and invoking that post-condition checker at the return sites for the function, and
3. intrinsics for the actual evaluation of pre- and post-condition predicates that third-party verification tools can intercept and reinterpret for their own purposes (e.g. creating shims of behavior that abstract away the function body and replace it solely with the pre- and post-conditions).

Known issues:

 * My original intent, as described in the MCP (https://github.com/rust-lang/compiler-team/issues/759) was   to have a rustc-prefixed attribute namespace (like   rustc_contracts::requires). But I could not get things working when I tried   to do rewriting via a rustc-prefixed builtin attribute-macro. So for now it  is called `contracts::requires`.

 * Our attribute macro machinery does not provide direct support for attribute arguments that are parsed like rust expressions. I spent some time trying to add that (e.g. something that would parse the attribute arguments as an AST while treating the remainder of the items as a token-tree), but its too big a lift for me to undertake. So instead I hacked in something approximating that goal, by semi-trivially desugaring the token-tree attribute contents into internal AST constucts. This may be too fragile for the long-term.
   * (In particular, it *definitely* breaks when you try to add a contract to a function like this: `fn foo1(x: i32) -> S<{ 23 }> { ... }`, because its token-tree based search for where to inject the internal AST constructs cannot immediately see that the `{ 23 }` is within a generics list. I think we can live for this for the short-term, i.e. land the work, and continue working on it while in parallel adding a new attribute variant that takes a token-tree attribute alongside an AST annotation, which would completely resolve the issue here.)

* the *intent* of `-Z contract-checks` is that it behaves like `-Z ub-checks`, in that we do not prematurely commit to including or excluding the contract evaluation in upstream crates (most notably, `core` and `std`). But the current test suite does not actually *check* that this is the case. Ideally the test suite would be extended with a multi-crate test that explores the matrix of enabling/disabling contracts on both the upstream lib and final ("leaf") bin crates.
2025-02-05 05:03:01 +01:00
bors
bef3c3b01f Auto merge of #136549 - matthiaskrgr:rollup-sqbpgtd, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #136242 (Remove `LateContext::match_def_path()`)
 - #136274 (Check Sizedness of return type in WF)
 - #136284 (Allow using named consts in pattern types)
 - #136477 (Fix a couple NLL TLS spans )
 - #136497 (Report generic mismatches when calling bodyless trait functions)
 - #136520 (Remove unnecessary layout assertions for object-safe receivers)
 - #136526 (mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers`)

Failed merges:

 - #136304 (Reject negative literals for unsigned or char types in pattern ranges and literals)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-02-04 20:55:34 +00:00
Michael Goulet
009feeb83e Fix rustc_hidden_type_of_opaques for RPITITs with no default body 2025-02-04 17:56:47 +00:00
Matthias Krüger
b07fa7696b
Rollup merge of #136284 - oli-obk:push-zsxuwnzmonnl, r=lcnr
Allow using named consts in pattern types

This required a refactoring first: I had to stop using `hir::Pat`in `hir::TyKind::Pat` and instead create a separate `TyPat` that has `ConstArg` for range ends instead of `PatExpr`. Within the type system we should be using `ConstArg` for all constants, as otherwise we'd be maintaining two separate const systems that could diverge. The big advantage of this PR is that we now inherit all the rules from const generics and don't have a separate system. While this makes things harder for users (const generic rules wrt what is allowed in those consts), it also means we don't accidentally allow some things like referring to assoc consts or doing math on generic consts.
2025-02-04 18:49:37 +01:00
Matthias Krüger
a8ecb79d19
Rollup merge of #136274 - compiler-errors:sized-wf, r=lcnr
Check Sizedness of return type in WF

Still need to clean this up a bit. This should fix https://github.com/rust-lang/trait-system-refactor-initiative/issues/150.

r? lcnr
2025-02-04 18:49:37 +01:00
bors
3f33b30e19 Auto merge of #135760 - scottmcm:disjoint-bitor, r=WaffleLapkin
Add `unchecked_disjoint_bitor` per ACP373

Following the names from libs-api in https://github.com/rust-lang/libs-team/issues/373#issuecomment-2085686057

Includes a fallback implementation so this doesn't have to update cg_clif or cg_gcc, and overrides it in cg_llvm to use `or disjoint`, which [is available in LLVM 18](https://releases.llvm.org/18.1.0/docs/LangRef.html#or-instruction) so hopefully we don't need any version checks.
2025-02-04 17:46:06 +00:00
Oli Scherer
fbcaa9b0a1 Allow using named consts in pattern types 2025-02-04 15:17:31 +00:00
Celina G. Val
2bb1464cb6 Improve contracts intrisics and remove wrapper function
1. Document the new intrinsics.
2. Make the intrinsics actually check the contract if enabled, and
   remove `contract::check_requires` function.
3. Use panic with no unwind in case contract is using to check for
   safety, we probably don't want to unwind. Following the same
   reasoning as UB checks.
2025-02-03 13:55:15 -08:00
Felix S. Klock II
bcb8565f30 Contracts core intrinsics.
These are hooks to:

  1. control whether contract checks are run
  2. allow 3rd party tools to intercept and reintepret the results of running contracts.
2025-02-03 12:53:57 -08:00