Commit Graph

2469 Commits

Author SHA1 Message Date
Michael Goulet
ae8b4607c6 Introduce distinct error codes for precise capturing 2024-09-16 10:56:22 -04:00
Michael Goulet
26bdfefae1 Do precise capturing arg validation in resolve 2024-09-16 10:56:22 -04:00
Obei Sideg
74cab947f7
Disallow hidden references to mutable static 2024-09-13 13:33:43 +03:00
bors
a5efa01895 Auto merge of #107251 - dingxiangfei2009:let-chain-rescope, r=jieyouxu
Rescope temp lifetime in if-let into IfElse with migration lint

Tracking issue #124085

This PR shortens the temporary lifetime to cover only the pattern matching and consequent branch of a `if let`.

At the expression location, means that the lifetime is shortened from previously the deepest enclosing block or statement in Edition 2021. This warrants an Edition change.

Coming with the Edition change, this patch also implements an edition lint to warn about the change and a safe rewrite suggestion to preserve the 2021 semantics in most cases.

Related to #103108.
Related crater runs: https://github.com/rust-lang/rust/pull/129466.
2024-09-13 03:47:30 +00:00
Veera
741005792e Implement a Method to Seal DiagInner's Suggestions 2024-09-12 21:27:44 -04:00
Stuart Cook
57020e0f8c
Rollup merge of #130250 - compiler-errors:useless-conversion, r=jieyouxu
Fix `clippy::useless_conversion`

Self-explanatory. Probably the last clippy change I'll actually put up since this is the only other one I've actually seen in the wild.
2024-09-12 20:37:17 +10:00
Stuart Cook
3ba12756d3
Rollup merge of #130235 - compiler-errors:nested-if, r=michaelwoerister
Simplify some nested `if` statements

Applies some but not all instances of `clippy::collapsible_if`. Some ended up looking worse afterwards, though, so I left those out. Also applies instances of `clippy::collapsible_else_if`

Review with whitespace disabled please.
2024-09-12 20:37:16 +10:00
Jubilee
a31a8fe0cf
Rollup merge of #130114 - eduardosm:needless-returns, r=compiler-errors
Remove needless returns detected by clippy in the compiler
2024-09-11 15:53:22 -07:00
Michael Goulet
6d064295c8 clippy::useless_conversion 2024-09-11 17:52:53 -04:00
Michael Goulet
af8d911d63 Also fix if in else 2024-09-11 17:24:01 -04:00
Michael Goulet
954419aab0 Simplify some nested if statements 2024-09-11 13:45:23 -04:00
bors
6f7229c4da Auto merge of #129403 - scottmcm:only-array-simd, r=compiler-errors
Ban non-array SIMD

Nearing the end of https://github.com/rust-lang/compiler-team/issues/621 !

Currently blocked on ~~https://github.com/rust-lang/compiler-builtins/pull/673~~ ~~https://github.com/rust-lang/compiler-builtins/pull/674~~ ~~https://github.com/rust-lang/rust/pull/129400~~ ~~https://github.com/rust-lang/rust/pull/129481~~ for windows.
2024-09-10 22:47:40 +00:00
Ding Xiang Fei
f93df1f7dc
rescope temp lifetime in let-chain into IfElse
apply rules by span edition
2024-09-11 04:10:00 +08:00
Scott McMurray
d2309c2a9d Ban non-array SIMD 2024-09-09 19:39:43 -07:00
Jubilee
68ae3b27f5
Rollup merge of #130149 - GrigorenkoPV:lifetime-suggestion, r=cjgillot
Helper function for formatting with `LifetimeSuggestionPosition`
2024-09-09 19:20:38 -07:00
Matthias Krüger
1490fe6d16
Rollup merge of #130064 - folkertdev:fix-issue-129983, r=compiler-errors
fix ICE in CMSE type validation

fixes #129983

tracking issue: https://github.com/rust-lang/rust/issues/81391

r? ``@compiler-errors``
2024-09-09 20:20:18 +02:00
Pavel Grigorenko
db6361184e Helper function for formatting with LifetimeSuggestionPosition 2024-09-09 14:39:04 +03:00
Eduardo Sánchez Muñoz
0b20ffcb63 Remove needless returns detected by clippy in the compiler 2024-09-09 13:32:22 +02:00
Folkert de Vries
e186cc6df8 do PolyFnSig -> FnSig conversion later 2024-09-09 11:09:22 +02:00
bors
085744b7ad Auto merge of #130036 - weiznich:diagnostic_unstable_tracking, r=compiler-errors
Correctly handle stability of `#[diagnostic]` attributes

This commit changes the way we treat the stability of attributes in the
`#[diagnostic]` namespace. Instead of relaying on ad-hoc checks to
ensure at call side that a certain attribute is really usable at that
location it centralises the logic to one place. For diagnostic
attributes comming from other crates it just skips serializing
attributes that are not stable and that do not have the corresponding
feature enabled. For attributes from the current crate we can just use
the feature information provided by `TyCtx`.

r​? `@compiler-errors`
2024-09-08 23:39:00 +00:00
bors
ec867f03bc Auto merge of #126161 - Bryanskiy:delegation-generics-4, r=petrochenkov
Delegation: support generics in associated delegation items

This is a continuation of https://github.com/rust-lang/rust/pull/125929.

[design](https://github.com/Bryanskiy/posts/blob/master/delegation%20in%20generic%20contexts.md)

Generic parameters inheritance was implemented in all contexts. Generic arguments are not yet supported.

r? `@petrochenkov`
2024-09-07 18:12:05 +00:00
Folkert de Vries
46115fd6d3 fix ICE in CMSE type validation 2024-09-07 10:53:59 +02:00
bors
26b5599e4d Auto merge of #128776 - Bryanskiy:deep-reject-ctxt, r=lcnr
Use `DeepRejectCtxt` to quickly reject `ParamEnv` candidates

The description is on the [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/.5Basking.20for.20help.5D.20.60DeepRejectCtxt.60.20for.20param.20env.20candidates)

r? `@lcnr`
2024-09-06 19:50:48 +00:00
Georg Semmler
7c9e818f02
Revert ed7bdbb17b 2024-09-06 19:06:59 +02:00
Bryanskiy
588dce1421 Delegation: support generics in associated delegation items 2024-09-05 16:04:50 +03:00
Matthias Krüger
08187c32c7
Rollup merge of #129664 - adetaylor:arbitrary-self-types-pointers-feature-gate, r=wesleywiser
Arbitrary self types v2: pointers feature gate.

The main `arbitrary_self_types` feature gate will shortly be reused for a new version of arbitrary self types which we are amending per [this RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md). The main amendments are:

* _do_ support `self` types which can't safely implement `Deref`
* do _not_ support generic `self` types
* do _not_ support raw pointers as `self` types.

This PR relates to the last of those bullet points: this strips pointer support from the current `arbitrary_self_types` feature. We expect this to cause some amount of breakage for crates using this unstable feature to allow raw pointer self types. If that's the case, we want to know about it, and we want crate authors to know of the upcoming changes.

For now, this can be resolved by adding the new
`arbitrary_self_types_pointers` feature to such crates. If we determine that use of raw pointers as self types is common, then we may maintain that as an unstable feature even if we come to stabilize the rest of the `arbitrary_self_types` support in future. If we don't hear that this PR is causing breakage, then perhaps we don't need it at all, even behind an unstable feature gate.

[Tracking issue](https://github.com/rust-lang/rust/issues/44874)

This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
2024-09-05 03:47:42 +02:00
Matthias Krüger
f75a1954eb
Rollup merge of #127692 - veera-sivarajan:bugfix-125139, r=estebank
Suggest `impl Trait` for References to Bare Trait in Function Header

Fixes #125139

This PR suggests `impl Trait` when `&Trait` is found as a function parameter type or return type. This makes use of existing diagnostics by adding `peel_refs()` when checking for type equality.

Additionaly, it makes a few other improvements:
1. Checks if functions inside impl blocks have bare trait in their headers.
2. Introduces a trait `NextLifetimeParamName` similar to the existing `NextTypeParamName` for suggesting a lifetime name. Also, abstracts out the common logic between the two trait impls.

### Related Issues
I ran into a bunch of related diagnostic issues but couldn't fix them within the scope of this PR. So, I have created the following issues:
1. [Misleading Suggestion when Returning a Reference to a Bare Trait from a Function](https://github.com/rust-lang/rust/issues/127689)
2. [Verbose Error When a Function Takes a Bare Trait as Parameter](https://github.com/rust-lang/rust/issues/127690)
3. [Incorrect Suggestion when Returning a Bare Trait from a Function](https://github.com/rust-lang/rust/issues/127691)

r​? ```@estebank``` since you implemented  #119148
2024-09-03 19:13:23 +02:00
Bryanskiy
59885f5065 Delegation refactoring: add builders for generics inheritance 2024-09-03 15:38:39 +03:00
Bryanskiy
c51953f4d8 Use DeepRejectCtxt to quickly reject ParamEnv candidates 2024-09-02 19:59:18 +03:00
Alexander Cyon
ac69544a17
chore: Fix typos in 'compiler' (batch 1) 2024-09-02 07:42:38 +02:00
Matthias Krüger
7d025bb63d
Rollup merge of #129767 - nnethercote:rm-extern-crate-tracing-4, r=jieyouxu
Remove `#[macro_use] extern crate tracing`, round 4

Because explicit importing of macros via use items is nicer (more standard and readable) than implicit importing via #[macro_use]. Continuing the work from #124511, #124914, and #125434. After this PR no `rustc_*` crates use `#[macro_use] extern crate tracing` except for `rustc_codegen_gcc` which is a special case and I will do separately.

r? ```@jieyouxu```
2024-08-31 14:46:11 +02:00
Adrian Taylor
8e20b66524 Some code review suggestions. 2024-08-30 17:48:15 +00:00
Nicholas Nethercote
cc16c902f1 Remove #[macro_use] extern crate tracing from rustc_hir_analysis. 2024-08-30 17:14:59 +10:00
Michael Goulet
92004523db Stop using ty::GenericPredicates for non-predicates_of queries 2024-08-29 00:17:40 -04:00
bors
748c54848d Auto merge of #129546 - compiler-errors:no-pred-on, r=fee1-dead
Get rid of `predicates_defined_on`

This is the uncontroversial part of #129532. This simply inlines the `predicates_defined_on` into into `predicates_of`. Nothing should change here logically.
2024-08-28 04:41:43 +00:00
bors
d9a2cc4dae Auto merge of #128506 - compiler-errors:by-move-body, r=cjgillot
Stop storing a special inner body for the coroutine by-move body for async closures

...and instead, just synthesize an item which is treated mostly normally by the MIR pipeline.

This PR does a few things:
* We synthesize a new `DefId` for the by-move body of a closure, which has its `mir_built` fed with the output of the `ByMoveBody` MIR transformation, and some other relevant queries.
* This has the `DefKind::ByMoveBody`, which we use to distinguish it from "real" bodies (that come from HIR) which need to be borrowck'd. Introduce `TyCtxt::is_synthetic_mir` to skip over `mir_borrowck` which is called by `mir_promoted`; borrowck isn't really possible to make work ATM since it heavily relies being called on a body generated from HIR, and is redundant by the construction of the by-move-body.
* Remove the special `PassManager` hacks for handling the inner `by_move_body` stored within the coroutine's mir body. Instead, this body is fed like a regular MIR body, so it's goes through all of the `tcx.*_mir` stages normally (build -> promoted -> ...etc... -> optimized) .
* Remove the `InstanceKind::ByMoveBody` shim, since now we have a "regular" def id, we can just use `InstanceKind::Item`. This also allows us to remove the corresponding hacks from codegen, such as in `fn_sig_for_fn_abi` .

Notable remarks:
* ~~I know it's kind of weird to be using `DefKind::Closure` here, since it's not a distinct closure but just a new MIR body. I don't believe it really matters, but I could also use a different `DefKind`... maybe one that we could use for synthetic MIR bodies in general?~~ edit: We're doing this now.
2024-08-27 23:30:24 +00:00
Adrian Taylor
e77eb042ce Arbitrary self types v2: pointers feature gate.
The main `arbitrary_self_types` feature gate will shortly be reused for
a new version of arbitrary self types which we are amending per [this
RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md).
The main amendments are:

* _do_ support `self` types which can't safely implement `Deref`
* do _not_ support generic `self` types
* do _not_ support raw pointers as `self` types.

This PR relates to the last of those bullet points: this strips pointer
support from the current `arbitrary_self_types` feature.
We expect this to cause some amount of breakage for crates using this
unstable feature to allow raw pointer self types. If that's the case, we
want to know about it, and we want crate authors to know of the upcoming
changes.

For now, this can be resolved by adding the new
`arbitrary_self_types_pointers` feature to such crates. If we determine
that use of raw pointers as self types is common, then we may maintain
that as an unstable feature even if we come to stabilize the rest of the
`arbitrary_self_types` support in future. If we don't hear that this PR
is causing breakage, then perhaps we don't need it at all, even behind
an unstable feature gate.

[Tracking issue](https://github.com/rust-lang/rust/issues/44874)

This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
2024-08-27 17:32:35 +00:00
Nicholas Nethercote
5acf4e7b4b Add warn(unreachable_pub) to rustc_hir_analysis. 2024-08-27 13:14:50 +10:00
Michael Goulet
4609841c07 Stop using a special inner body for the coroutine by-move body for async closures 2024-08-26 18:44:19 -04:00
Matthias Krüger
d6a3aa4fc4
Rollup merge of #129590 - compiler-errors:ref-tykind, r=fmease
Avoid taking reference of &TyKind

It's already a ref anyways. Just a tiny cleanup here.
2024-08-26 01:49:04 +02:00
Matthias Krüger
ae21236530
Rollup merge of #129519 - compiler-errors:lowering-flags, r=fmease
Remove redundant flags from `lower_ty_common` that can be inferred from the HIR

...and then get rid of `lower_ty_common`.

r? ``@fmease`` or re-roll if you're busy!
2024-08-26 01:49:01 +02:00
Michael Goulet
ecd2d11573 Remove redundant flags that can be inferred from the HIR 2024-08-25 16:21:00 -04:00
Michael Goulet
48f43fa0ed Avoid taking reference of &TyKind 2024-08-25 16:02:29 -04:00
Matthias Krüger
9c59e97ded
Rollup merge of #129487 - GrigorenkoPV:repr_transparent_external_private_fields, r=compiler-errors
repr_transparent_external_private_fields: special-case some std types

Fixes #129470

```@rustbot``` label +A-lint +L-repr_transparent_external_private_fields
2024-08-25 16:51:05 +02:00
bors
717aec0f8e Auto merge of #129521 - matthiaskrgr:rollup-uigv77m, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #128596 (stabilize const_fn_floating_point_arithmetic)
 - #129199 (make writes_through_immutable_pointer a hard error)
 - #129246 (Retroactively feature gate `ConstArgKind::Path`)
 - #129290 (Pin `cc` to 1.0.105)
 - #129323 (Implement `ptr::fn_addr_eq`)
 - #129500 (remove invalid `TyCompat` relation for effects)
 - #129501 (panicking: improve hint for Miri's RUST_BACKTRACE behavior)
 - #129505 (interpret: ImmTy: tighten sanity checks in offset logic)
 - #129510 (Fix `elided_named_lifetimes` in code)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-25 08:12:16 +00:00
Trevor Gross
2269381e0a
Rollup merge of #129429 - cjgillot:named-variance, r=compiler-errors
Print the generic parameter along with the variance in dumps.

This allows to make sure we are testing what we think we are testing.

While the tests are correct, I discovered that opaque duplicated args are in the reverse declaration order.
2024-08-24 21:03:32 -05:00
Michael Goulet
dbf06d2170 Get rid of predicates_defined_on 2024-08-24 18:25:41 -04:00
Pavel Grigorenko
06f2d73b2b repr_transparent_external_private_fields: treat rustc_pub_transparent types as local 2024-08-24 23:05:54 +03:00
Michael Goulet
147bb17f51 Rework how we emit errors for unresolved object lifetimes 2024-08-24 14:55:31 -04:00
Pavel Grigorenko
53ce92770d Fix elided_named_lifetimes in code 2024-08-24 19:21:32 +03:00
Camille GILLOT
5cef88c1f4 Print the generic parameter along with the variance in dumps. 2024-08-23 23:00:45 +00:00
Matthias Krüger
32821b9f8a
Rollup merge of #129417 - compiler-errors:refine-err, r=lqd
Don't trigger refinement lint if predicates reference errors

Fixes #129404
2024-08-23 06:26:54 +02:00
Matthias Krüger
487b3d92cf
Rollup merge of #129386 - cjgillot:local-resolved-arg, r=compiler-errors
Use a LocalDefId in ResolvedArg.
2024-08-23 06:26:53 +02:00
Michael Goulet
8eb15586c6 Don't trigger refinement lint if predicates reference errors 2024-08-22 12:34:12 -04:00
bors
739b1fdb15 Auto merge of #129365 - matthiaskrgr:rollup-ebwx6ya, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #127279 (use old ctx if has same expand environment during decode span)
 - #127945 (Implement `debug_more_non_exhaustive`)
 - #128941 ( Improve diagnostic-related lints: `untranslatable_diagnostic` & `diagnostic_outside_of_impl`)
 - #129070 (Point at explicit `'static` obligations on a trait)
 - #129187 (bootstrap: fix clean's remove_dir_all implementation)
 - #129231 (improve submodule updates)
 - #129264 (Update `library/Cargo.toml` in weekly job)
 - #129284 (rustdoc: animate the `:target` highlight)
 - #129302 (compiletest: use `std::fs::remove_dir_all` now that it is available)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-22 05:17:27 +00:00
Camille GILLOT
c51f2d24d1 Use a LocalDefId in ResolvedArg. 2024-08-22 01:17:01 +00:00
Esteban Küber
f5bae722be Point at explicit 'static obligations on a trait
Given `trait Any: 'static` and a `struct` with a `Box<dyn Any + 'a>` field, point at the `'static` bound in `Any` to explain why `'a: 'static`.

```
error[E0478]: lifetime bound not satisfied
   --> f202.rs:2:12
    |
2   |     value: Box<dyn std::any::Any + 'a>,
    |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: lifetime parameter instantiated with the lifetime `'a` as defined here
   --> f202.rs:1:14
    |
1   | struct Hello<'a> {
    |              ^^
note: but lifetime parameter must outlive the static lifetime
   --> /home/gh-estebank/rust/library/core/src/any.rs:113:16
    |
113 | pub trait Any: 'static {
    |                ^^^^^^^
```

Partially address #33652.
2024-08-21 16:40:15 +00:00
Matthias Krüger
4137f3bc15
Rollup merge of #129345 - compiler-errors:scratch4, r=jieyouxu
Use shorthand field initialization syntax more aggressively in the compiler

Caught these when cleaning up #129344 and decided to run clippy to find the rest
2024-08-21 18:15:06 +02:00
Matthias Krüger
937a18daf9
Rollup merge of #129344 - compiler-errors:less-option-unit-diagnostics, r=jieyouxu
Use `bool` in favor of `Option<()>` for diagnostics

We originally only supported `Option<()>` for optional notes/labels, but we now support `bool`. Let's use that, since it usually leads to more readable code.

I'm not removing the support from the derive macro, though I guess we could error on it... 🤔
2024-08-21 18:15:05 +02:00
Matthias Krüger
48c9864a05
Rollup merge of #128843 - veera-sivarajan:small-cleanup, r=davidtwco
Minor Refactor: Remove a Redundant Conditional Check

The existing code checks `where_bounds.is_empty()` twice when
it can be combined into one. Now, after combining, the refactored code reads
better and feels straightforward.

The diff doesn't make it clear. So, the current code looks like this:
``` rust
    if !where_bounds.is_empty() {
        err.help(format!(
            "consider introducing a new type parameter `T` and adding `where` constraints:\
             \n    where\n        T: {qself_str},\n{}",
            where_bounds.join(",\n"),
        ));
    }
    let reported = err.emit();
    if !where_bounds.is_empty() {
        return Err(reported);
    }
```
The proposed changes:
``` rust
    if !where_bounds.is_empty() {
        err.help(format!(
            "consider introducing a new type parameter `T` and adding `where` constraints:\
             \n    where\n        T: {qself_str},\n{}",
            where_bounds.join(",\n"),
        ));
        let reported = err.emit();
        return Err(reported);
    }
    err.emit();

```
2024-08-21 18:15:01 +02:00
Michael Goulet
0b2525c787 Simplify some redundant field names 2024-08-21 01:31:42 -04:00
Michael Goulet
25ff9b6bcb Use bool in favor of Option<()> for diagnostics 2024-08-21 01:31:11 -04:00
Veera
12de141df2 Suggest impl Trait for References to Bare Trait in Function Header 2024-08-19 15:19:43 -04:00
Michael Goulet
833af65f38 Use FnSig instead of raw FnDecl for ForeignItemKind::Fn 2024-08-16 14:10:06 -04:00
bors
e9c965df7b Auto merge of #128812 - nnethercote:shrink-TyKind-FnPtr, r=compiler-errors
Shrink `TyKind::FnPtr`.

By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.

r? `@compiler-errors`
2024-08-14 00:56:53 +00:00
Matthias Krüger
85eb465a10
Rollup merge of #128912 - compiler-errors:do-not-recommend-impl, r=lcnr
Store `do_not_recommend`-ness in impl header

Alternative to #128674

It's less flexible, but also less invasive. Hopefully it's also performant. I'd recommend we think separately about the design for how to gate arbitrary diagnostic attributes moving forward.
2024-08-12 23:10:51 +02:00
Guillaume Gomez
7c6dca9050
Rollup merge of #128978 - compiler-errors:assert-matches, r=jieyouxu
Use `assert_matches` around the compiler more

It's a useful assertion, especially since it actually prints out the LHS.
2024-08-12 17:09:19 +02:00
Michael Goulet
c361c924a0 Use assert_matches around the compiler 2024-08-11 12:25:39 -04:00
Jonathan Birk
ca94dd5bea Add more information link to orphan impls 2024-08-11 10:50:07 +00:00
Guillaume Gomez
50e9fd1a1d
Rollup merge of #128910 - estebank:assoc-fn, r=compiler-errors
Differentiate between methods and associated functions in diagnostics

Accurately refer to assoc fn without receiver as assoc fn instead of methods. Add `AssocItem::descr` method to centralize where we call methods and associated functions.
2024-08-10 16:23:55 +02:00
bors
48090b11b5 Auto merge of #128746 - compiler-errors:cache-super-outlives, r=lcnr
Cache supertrait outlives of impl header for soundness check

This caches the results of computing the transitive supertraits of an impl and filtering it to its outlives obligations. This is purely an optimization to improve https://github.com/rust-lang/rust/pull/124336.
2024-08-10 10:22:06 +00:00
Michael Goulet
ed7bdbb17b Store do_not_recommend-ness in impl header 2024-08-09 22:02:20 -04:00
Esteban Küber
860c8cdeaf Differentiate between methods and associated functions
Accurately refer to assoc fn without receiver as assoc fn instead of methods.
Add `AssocItem::descr` method to centralize where we call methods and associated functions.
2024-08-10 00:54:16 +00:00
Nicholas Nethercote
c4717cc9d1 Shrink TyKind::FnPtr.
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and
`FnHeader`, which can be packed more efficiently. This reduces the size
of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms.
This reduces peak memory usage by a few percent on some benchmarks. It
also reduces cache misses and page faults similarly, though this doesn't
translate to clear cycles or wall-time improvements on CI.
2024-08-09 14:33:25 +10:00
Veera
1350a65736 Remove a Redundant Conditional Check
The existing code check for `where_bounds.is_empty()` twice when
it can be combined into one. Moreover, the refactored code reads
better and feels straightforward.
2024-08-08 15:21:15 -04:00
Michael Goulet
b916431976 Rename struct_tail_erasing_lifetimes to struct_tail_for_codegen 2024-08-08 12:15:16 -04:00
Guillaume Gomez
a6caceee4d
Rollup merge of #128424 - fee1-dead-contrib:fx-clean, r=oli-obk
minor `effects` cleanups

* remove the fixme comment about not needing defaults because it turns out we do need defaults (if I made it None instead it would ice a bunch of tests)
* remove the part that special cased trait args when lowering them. This is now historical because effects doesn't add host args to traits anymore (we use associated types now)
2024-08-07 15:59:35 +02:00
Matthias Krüger
333c63b9fc
Rollup merge of #128377 - veera-sivarajan:fix-128249, r=davidtwco
Fix ICE Caused by Incorrectly Delaying E0107

Fixes  #128249

For the following code:
```rust
trait Foo<T> {}
impl Foo<T: Default> for u8 {}
```
#126054 added some logic to delay emitting E0107 as the names of associated type `T` in the impl header and generic parameter `T` in `trait Foo` match.

But it failed to ensure whether such unexpected associated type bounds are coming from a impl block header. This caused an ICE as the compiler was delaying E0107 for code like:
```rust
trait Trait<Type> {
    type Type;

    fn method(&self) -> impl Trait<Type: '_>;
}
```
because it assumed the associated type bound `Type: '_` is for the generic parameter `Type` in `trait Trait` since the names are same.

This PR adds a check to ensure that E0107 is delayed only in the context of impl block header.
2024-08-06 20:23:39 +02:00
Michael Goulet
79228526bf Cache supertrait outlives of impl header for soundness check 2024-08-06 13:33:32 -04:00
bors
c9687a95a6 Auto merge of #125558 - Amanieu:const-asm-type, r=lcnr
Tweak type inference for `const` operands in inline asm

Previously these would be treated like integer literals and default to `i32` if a type could not be determined. To allow for forward-compatibility with `str` constants in the future, this PR changes type inference to use an unbound type variable instead.

The actual type checking is deferred until after typeck where we still ensure that the final type for the `const` operand is an integer type.

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->
2024-08-06 01:20:43 +00:00
Matthias Krüger
cc61dc8b2d
Rollup merge of #127655 - RalfJung:invalid_type_param_default, r=compiler-errors
turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps`

`````@rust-lang/types````` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error.

However, turns out that outright removing it right now would lead to [tons of crater regressions](https://github.com/rust-lang/rust/pull/127655#issuecomment-2228285460), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this.

Fixes https://github.com/rust-lang/rust/issues/27336 by removing the feature gate (so there's no way to silence the lint even on nightly)
CC https://github.com/rust-lang/rust/issues/36887
2024-08-05 05:40:19 +02:00
Bryanskiy
9b097b2d44 Delegation: second attempt to improve perf 2024-07-31 18:58:04 +03:00
Deadbeef
ec77db83b2 minor effects cleanups 2024-07-31 03:29:10 +00:00
Jonathan Birk
9ce811cd00
Change orphan hint from "only" to "any uncovered type inside..." 2024-07-30 14:55:27 +02:00
bors
1ddedbaa59 Auto merge of #125929 - Bryanskiy:delegation-generics-3, r=petrochenkov
Delegation: support generics for delegation from free functions

(The PR was split from https://github.com/rust-lang/rust/pull/123958, explainer - https://github.com/Bryanskiy/posts/blob/master/delegation%20in%20generic%20contexts.md)

This PR implements generics inheritance from free functions to free functions and trait methods.

#### free functions to free functions:

```rust
fn to_reuse<T: Clone>(_: T) {}

reuse to_reuse as bar;
// desugaring:
fn bar<T: Clone>(x: T) {
  to_reuse(x)
}
```

Generics, predicates and signature are simply copied. Generic arguments in paths are ignored during generics inheritance:

```rust
fn to_reuse<T: Clone>(_: T) {}

reuse to_reuse::<u8> as bar;
// desugaring:
fn bar<T: Clone>(x: T) {
  to_reuse::<u8>(x) // ERROR: mismatched types
}
```

Due to implementation limitations callee path is lowered without modifications. Therefore, it is a compilation error at the moment.

#### free functions to trait methods:

```rust
trait Trait<'a, A> {
    fn foo<'b, B>(&self, x: A, y: B) {...}
}

reuse Trait::foo;
// desugaring:
fn foo<'a, 'b, This: Trait<'a, A>, A, B>(this: &This, x: A, y: B) {
  Trait::foo(this, x, y)
}
```

The inheritance is similar to the previous case but with some corrections:

- `Self` parameter converted into `T: Trait`
- generic parameters need to be reordered so that lifetimes go first

Arguments are similarly ignored.

---

In the future, we plan to  support generic inheritance for delegating from all contexts to all contexts (from free/trait/impl to free/trait /impl). These cases were considered first as the simplest from the implementation perspective.
2024-07-30 10:39:33 +00:00
bors
710ce90fbe Auto merge of #128250 - Amanieu:select_unpredictable, r=nikic
Add `select_unpredictable` to force LLVM to use CMOV

Since https://reviews.llvm.org/D118118, LLVM will no longer turn CMOVs into branches if it comes from a `select` marked with an `unpredictable` metadata attribute.

This PR introduces `core::intrinsics::select_unpredictable` which emits such a `select` and uses it in the implementation of `binary_search_by`.
2024-07-30 03:22:27 +00:00
Veera
3d5bd95558 Fix ICE Caused by Incorrectly Delaying E0107 2024-07-29 21:47:42 -04:00
Bryanskiy
f2f9aab380 Delegation: support generics for delegation from free functions 2024-07-29 20:04:55 +03:00
Matthias Krüger
5551f54aa1
Rollup merge of #128174 - compiler-errors:trait-alias-marker, r=oli-obk
Don't record trait aliases as marker traits

Don't record `#[marker]` on trait aliases, since we use that to check for the (non-presence of) associated types and other things which don't make sense of trait aliases. We already enforce this attr is only applied to a trait.

Also do the same for `#[const_trait]`, which we also enforce is only applied to a trait. This is a drive-by change, but also worthwhile just in case.

Fixes #127222
2024-07-29 17:46:42 +02:00
Nicholas Nethercote
84ac80f192 Reformat use declarations.
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
2024-07-29 08:26:52 +10:00
Amanieu d'Antras
4f78f9fbb0 Force LLVM to use CMOV for binary search
Since https://reviews.llvm.org/D118118, LLVM will no longer turn CMOVs
into branches if it comes from a `select` marked with an `unpredictable`
metadata attribute.

This PR introduces `core::intrinsics::select_unpredictable` which emits
such a `select` and uses it in the implementation of `binary_search_by`.
2024-07-28 17:24:57 +01:00
Slanterns
ec0b354092
stabilize is_sorted 2024-07-28 03:11:54 +08:00
bors
7c2012d0ec Auto merge of #121676 - Bryanskiy:polarity, r=petrochenkov
Support ?Trait bounds in supertraits and dyn Trait under a feature gate

This patch allows `maybe` polarity bounds under a feature gate. The only language change here is that corresponding hard errors are replaced by feature gates. Example:
```rust
#![feature(allow_maybe_polarity)]
...
trait Trait1 : ?Trait { ... } // ok
fn foo(_: Box<(dyn Trait2 + ?Trait)>) {} // ok
fn bar<T: ?Sized + ?Trait>(_: &T) {} // ok
```
Maybe bounds still don't do anything (except for `Sized` trait), however this patch will allow us to [experiment with default auto traits](https://github.com/rust-lang/rust/pull/120706#issuecomment-1934006762).

This is a part of the [MCP: Low level components for async drop](https://github.com/rust-lang/compiler-team/issues/727)
2024-07-26 20:14:16 +00:00
Bryanskiy
fd9d0bfbac Forbid ?Trait bounds repetitions 2024-07-26 16:35:05 +03:00
Trevor Gross
ceae37188b
Rollup merge of #126575 - fmease:update-lint-type_alias_bounds, r=compiler-errors
Make it crystal clear what lint `type_alias_bounds` actually signifies

This is part of my work on https://github.com/rust-lang/rust/labels/F-lazy_type_alias ([tracking issue](#112792)).

---

To recap, the lint `type_alias_bounds` detects bounds on generic parameters and where clauses on (eager) type aliases. These bounds should've never been allowed because they are currently neither enforced[^1] at usage sites of type aliases nor thoroughly checked for correctness at definition sites due to the way type aliases are represented in the compiler. Allowing them was an oversight.

Explicitly label this as a known limitation of the type checker/system and establish the experimental feature `lazy_type_alias` as its eventual proper solution.

Where this becomes a bit tricky (for me as a rustc dev) are the "secondary effects" of these bounds whose existence I sadly can't deny. As a matter of fact, type alias bounds do play some small roles during type checking. However, after a lot of thinking over the last two weeks I've come to the conclusion (not without second-guessing myself though) that these use cases should not trump the fact that these bounds are currently *inherently broken*. Therefore the lint `type_alias_bounds` should and will continue to flag bounds that may have subordinate uses.

The two *known* secondary effects are:

1. They may enable the use of "shorthand" associated type paths `T::Assoc` (as opposed to fully qualified paths `<T as Trait>::Assoc`) where `T` is a type param bounded by some trait `Trait` which defines that assoc ty.
2. They may affect the default lifetime of trait object types passed as a type argument to the type alias. That concept is called (trait) object lifetime default.

The second one is negligible, no question asked. The first one however is actually "kinda nice" (for writability) and comes up in practice from time to time.

So why don't I just special-case trait bounds that "define" shorthand assoc type paths as originally planned in #125709?

1. Starting to permit even a tiny subset of bounds would already be enough to send a signal to users that bounds in type aliases have been legitimized and that they can expect to see type alias bounds in the wild from now on (proliferation). This would be actively misleading and dangerous because those bounds don't behave at all like one would expect, they are *not real*[^2]!
   1. Let's take `type A<T: Trait> = T::Proj;` for example. Everywhere else in the language `T: Trait` means `T: Trait + Sized`. For type aliases, that's not the case though: `T: Trait` and `T: Trait + ?Sized` for that matter do neither mean `T: Trait + Sized` nor `T: Trait + ?Sized` (for both!). Instead, whether `T` requires `Sized` or not entirely depends on the definition of `Trait`[^2]. Namely, whether or not it is bounded by `Sized`.
   2. Given `type A<T: Trait<AssocA = ()>> = T::AssocB;`, while `X: Trait` gets checked given `A<X>` (by virtue of projection wfchecking post alias expansion[^2]), the associated type constraint `AssocA = ()` gets dropped entirely! While we could choose to warn on such cases, it would inevitably lead to a huge pile of special cases.
   3. While it's common knowledge that the body / aliased type / RHS of an (eager) type alias does not get checked for well-formedness, I'm not sure if people would realize that that extends to bounds as well. Namely, `type A<T: Trait<[u8]>> = T::Proj;` compiles even if `Trait`'s generic parameter requires `Sized`. Of course, at usage sites `[u8]: Sized` would still end up getting checked[^2], so it's not a huge problem if you have full control over `A`. However, imagine that `A` was actually part of a public API and was never used inside the defining crate (not unreasonable). In such a scenario, downstream users would be presented with an impossible to use type alias! Remember, bounds may grow arbitrarily complex and nuanced in practice.
   4. Even if we allowed trait bounds that "define" shorthand assoc type paths, we would still need to continue to warn in cases where the assoc ty comes from a supertrait despite the fact that the shorthand syntax can be used: `type A<T: Sub> = T::Assoc;` does compile given `trait Sub: Super {}` and `trait Super { type Assoc; }`. However, `A<X>` does not enforce `X: Sub`, only `X: Super`[^2]. All that to say, type alias bounds are simply not real and we shouldn't pretend they are!
   5. Summarizing the points above, we would be legitimizing bounds that are completely broken!
2. It's infeasible to implement: Due to the lack of `TypeckResults` in `ItemCtxt` (and a way to propagate it to other parts of the compiler), the resolution of type-dependent paths in non-`Body` items (most notably type aliases) is not recoverable from the HIR alone which would be necessary because the information of whether an associated type path (projection) is a shorthand is only present pre&in-HIR and doesn't survive HIR ty lowering. Of course, I could rerun parts of HIR ty lowering inside the lint `type_alias_bounds` (namely, `probe_single_ty_param_bound_for_assoc_ty` which would need to be exposed or alternatively a stripped-down version of it). This likely has a performance impact and introduces complexity. In short, the "benefits" are not worth the costs.

---

* 3rd commit: Update a diagnostic to avoid suggesting type alias bounds
* 4th commit: Flag type alias bounds even if the RHS contains inherent associated types.
  * I started to allow them at some point in the past which was not correct (see commit for details)
* 5th commit: Allow type alias bounds if the RHS contains const projections and GCEs are enabled
  * (and add a `FIXME(generic_const_exprs)` to be revisited before (M)GCE's stabilization)
  * As a matter of fact type alias bounds are enforced in this case because the contained AnonConsts do get checked for well-formedness and crucially they inherit the generics and predicates of their parent item (here: the type alias)
* Remaining commits: Improve the lint `type_alias_bounds` itself

---

Fixes #125789 (sugg diag fix).
Fixes #125709 (wontfix, acknowledgement, sugg diag applic fix).
Fixes #104918 (sugg diag applic fix).
Fixes #100270 (wontfix, acknowledgement, sugg diag applic fix).
Fixes #94398 (true fix).

r? `@compiler-errors` `@oli-obk`

[^1]: From the perspective of the trait solver.
[^2]: Given `type A<T: Trait> = T::Proj;`, the reason why the trait bound "`T: Trait`" gets *seemingly* enforced at usage sites of the type alias `A` is simply because `A<X>` gets expanded to "`<X as Trait>::Proj`" very early on and it's the *expansion* that gets checked for well-formedness, not the type alias reference.
2024-07-26 02:20:28 -04:00
Matthias Krüger
29314e4fca
Rollup merge of #127220 - BoxyUwU:dropck_handle_extra_impl_params, r=compiler-errors
Graciously handle `Drop` impls introducing more generic parameters than the ADT

Follow up to #110577
Fixes #126378
Fixes #126889

## Motivation

A current issue with the way we check drop impls do not specialize any of their generic parameters is that when the `Drop` impl introduces *more* generic parameters than are present on the ADT, we fail to prove any bounds involving those parameters. This can be demonstrated with the following [code on stable](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=139b65e4294634d7286a3282bc61e628) which fails due to the fact that `<T as Trait>::Assoc == U` is not present in `Foo`s `ParamEnv` even though arguably there is no reason it cannot compiler:
```rust
struct Foo<T: Trait>(T);

trait Trait {
    type Assoc;
}

impl<T: Trait<Assoc = U>, U: ?Sized> Drop for Foo<T> {
    //~^ ERROR: `Drop` impl requires `<T as Trait>::Assoc == U` but the struct ...
    fn drop(&mut self) {}
}

fn main() {}
```

I think the motivation for supporting this code is somewhat lacking, it might be useful in practice for deeply nested associated types where you might want to be able to write:
`where T: Trait<Assoc: Other<AnotherAssoc: MoreTrait<YetAnotherAssoc: InnerTrait<Final = U>>>>`
in order to be able to just use `U` in the function body instead of writing out the whole nested associated type. Regardless I don't think there is really any reason to *not* support this code and it is relatively easy to support it.

What I find slightly more compelling is the fact that when defining a const parameter `const N: u8` we desugar that to having a where clause requiring the constant `N` is typed as `u8` (`ClauseKind::ConstArgHasType`). As we *always* desugar const parameters to have these bounds, if we attempt to prove that some const parameter `N` is of type `u8` and there is no bound on `N` in the enviroment that generally indicates usage of an incorrect `ParamEnv` (this has caught a bug already).

Given that, if we write the following code:
```rust
#![feature(associated_const_equality)]
struct Foo<T: Trait>(T);

trait Trait {
    const ASSOC: usize;
}

impl<T: Trait<ASSOC = N>, const N: usize> Drop for Foo<T> {
    fn drop(&mut self) {}
}

fn main() {}
```

The `Drop` impl would have this desugared where clause about `N` being of type `usize`, and if we were to try to prove that where clause in `Foo`'s `ParamEnv` we would ICE as there would not be any `ConstArgHasType` in the environment (which generally indicates improper `ParamEnv` usage. As this is otherwise well formed code (the `T: Trait<ASSOC = N>` causes `N` to be constrained) we have to handle this *somehow* and I believe the only principled way to support this is the changes I have made to `dropck.rs` that would cause these code examples to compiler (Perhaps we could just throw out all `ConstArgHasType` where clauses from the predicates we prove but that makes me nervous even if it might actually be okay).

## The changes

Currently the way `dropck.rs` works is that take the `ParamEnv` of the ADT and instantiate it with the generic arguments used on the self ty of the `impl`. We then instantiate the predicates of the drop impl with the identity params to the impl,  e.g. in the original example `<T as Trait>::Assoc == U` stays as `<T as Trait>::Assoc == U`. We then attempt to prove all the where clauses in the instantiated env of the self type ADT.

This PR changes us to first instantiate the impl with infer vars, then we equate the self type (with infer vars as its generic arguments) with the self type as written by the user. This causes all generic parameters on the impl that are constrained via associated type/const equality bounds to be left as inference variables while all other parameters are still `Ty`/`Const`/`Region`

Finally when instantiating the predicates on the impl, instead of using the identity arguments, we use the list of inference variables of which some have been inferred to the impl parameters. In practice this means that we wind up proving `<T as Trait>::Assoc == ?x` which can succeed just fine. In the const generics example we would wind up trying to prove `ConstArgHasType(?x: usize)` instead of `ConstArgHasType(N: usize)` which avoids the ICE as it is expected to encounter goals of the form `?x: usize`.

At a higher level the way I justify/think about this is that as we are proving goals in the environment of the ADT (`Foo` in the above examples), we do not expect to encounter generic parameters from a different environment so we must "deal with them" somehow. In this PR we handle them by replacing them with inference variables as they should either *actually* be unconstrained (and we will error later) or they are constrained to be equal to some associated type/const.

To go along with this it would be nice if we were not instantiating the adt's env with the generic arguments to the ADT in the `Drop` impl as it would make it clearer we are proving bounds in the adt's env instead of the `Drop` impl's. Instead we would map the predicates on the drop impl to be valid in the environment of the adt. In practice this causes diagnostic regressions as all of the generic parameters in errors refer to the ones defined on the adt; attempting to map these back to the ones on the impl, while possible, is involved as writing a `TypeFolder` over `FulfillmentError` is non trivial.

## Edge cases

There are some subtle interactions here:

One is that we should not allow `<T as Trait>::Assoc == U` to be present on the `Drop` if `U` is constrained by the self type of the impl and the bound is not present in the ADT's environment. demonstrated with the [following code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=af839e2c3e43e03a624825c58af84dff):
```rust
trait Trait {
    type Assoc;
}

struct Foo<T: Trait, U: ?Sized>(T, U);

impl<T: Trait<Assoc = U>, U: ?Sized> Drop for Foo<T, U> {
    //~^ ERROR: `Drop` impl requires `<T as Trait>::Assoc == U`
    fn drop(&mut self) {}
}

fn main() {}
```
This is tested at `tests/ui/dropck/constrained_by_assoc_type_equality_and_self_ty.rs`.

Another weirdness is that we permit the following code to compile now:
```rust
struct Foo<T>(T);

impl<'a, T: 'a> Drop for Foo<T> {
    fn drop(&mut self) {}
}
```
This is caused by the fact that we permit unconstrained lifetime parameters in trait implementations as long as they are not used in associated types (so we do not wind up erroring on this code like we perhaps ought to), combined with the fact that as we are now proving `T: '?x` instead of `T: 'a` which allows proving the bound via `'?x= 'empty` wheras previously it would have failed.

This is tested as part of `tests/ui/dropck/reject-specialized-drops-8142.rs`.

---

r? `@compiler-errors`
2024-07-26 00:57:21 +02:00
Folkert
be66415e11 use ErrorGuaranteed from emit 2024-07-25 20:12:14 +01:00
Amanieu d'Antras
d4ca1ac8b9 rustfmt 2024-07-25 20:12:14 +01:00
Folkert de Vries
c77b56901f Apply suggestions from code review
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2024-07-25 20:12:14 +01:00
Folkert
97738e1b86 apply fix suggested by lcnr 2024-07-25 20:12:14 +01:00
Amanieu d'Antras
4d747128eb Tweak type inference for const operands in inline asm
Previously these would be treated like integer literals and default to
`i32` if a type could not be determined. To allow for
forward-compatibility with `str` constants in the future, this PR
changes type inference to use an unbound type variable instead.

The actual type checking is deferred until after typeck where we still
ensure that the final type for the `const` operand is an integer type.
2024-07-25 20:12:14 +01:00
Bryanskiy
2a73553513 Support ?Trait bounds in supertraits and dyn Trait under a feature gate 2024-07-25 20:53:33 +03:00
Michael Goulet
12f1463b7e Don't record trait aliases as marker traits 2024-07-25 00:38:50 -04:00
León Orell Valerian Liehr
02a2f02727
Suggest full trait ref (with placeholders) on unresolved assoc tys 2024-07-23 01:26:25 +02:00
León Orell Valerian Liehr
3c8b108512
Inside eager ty aliases on unresolved assoc tys suggest fully qualifying instead of restricting their self ty 2024-07-23 01:26:24 +02:00
León Orell Valerian Liehr
898448ca58
HIR ty lowering: Refactor the way the projectee ("QSelf") gets passed to diagnostics 2024-07-23 01:23:54 +02:00
León Orell Valerian Liehr
ef121f28d8
Suggesting an available assoc item is always maybe-incorrect 2024-07-23 01:18:18 +02:00
Esteban Küber
921de9d8ea Revert suggestion verbosity change 2024-07-22 22:51:53 +00:00
Esteban Küber
b30fdec5fb On generic and lifetime removal suggestion, do not leave behind stray , 2024-07-22 22:04:49 +00:00
Esteban Küber
5c2b36a21c Change suggestion message wording 2024-07-22 22:04:49 +00:00
Esteban Küber
c807ac0340 Use verbose suggestion for "wrong # of generics" 2024-07-22 22:04:49 +00:00
bors
20f23abbec Auto merge of #128041 - compiler-errors:uplift-errors-into-trait-sel, r=lcnr
Uplift most type-system related error reporting from `rustc_infer` to `rustc_trait_selection`

Completes the major part of #127492. The only cleanup that's needed afterwards is to actually use normalization in favor of the callback where needed, and deleting `can_eq_shallow`.

r? lcnr

Sorry for the large diff! Would prefer if comments can be handled in a follow-up (unless they're absolutely dealbreakers) because it seems bitrotty to let this sit.
2024-07-22 15:06:18 +00:00
Michael Goulet
ce8a625092 Move all error reporting into rustc_trait_selection 2024-07-21 22:34:35 -04:00
Michael Goulet
5accaf3af4 Make type_var_origin take a vid 2024-07-21 22:33:15 -04:00
Jubilee
2ef7699a1a
Rollup merge of #128020 - compiler-errors:nlb-no-const, r=BoxyUwU
Just totally fully deny late-bound consts

Kinda don't care about supporting this until we have where clauses on binders. They're super busted and should be reworked in due time, and they are approximately 100% useless until then 😸

Fixes #127970
Fixes #127009

r? ``@BoxyUwU``
2024-07-21 17:44:29 -07:00
bors
9629b90b3f Auto merge of #127722 - BoxyUwU:new_adt_const_params_limitations, r=compiler-errors
Forbid borrows and unsized types from being used as the type of a const generic under `adt_const_params`

Fixes #112219
Fixes #112124
Fixes #112125

### Motivation

Currently the `adt_const_params` feature allows writing `Foo<const N: [u8]>` this is entirely useless as it is not possible to write an expression which evaluates to a type that is not `Sized`. In order to actually use unsized types in const generics they are typically written as `const N: &[u8]` which *is* possible to provide a value of.

Unfortunately allowing the types of const parameters to contain references is non trivial (#120961) as it introduces a number of difficult questions about how equality of references in the type system should behave. References in the types of const generics is largely only useful for using unsized types in const generics.

This PR introduces a new feature gate `unsized_const_parameters` and moves support for `const N: [u8]` and `const N: &...` from `adt_const_params` into it. The goal here hopefully is to experiment with allowing `const N: [u8]` to work without references and then eventually completely forbid references in const generics.

Splitting this out into a new feature gate means that stabilization of `adt_const_params` does not have to resolve #120961 which is the only remaining "big" blocker for the feature. Remaining issues after this are a few ICEs and naming bikeshed for `ConstParamTy`.

### Implementation

The implementation is slightly subtle here as we would like to ensure that a stabilization of `adt_const_params` is forwards compatible with any outcome of `unsized_const_parameters`. This is inherently tricky as we do not support unstable trait implementations and we determine whether a type is valid as the type of a const parameter via a trait bound.

There are a few constraints here:
- We would like to *allow for the possibility* of adding a `Sized` supertrait to `ConstParamTy` in the event that we wind up opting to not support unsized types and instead requiring people to write the 'sized version', e.g. `const N: [u8; M]` instead of `const N: [u8]`.
- Crates should be able to enable `unsized_const_parameters` and write trait implementations of `ConstParamTy` for `!Sized` types without downstream crates that only enable `adt_const_params` being able to observe this (required for std to be able to `impl<T> ConstParamTy for [T]`

Ultimately the way this is accomplished is via having two traits (sad), `ConstParamTy` and `UnsizedConstParamTy`. Depending on whether `unsized_const_parameters` is enabled or not we change which trait is used to check whether a type is allowed to be a const parameter.

Long term (when stabilizing `UnsizedConstParamTy`) it should be possible to completely merge these traits (and derive macros), only having a single `trait ConstParamTy` and `macro ConstParamTy`.

Under `adt_const_params` it is now illegal to directly refer to `ConstParamTy` it is only used as an internal impl detail by `derive(ConstParamTy)` and checking const parameters are well formed. This is necessary in order to ensure forwards compatibility with all possible future directions for `feature(unsized_const_parameters)`.

Generally the intuition here should be that `ConstParamTy` is the stable trait that everything uses, and `UnsizedConstParamTy` is that plus unstable implementations (well, I suppose `ConstParamTy` isn't stable yet :P).
2024-07-21 05:36:21 +00:00
Michael Goulet
3862095bd2 Just totally fully deny late-bound consts 2024-07-20 19:45:24 -04:00
bors
73a228116a Auto merge of #127658 - compiler-errors:precise-capturing-rustdoc-cross, r=fmease
Add cross-crate precise capturing support to rustdoc

Follow-up to #127632. Fixes #127228.

r? `@fmease`

Tracking:
* https://github.com/rust-lang/rust/issues/123432
2024-07-20 11:03:35 +00:00
Matthias Krüger
cd8c5f78ec
Rollup merge of #127980 - nyurik:compiler-refs, r=oli-obk
Avoid ref when using format! in compiler

Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing).  Inlining format args prevents accidental `&` misuse.

See also https://github.com/rust-lang/rust-clippy/issues/10851
2024-07-20 07:13:45 +02:00
Yuri Astrakhan
aef0e346de Avoid ref when using format! in compiler
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing).  Inlining format args prevents accidental `&` misuse.
2024-07-19 14:52:07 -04:00
Matthias Krüger
115b086850
Rollup merge of #127976 - fmease:lta-cyclic-bivariant-param-better-err, r=compiler-errors
Lazy type aliases: Diagostics: Detect bivariant ty params that are only used recursively

Follow-up to errs's #127871. Extends the logic to cover LTAs, too, not just ADTs.
This change only takes effect with the next-gen solver enabled as cycle errors like
the one we have here are fatal in the old solver. That's my explanation anyways.

r? compiler-errors
2024-07-19 20:03:58 +02:00
Matthias Krüger
a2c99cf87c
Rollup merge of #127966 - oli-obk:structured_diag, r=compiler-errors
Use structured suggestions for unconstrained generic parameters on impl blocks

I did not deduplicate with `UnusedGenericParameter`, because in contrast to type declarations, just using a generic parameter in an impl isn't enough, it must be used with the right variance and not just as part of a projection.
2024-07-19 20:03:57 +02:00
Matthias Krüger
3b20150b48
Rollup merge of #127814 - folkertdev:c-cmse-nonsecure-call-error-messages, r=oli-obk
`C-cmse-nonsecure-call`: improved error messages

tracking issue: #81391
issue for the error messages (partially implemented by this PR): #81347
related, in that it also deals with CMSE: https://github.com/rust-lang/rust/pull/127766

When using the `C-cmse-nonsecure-call` ABI, both the arguments and return value must be passed via registers. Previously, when violating this constraint, an ugly LLVM error would be shown. Now, the rust compiler itself will print a pretty message and link to more information.
2024-07-19 20:03:56 +02:00
León Orell Valerian Liehr
756459ed85
LTA: Diag: Detect bivariant ty params that are only used recursively 2024-07-19 18:53:40 +02:00
Oli Scherer
a0db06bdeb Use structured suggestions for unconstrained generic parameters on impl blocks 2024-07-19 14:21:56 +00:00
bors
11e57241f1 Auto merge of #127956 - tgross35:rollup-8ten7pk, r=tgross35
Rollup of 7 pull requests

Successful merges:

 - #121533 (Handle .init_array link_section specially on wasm)
 - #127825 (Migrate `macos-fat-archive`, `manual-link` and `archive-duplicate-names` `run-make` tests to rmake)
 - #127891 (Tweak suggestions when using incorrect type of enum literal)
 - #127902 (`collect_tokens_trailing_token` cleanups)
 - #127928 (Migrate `lto-smoke-c` and `link-path-order` `run-make` tests to rmake)
 - #127935 (Change `binary_asm_labels` to only fire on x86 and x86_64)
 - #127953 ([compiletest] Search *.a when getting dynamic libraries on AIX)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-19 11:08:02 +00:00
bors
8c3a94a1c7 Auto merge of #125915 - camelid:const-arg-refactor, r=BoxyUwU
Represent type-level consts with new-and-improved `hir::ConstArg`

### Summary

This is a step toward `min_generic_const_exprs`. We now represent all const
generic arguments using an enum that differentiates between const *paths*
(temporarily just bare const params) and arbitrary anon consts that may perform
computations. This will enable us to cleanly implement the `min_generic_const_args`
plan of allowing the use of generics in paths used as const args, while
disallowing their use in arbitrary anon consts. Here is a summary of the salient
aspects of this change:

- Add `current_def_id_parent` to `LoweringContext`

  This is needed to track anon const parents properly once we implement
  `ConstArgKind::Path` (which requires moving anon const def-creation
  outside of `DefCollector`).

- Create `hir::ConstArgKind` enum with `Path` and `Anon` variants. Use it in the
  existing `hir::ConstArg` struct, replacing the previous `hir::AnonConst` field.

- Use `ConstArg` for all instances of const args. Specifically, use it instead
  of `AnonConst` for assoc item constraints, array lengths, and const param
  defaults.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at https://github.com/rust-lang/rust/issues/127009.

### Followup items post-merge

- Use `ConstArgKind::Path` for all const paths, not just const params.
- Fix (no github dont close this issue) #127009
- If a path in generic args doesn't resolve as a type, try to resolve as a const
  instead (do this in rustc_resolve). Then remove the special-casing from
  `rustc_ast_lowering`, so that all params will automatically be lowered as
  `ConstArgKind::Path`.
- (?) Consider making `const_evaluatable_unchecked` a hard error, or at least
  trying it in crater

r? `@BoxyUwU`
2024-07-19 08:44:51 +00:00
Trevor Gross
fc6e34f38f
Rollup merge of #127891 - estebank:enum-type-sugg, r=estebank
Tweak suggestions when using incorrect type of enum literal

More accurate suggestions when writing wrong style of enum variant literal:

```
error[E0533]: expected value, found struct variant `E::Empty3`
  --> $DIR/empty-struct-braces-expr.rs:18:14
   |
LL |     let e3 = E::Empty3;
   |              ^^^^^^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     let e3 = E::Empty3 {};
   |                        ++
```
```
error[E0533]: expected value, found struct variant `E::V`
  --> $DIR/struct-literal-variant-in-if.rs:10:13
   |
LL |     if x == E::V { field } {}
   |             ^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     if x == (E::V { field }) {}
   |             +              +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
  --> $DIR/suggestion-highlights.rs:15:5
   |
LL |     Unit,
   |     ---- enum variant `Enum::Unit` defined here
...
LL |     Enum::Unit();
   |     ^^^^^^^^^^--
   |     |
   |     call expression requires function
   |
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
   |
LL -     Enum::Unit();
LL +     Enum::Unit;
   |
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
  --> $DIR/suggestion-highlights.rs:36:11
   |
LL | enum Enum {
   | --------- variant or associated item `tuple` not found for this enum
...
LL |     Enum::tuple;
   |           ^^^^^ variant or associated item not found in `Enum`
   |
help: there is a variant with a similar name
   |
LL |     Enum::Tuple(/* i32 */);
   |           ~~~~~~~~~~~~~~~~;
   |
```

Tweak "field not found" suggestion when giving struct literal for tuple struct type:

```
error[E0560]: struct `S` has no field named `x`
  --> $DIR/nested-non-tuple-tuple-struct.rs:8:19
   |
LL | pub struct S(f32, f32);
   |            - `S` defined here
...
LL |     let _x = (S { x: 1.0, y: 2.0 }, S { x: 3.0, y: 4.0 });
   |                   ^ field does not exist
   |
help: `S` is a tuple struct, use the appropriate syntax
   |
LL |     let _x = (S(/* f32 */, /* f32 */), S { x: 3.0, y: 4.0 });
   |               ~~~~~~~~~~~~~~~~~~~~~~~
2024-07-19 03:27:48 -05:00
Trevor Gross
986d6bf9fb
Rollup merge of #121533 - ratmice:wasm_init_fini_array, r=nnethercote
Handle .init_array link_section specially on wasm

Given that wasm-ld now has support for [.init_array](8f2bd8ae68/llvm/lib/MC/WasmObjectWriter.cpp (L1852)), it appears we can easily implement that section by falling through to the normal path rather than taking the typical custom_section path for wasm.

The wasm-ld appears to have a bunch of limitations. Only one static with the `link_section` in a crate or else you hit the fatal error in the link above "only one .init_array section fragment supported". They do not get merged.

You can still call multiple constructors by setting it to an array.

```
unsafe extern "C" fn ctor() {
    println!("foo");
}
#[used]
#[link_section = ".init_array"]
static FOO: [unsafe extern "C" fn(); 2] = [ctor, ctor];
```

Another issue appears to be that if crate *A* depends on crate *B*, but *A* doesn't call any symbols from *B* and *B* doesn't `#[export_name = ...]` any symbols, then crate *B*'s constructor will not be called.  The workaround to this is to provide an exported symbol in crate *B*.
2024-07-19 03:27:46 -05:00
Matthias Krüger
d1250bc1d5
Rollup merge of #127929 - estebank:addr_of, r=compiler-errors
Use more accurate span for `addr_of!` suggestion

Use a multipart suggestion instead of a single whole-span replacement:

```
error[E0796]: creating a shared reference to a mutable static
  --> $DIR/reference-to-mut-static-unsafe-fn.rs:10:18
   |
LL |         let _y = &X;
   |                  ^^ shared reference to mutable static
   |
   = note: this shared reference has lifetime `'static`, but if the static ever gets mutated, or a mutable reference is created, then any further use of this shared reference is Undefined Behavior
help: use `addr_of!` instead to create a raw pointer
   |
LL |         let _y = addr_of!(X);
   |                  ~~~~~~~~~ +
```
2024-07-18 23:05:24 +02:00
Matthias Krüger
65de5d0472
Rollup merge of #127871 - compiler-errors:recursive, r=estebank
Mention that type parameters are used recursively on bivariance error

Right now when a type parameter is used recursively, even with indirection (so it has a finite size) we say that the type parameter is unused:

```
struct B<T>(Box<B<T>>);
```

This is confusing, because the type parameter is *used*, it just doesn't have its variance constrained. This PR tweaks that message to mention that it must be used *non-recursively*.

Not sure if we should actually mention "variance" here, but also I'd somewhat prefer we don't keep the power users in the dark w.r.t the real underlying issue, which is that the variance isn't constrained. That technical detail is reserved for a note, though.

cc `@fee1-dead`

Fixes #118976
Fixes #26283
Fixes #53191
Fixes #105740
Fixes #110466
2024-07-18 23:05:22 +02:00
Esteban Küber
abf92c049d Use more accurate span for addr_of! suggestion
Use a multipart suggestion instead of a single whole-span replacement:

```
error[E0796]: creating a shared reference to a mutable static
  --> $DIR/reference-to-mut-static-unsafe-fn.rs:10:18
   |
LL |         let _y = &X;
   |                  ^^ shared reference to mutable static
   |
   = note: this shared reference has lifetime `'static`, but if the static ever gets mutated, or a mutable reference is created, then any further use of this shared reference is Undefined Behavior
help: use `addr_of!` instead to create a raw pointer
   |
LL |         let _y = addr_of!(X);
   |                  ~~~~~~~~~ +
```
2024-07-18 18:39:20 +00:00
Esteban Küber
ec7a188f16 More accurate suggestions when writing wrong style of enum variant literal
```
error[E0533]: expected value, found struct variant `E::Empty3`
  --> $DIR/empty-struct-braces-expr.rs:18:14
   |
LL |     let e3 = E::Empty3;
   |              ^^^^^^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     let e3 = E::Empty3 {};
   |                        ++
```
```
error[E0533]: expected value, found struct variant `E::V`
  --> $DIR/struct-literal-variant-in-if.rs:10:13
   |
LL |     if x == E::V { field } {}
   |             ^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     if x == (E::V { field }) {}
   |             +              +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
  --> $DIR/suggestion-highlights.rs:15:5
   |
LL |     Unit,
   |     ---- enum variant `Enum::Unit` defined here
...
LL |     Enum::Unit();
   |     ^^^^^^^^^^--
   |     |
   |     call expression requires function
   |
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
   |
LL -     Enum::Unit();
LL +     Enum::Unit;
   |
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
  --> $DIR/suggestion-highlights.rs:36:11
   |
LL | enum Enum {
   | --------- variant or associated item `tuple` not found for this enum
...
LL |     Enum::tuple;
   |           ^^^^^ variant or associated item not found in `Enum`
   |
help: there is a variant with a similar name
   |
LL |     Enum::Tuple(/* i32 */);
   |           ~~~~~~~~~~~~~~~~;
   |
```
2024-07-18 18:20:35 +00:00
Folkert
c2894a4297
improve error reporting 2024-07-18 14:32:10 +02:00
Folkert
6b6b8422ba
remove cmse validation from rustc_codegen_ssa
it was moved to hir_analysis in the previous commit
2024-07-18 12:42:43 +02:00
Folkert
7b63734961
move CMSE validation to hir_analysis 2024-07-18 12:42:40 +02:00
Matthias Krüger
d78be31a2a
Rollup merge of #127888 - estebank:type-param-sugg, r=compiler-errors
More accurate span for type parameter suggestion

After:

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
   |
LL | impl Foo<T: Default> for String {}
   |          ^^^^^^^^^^ associated item constraint not allowed here
   |
help: declare the type parameter right after the `impl` keyword
   |
LL - impl Foo<T: Default> for String {}
LL + impl<T: Default> Foo<T> for String {}
   |
```

Before:

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
   |
LL | impl Foo<T: Default> for String {}
   |          ^^^^^^^^^^ associated item constraint not allowed here
   |
help: declare the type parameter right after the `impl` keyword
   |
LL | impl<T: Default> Foo<T> for String {}
   |     ++++++++++++     ~
```
2024-07-18 08:09:02 +02:00
Matthias Krüger
a13d7dbecf
Rollup merge of #127878 - estebank:assoc-item-removal, r=fmease
Fix associated item removal suggestion

We were previously telling people to write what was already there, instead of removal (treating it as a `help`). We now properly suggest to remove the code that needs to be removed.

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/E0229.rs:13:25
   |
LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
   |                         ^^^^^^^ associated item constraint not allowed here
   |
help: consider removing this associated item binding
   |
LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
LL + fn baz<I>(x: &<I as Foo>::A) {}
   |
```
2024-07-18 08:09:01 +02:00
Noah Lev
c8457e60e8 Remove some unintended changes to imports 2024-07-17 20:31:37 -07:00
Michael Goulet
c02d0de871 Account for structs that have unused params in nested types in fields 2024-07-17 21:12:12 -04:00
Esteban Küber
be9d961884 More accurate span for type parameter suggestion
After:

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
   |
LL | impl Foo<T: Default> for String {}
   |          ^^^^^^^^^^ associated item constraint not allowed here
   |
help: declare the type parameter right after the `impl` keyword
   |
LL - impl Foo<T: Default> for String {}
LL + impl<T: Default> Foo<T> for String {}
   |
```

Before:

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/impl-block-params-declared-in-wrong-spot-issue-113073.rs:3:10
   |
LL | impl Foo<T: Default> for String {}
   |          ^^^^^^^^^^ associated item constraint not allowed here
   |
help: declare the type parameter right after the `impl` keyword
   |
LL | impl<T: Default> Foo<T> for String {}
   |     ++++++++++++     ~
```
2024-07-18 00:10:48 +00:00
Esteban Küber
e38032fb3a Fix associated item removal suggestion
We were previously telling people to write what was already there, instead of removal.

```
error[E0229]: associated item constraints are not allowed here
  --> $DIR/E0229.rs:13:25
   |
LL | fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
   |                         ^^^^^^^ associated item constraint not allowed here
   |
help: consider removing this associated item binding
   |
LL - fn baz<I>(x: &<I as Foo<A = Bar>>::A) {}
LL + fn baz<I>(x: &<I as Foo>::A) {}
   |
```
2024-07-17 21:30:40 +00:00
Michael Goulet
a0a251a688 Account for self ty alias 2024-07-17 16:48:17 -04:00
Michael Goulet
3716a3fd31 Mention that type parameters are used recursively 2024-07-17 15:57:38 -04:00
Michael Goulet
da2054f389 Add cross-crate precise capturing support to rustdoc 2024-07-17 11:06:10 -04:00
Boxy
d0c11bf6e3 Split part of adt_const_params into unsized_const_params 2024-07-17 11:01:29 +01:00
Boxy
42cc42b942 Forbid !Sized types and references 2024-07-17 11:01:29 +01:00
Noah Lev
37ed7a4438 Add ConstArgKind::Path and make ConstArg its own HIR node
This is a very large commit since a lot needs to be changed in order to
make the tests pass. The salient changes are:

- `ConstArgKind` gets a new `Path` variant, and all const params are now
  represented using it. Non-param paths still use `ConstArgKind::Anon`
  to prevent this change from getting too large, but they will soon use
  the `Path` variant too.

- `ConstArg` gets a distinct `hir_id` field and its own variant in
  `hir::Node`. This affected many parts of the compiler that expected
  the parent of an `AnonConst` to be the containing context (e.g., an
  array repeat expression). They have been changed to check the
  "grandparent" where necessary.

- Some `ast::AnonConst`s now have their `DefId`s created in
  rustc_ast_lowering rather than `DefCollector`. This is because in some
  cases they will end up becoming a `ConstArgKind::Path` instead, which
  has no `DefId`. We have to solve this in a hacky way where we guess
  whether the `AnonConst` could end up as a path const since we can't
  know for sure until after name resolution (`N` could refer to a free
  const or a nullary struct). If it has no chance as being a const
  param, then we create a `DefId` in `DefCollector` -- otherwise we
  decide during ast_lowering. This will have to be updated once all path
  consts use `ConstArgKind::Path`.

- We explicitly use `ConstArgHasType` for array lengths, rather than
  implicitly relying on anon const type feeding -- this is due to the
  addition of `ConstArgKind::Path`.

- Some tests have their outputs changed, but the changes are for the
  most part minor (including removing duplicate or almost-duplicate
  errors). One test now ICEs, but it is for an incomplete, unstable
  feature and is now tracked at #127009.
2024-07-16 19:27:28 -07:00
Noah Lev
1c49d406b6 Use ConstArg for const param defaults
Now everything that actually affects the type system (i.e., excluding
const blocks, enum variant discriminants, etc.) *should* be using
`ConstArg`.
2024-07-16 19:27:28 -07:00
Noah Lev
67fccb7045 Use ConstArg for array lengths 2024-07-16 19:27:28 -07:00
Noah Lev
8818708a31 Use ConstArg for assoc item constraints 2024-07-16 19:27:28 -07:00
Noah Lev
e7c85cb1e0 Setup ty::Const functions for ConstArg 2024-07-16 19:27:28 -07:00
Noah Lev
11b144aa98 hir: Create hir::ConstArgKind enum
This will allow lowering const params to a dedicated enum variant, rather
than to an `AnonConst` that is later examined during `ty` lowering.
2024-07-16 19:27:28 -07:00
Michael Goulet
e86fbcfd70 Move rustc_infer::infer::error_reporting to rustc_infer::error_reporting::infer 2024-07-15 20:16:12 -04:00
Ralf Jung
9d9b55cd2b make invalid_type_param_default lint show up in cargo future-compat reports
and remove the feature gate that silenced the lint
2024-07-15 22:05:45 +02:00
Camille GILLOT
b494d98b18 find_field does not need to be a query. 2024-07-14 13:25:25 +00:00
bors
8c39ac9ecc Auto merge of #127575 - chenyukang:yukang-fix-struct-fields-ice, r=compiler-errors
Avoid "no field" error and ICE on recovered ADT variant

Fixes https://github.com/rust-lang/rust/issues/126744
Fixes https://github.com/rust-lang/rust/issues/126344, a more general fix compared with https://github.com/rust-lang/rust/pull/127426

r? `@oli-obk`

From `@compiler-errors` 's comment https://github.com/rust-lang/rust/pull/127502#discussion_r1669538204
Seems most of the ADTs don't have taint, so maybe it's not proper to change `TyCtxt::type_of` query.
2024-07-11 03:12:38 +00:00
yukang
07e6dd95bd report pat no field error no recoverd struct variant 2024-07-11 00:18:47 +08:00
Matthias Krüger
a7fe30d82a
Rollup merge of #127094 - Borgerr:E0191-suggestion-correction, r=fmease
E0191 suggestion correction, inserts turbofish

closes #91997
2024-07-10 17:54:26 +02:00
Ashton Hunt
7c88bda1cb E0191 suggestion correction, inserts turbofish without dyn (#91997) 2024-07-09 17:21:31 -06:00
bors
7d640b670e Auto merge of #127358 - oli-obk:taint_itemctxt, r=fmease
Automatically taint when reporting errors from ItemCtxt

This isn't very robust yet, as you need to use `itemctxt.dcx()` instead of `tcx.dcx()` for it to take effect, but it's at least more convenient than sprinkling `set_tainted_by_errors` calls in individual places.

based on https://github.com/rust-lang/rust/pull/127357

r? `@fmease`
2024-07-09 23:03:01 +00:00
bors
a2d58197a7 Auto merge of #127493 - compiler-errors:crate-level-import, r=lcnr
Move trait selection error reporting to its own top-level module

This effectively moves `rustc_trait_selection::traits::error_reporting` to `rustc_trait_selection::error_reporting::traits`. There are only a couple of actual changes to the code, like moving the `pretty_impl_header` fn out of the specialization module for privacy reasons.

This is quite pointless on its own, but having `error_reporting` as a top-level module in `rustc_trait_selection` is very important to make sure we have a meaningful file structure for when we move **type** error reporting (and region error reporting, with which it's incredibly entangled currently) into `rustc_trait_selection`. I've opened a tracking issue here: #127492

r? lcnr
2024-07-09 11:23:13 +00:00
Oli Scherer
aece06482e Remove HirTyLowerer::set_tainted_by_errors, since it is now redundant 2024-07-09 07:44:17 +00:00
Oli Scherer
fd9a92542c Automatically taint when reporting errors from ItemCtxt 2024-07-09 07:44:17 +00:00
bors
5be2ec7245 Auto merge of #127200 - fee1-dead-contrib:trait_def_const_trait, r=compiler-errors
Add `constness` to `TraitDef`

Second attempt at fixing the regression @ https://github.com/rust-lang/rust/pull/120639#issuecomment-2198373716

r? project-const-traits
2024-07-09 06:51:35 +00:00
Michael Goulet
fe4c995ccb Move trait selection error reporting to its own top-level module 2024-07-08 16:04:47 -04:00
Oli Scherer
af9ab1b026 Remove structured_errors module 2024-07-08 19:29:55 +00:00
Oli Scherer
2f0368c902 Remove StructuredDiag 2024-07-08 19:29:55 +00:00
Oli Scherer
9e7918f70e Remove another StructuredDiag impl 2024-07-08 19:29:55 +00:00
许杰友 Jieyou Xu (Joe)
73593b9aca
Rollup merge of #127452 - fee1-dead-contrib:fx-intrinsic-counting, r=fmease
Fix intrinsic const parameter counting with `effects`

r? project-const-traits
2024-07-08 13:04:34 +08:00
许杰友 Jieyou Xu (Joe)
ffb93361b4
Rollup merge of #127439 - compiler-errors:uplift-elaborate, r=lcnr
Uplift elaboration into `rustc_type_ir`

Allows us to deduplicate and consolidate elaboration (including these stupid elaboration duplicate fns i added for pretty printing like 3 years ago) so I'm pretty hyped about this change :3

r? lcnr
2024-07-08 13:04:33 +08:00
许杰友 Jieyou Xu (Joe)
928d71f17b
Rollup merge of #127437 - compiler-errors:uplift-trait-ref-is-knowable, r=lcnr
Uplift trait ref is knowable into `rustc_next_trait_solver`

Self-explanatory. Eliminates one more delegate method.

r? lcnr cc ``@fmease``
2024-07-08 13:04:32 +08:00
bors
89aefb9c53 Auto merge of #127172 - compiler-errors:full-can_eq-everywhere, r=lcnr
Make `can_eq` process obligations (almost) everywhere

Move `can_eq` to an extension trait on `InferCtxt` in `rustc_trait_selection`, and change it so that it processes obligations. This should strengthen it to be more accurate in some cases, but is most important for the new trait solver which delays relating aliases to `AliasRelate` goals. Without this, we always basically just return true when passing aliases to `can_eq`, which can lead to weird errors, for example #127149.

I'm not actually certain if we should *have* `can_eq` be called on the good path. In cases where we need `can_eq`, we probably should just be using a regular probe.

Fixes #127149

r? lcnr
2024-07-07 23:03:48 +00:00
Michael Goulet
a982471e07 Uplift trait_ref_is_knowable and friends 2024-07-07 11:10:32 -04:00
Michael Goulet
b2e30bdec4 Add fundamental to trait def 2024-07-07 11:10:32 -04:00
Deadbeef
4f54193ccf Fix intrinsic const parameter counting with effects 2024-07-07 11:30:03 +00:00
Michael Goulet
58aad3c72c iter_identity is a better name 2024-07-07 00:12:35 -04:00
Michael Goulet
cc6c5de39d Import via rustc_type_ir::outlives
We could use rustc_middle::ty::outlives I guess?
2024-07-06 10:47:46 -04:00
Jubilee
853148752f
Rollup merge of #127392 - estebank:arg-type, r=jieyouxu
Use verbose suggestion for changing arg type
2024-07-05 23:23:36 -07:00
Esteban Küber
75692056e1 Use verbose suggestion for changing arg type 2024-07-05 20:58:33 +00:00
Michael Goulet
465e7d546e Rework receiver_is_valid 2024-07-05 11:59:54 -04:00
Michael Goulet
fb8d5f1e13 Actually just make can_eq process obligations (almost) everywhere 2024-07-05 11:59:54 -04:00
Michael Goulet
fdde66acee Process alias-relate obligations when proving receiver_is_valid 2024-07-05 11:59:52 -04:00
Oli Scherer
7dca61b68b Use ControlFlow results for visitors that are only looking for a single value 2024-07-05 15:00:40 +00:00
Matthias Krüger
dd42f7a0a6
Rollup merge of #127319 - oli-obk:fail2taint, r=compiler-errors
Remove a use of `StructuredDiag`, which is incompatible with automatic error tainting and error translations

fixes #127219

I want to remove all of `StructuredDiag`, but it's a bit more involved as it is also used from the `ItemCtxt`, which doesn't support tainting yet.
2024-07-04 18:16:26 +02:00
Oli Scherer
0d54fe0d02 Remove a use of StructuredDiag, which is incompatible with automatic error tainting and error translations 2024-07-04 12:20:51 +00:00
Esteban Küber
f63d2bc657 Better suggestion span for missing type parameter 2024-07-04 02:41:13 +00:00
Deadbeef
46af987072 Add constness to TraitDef 2024-07-03 15:37:34 +00:00
Boxy
6a00008276 Rewrite dropck 2024-07-02 02:30:38 +01:00
Matthias Krüger
b067ee82f8
Rollup merge of #127181 - BoxyUwU:dump_def_parents, r=compiler-errors
Introduce a `rustc_` attribute to dump all the `DefId` parents of a `DefId`

We've run into a bunch of issues with anon consts having the wrong generics and it would have been incredibly helpful to be able to quickly slap a `rustc_` attribute to check what `tcx.parent(` will return on the relevant DefIds.

I wasn't sure of a better way to make this work for anon consts than requiring the attribute to be on the enclosing item and then walking the inside of it to look for any anon consts. This particular method will honestly break at some point when we stop having a `DefId` available for anon consts in hir but that's for another day...

r? ``@compiler-errors``
2024-07-01 08:53:07 +02:00
Boxy
552794410a add rustc_dump_def_parents attribute 2024-06-30 19:31:21 +01:00
Deadbeef
34ae56de35 Make feature(effects) require -Znext-solver 2024-06-30 17:08:10 +00:00
bors
716752ebe6 Auto merge of #127133 - matthiaskrgr:rollup-jxkp3yf, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #123237 (Various rustc_codegen_ssa cleanups)
 - #126960 (Improve error message in tidy)
 - #127002 (Implement `x perf` as a separate tool)
 - #127081 (Add a run-make test that LLD is not being used by default on the x64 beta/stable channel)
 - #127106 (Improve unsafe extern blocks diagnostics)
 - #127110 (Fix a error suggestion for E0121 when using placeholder _ as return types on function signature.)
 - #127114 (fix: prefer `(*p).clone` to `p.clone` if the `p` is a raw pointer)
 - #127118 (Show `used attribute`'s kind for user when find it isn't applied to a `static` variable.)
 - #127122 (Remove uneccessary condition in `div_ceil`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-06-30 02:20:01 +00:00
Matthias Krüger
80cf576f59
Rollup merge of #127110 - surechen:fix_125488_06, r=compiler-errors
Fix a error suggestion for E0121 when using placeholder _ as return types on function signature.

Recommit after refactoring based on comment:
https://github.com/rust-lang/rust/pull/126017#issuecomment-2189149361

But when changing return type's lifetime to `ReError` will affect the subsequent borrow check process and cause test11 in typeck_type_placeholder_item.rs to lost E0515 message.
```rust
fn test11(x: &usize) -> &_ {
//~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types
    &x //~ ERROR cannot return reference to function parameter(this E0515 msg will disappear)
}
```

fixes #125488

r? ``@pnkfelix``
2024-06-29 22:10:58 +02:00
bors
ba1d7f4a08 Auto merge of #120639 - fee1-dead-contrib:new-effects-desugaring, r=oli-obk
Implement new effects desugaring

cc `@rust-lang/project-const-traits.` Will write down notes once I have finished.

* [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>`
* [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>`
* [ ] add types and traits to minicore test
* [ ] update rustc-dev-guide

Fixes #119717
Fixes #123664
Fixes #124857
Fixes #126148
2024-06-29 20:08:10 +00:00
surechen
50edb32939 Fix a error suggestion for E0121 when using placeholder _ as return types on function signature.
Recommit after refactoring based on comment:
https://github.com/rust-lang/rust/pull/126017#issuecomment-2189149361

But when changing return type's lifetime to `ReError` will affect the subsequent borrow check process and cause test11 in typeck_type_placeholder_item.rs to lost E0515 message.
```rust
fn test11(x: &usize) -> &_ {
//~^ ERROR the placeholder `_` is not allowed within types on item signatures for return types
    &x //~ ERROR cannot return reference to function parameter(this E0515 msg will disappear)
}

```
2024-06-29 14:23:33 +08:00
Deadbeef
65a0bee0b7 address review comments 2024-06-28 15:44:20 +00:00
Deadbeef
0a2330630d general fixups and turn TODOs into FIXMEs 2024-06-28 10:57:35 +00:00
Deadbeef
f852a2c173 Implement Self::Effects: Compat<HOST> desugaring 2024-06-28 10:57:35 +00:00
Deadbeef
b9886c6872 bless tests part 1 2024-06-28 10:57:35 +00:00
Deadbeef
74e7b5bd76 temporarily disable effects on specialization tests 2024-06-28 10:57:35 +00:00
Deadbeef
3637b153f7 move desugaring to item bounds 2024-06-28 10:57:35 +00:00
Deadbeef
c7d27a15d0 Implement Min trait in new solver 2024-06-28 10:57:35 +00:00
Deadbeef
72e8244e64 implement new effects desugaring 2024-06-28 10:57:35 +00:00
Michael Goulet
81c2c57519 Make queries more explicit 2024-06-27 12:03:57 -04:00
Matthias Krüger
8c6c6a7591
Rollup merge of #126968 - lqd:issue-126670, r=compiler-errors
Don't ICE during RPITIT refinement checking for resolution errors after normalization

#126670 shows a case where resolution errors after normalization can happen during RPITIT refinement checking. Our tests didn't reach this path before, and we explicitly ICEd until we had a test. We can now delay a bug since we're sure it is reachable and have the test from the isue.

The comment I added likely still needs more expert wordsmithing.

r? ``@compiler-errors`` who's making me work during vacation (j/k).
Fixes #126670
2024-06-26 07:50:20 +02:00
Rémy Rakic
6402909f42 delay bug in RPITIT refinement checking with resolution errors 2024-06-25 21:05:54 +00:00
Matthias Krüger
52e6f9ce96
Rollup merge of #126868 - bvanjoi:fix-126764, r=davidtwco
not use offset when there is not ends with brace

Fixes #126764
2024-06-25 18:02:59 +02:00
Michael Goulet
f26cc349d9 Split out IntoIterator and non-Iterator constructors for AliasTy/AliasTerm/TraitRef/projection 2024-06-24 11:28:21 -04:00
bohan
594fa01aba not use offset when there is not ends with brace 2024-06-23 23:44:22 +08:00
Matthias Krüger
dc9a08f535
Rollup merge of #126552 - fee1-dead-contrib:rmfx, r=compiler-errors
Remove use of const traits (and `feature(effects)`) from stdlib

The current uses are already unsound because they are using non-const impls in const contexts. We can reintroduce them by reverting the commit in this PR, after #120639 lands.

Also, make `effects` an incomplete feature.

cc `@rust-lang/project-const-traits`
r? `@compiler-errors`
2024-06-22 19:33:56 +02:00
Guillaume Gomez
3ed2cd74b5
Rollup merge of #126686 - fmease:dump-preds-n-item-bounds, r=compiler-errors
Add `#[rustc_dump_{predicates,item_bounds}]`

Conflicts with #126668.

As discussed
r? compiler-errors CC ``@fee1-dead``
2024-06-22 12:57:19 +02:00
León Orell Valerian Liehr
38bd7a0fcb
Add #[rustc_dump_{predicates,item_bounds}] 2024-06-22 06:34:09 +02:00
Michael Goulet
ffd72b1700 Fix remaining cases 2024-06-21 19:00:18 -04:00
Michael Goulet
db638ab968 Rename a bunch of things 2024-06-21 12:32:05 -04:00
Deadbeef
02aaea1803 update intrinsic const param counting 2024-06-21 09:23:54 +00:00
León Orell Valerian Liehr
bc12972bcd
Slightly refactor the dumping of HIR analysis data 2024-06-20 20:31:32 +02:00
Matthias Krüger
ef2e8bfcbf
Rollup merge of #126717 - nnethercote:rustfmt-use-pre-cleanups, r=jieyouxu
Clean up some comments near `use` declarations

#125443 will reformat all `use` declarations in the repository. There are a few edge cases involving comments on `use` declarations that require care. This PR cleans up some clumsy comment cases, taking us a step closer to #125443 being able to merge.

r? ``@lqd``
2024-06-20 14:07:04 +02:00
Matthias Krüger
e7be3562b7
Rollup merge of #126620 - oli-obk:taint_errors, r=fee1-dead
Actually taint InferCtxt when a fulfillment error is emitted

And avoid checking the global error counter

fixes #122044
fixes #123255
fixes #123276
fixes #125799
2024-06-20 07:52:43 +02:00
Nicholas Nethercote
b104fbec85 Add blank lines after module-level // comments.
Similar to the previous commit.
2024-06-20 09:23:20 +10:00
Oli Scherer
393dea8bc3 Allow tracing through item_bounds query invocations on opaques
Previously these caused cycles when printing the result
2024-06-19 08:47:55 +00:00
Oli Scherer
1cb75dc4a9 Remove a hack that isn't needed anymore 2024-06-19 04:41:57 +00:00
许杰友 Jieyou Xu (Joe)
8eb2e5f4c8
Rollup merge of #125293 - dingxiangfei2009:tail-expr-temp-lifetime, r=estebank,davidtwco
Place tail expression behind terminating scope

This PR implements #123739 so that we can do further experiments in nightly.

A little rewrite has been applied to `for await` lowering. It was previously `unsafe { Pin::unchecked_new(into_async_iter(..)) }`. Under the edition 2024 rule, however, `into_async_iter` gets dropped at the end of the `unsafe` block. This presumably the first Edition 2024 migration rule goes by hoisting `into_async_iter(..)` into `match` one level above, so it now looks like the following.
```rust
match into_async_iter($iter_expr) {
  ref mut iter => match unsafe { Pin::unchecked_new(iter) } {
    ...
  }
}
```
2024-06-19 01:51:38 +01:00
Oli Scherer
3f34196839 Remove redundant argument from subdiagnostic method 2024-06-18 15:42:11 +00:00
Oli Scherer
7ba82d61eb Use a dedicated type instead of a reference for the diagnostic context
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
2024-06-18 15:42:11 +00:00
Oli Scherer
c91edc3888 Prefer dcx methods over fields or fields' methods 2024-06-18 13:45:08 +00:00
Michael Goulet
b1efe1ab5d Rework precise capturing syntax 2024-06-17 22:35:25 -04:00
Ding Xiang Fei
0f8c3f7882
tail expression behind terminating scope 2024-06-18 04:14:43 +08:00
Matthias Krüger
0f2cc21547
Rollup merge of #126417 - beetrees:f16-f128-inline-asm-x86, r=Amanieu
Add `f16` and `f128` inline ASM support for `x86` and `x86-64`

This PR adds `f16` and `f128` input and output support to inline ASM on `x86` and `x86-64`. `f16` vector sizes are taken from [here](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html).

Relevant issue: #125398
Tracking issue: #116909

``@rustbot`` label +F-f16_and_f128
2024-06-15 14:40:48 +02:00
Michael Goulet
93ff86ed7c Use is_lang_item more aggressively 2024-06-14 16:54:29 -04:00
matt rice
1de046fa24 Update for review 2024-06-14 07:53:37 -07:00
Matthias Krüger
bfe032334f
Rollup merge of #126054 - veera-sivarajan:bugfix-113073-bound-on-generics-2, r=fee1-dead
`E0229`: Suggest Moving Type Constraints to Type Parameter Declaration

Fixes #113073

This PR suggests  `impl<T: Bound> Trait<T> for Foo` when finding `impl Trait<T: Bound> for Foo`. Tangentially, it also improves a handful of other error messages.

It accomplishes this in two steps:
1. Check if constrained arguments and parameter names appear in the same order and delay emitting "incorrect number of generic arguments" error because it can be confusing for the programmer to see `0 generic arguments provided` when there are `n` constrained generic arguments.

2. Inside `E0229`, suggest declaring the type parameter right after the `impl` keyword by finding the relevant impl block's span for type parameter declaration. This also handles lifetime declarations correctly.

Also, the multi part suggestion doesn't use the fluent error mechanism because translating all the errors to fluent style feels outside the scope of this PR. I will handle it in a separate PR if this gets approved.
2024-06-14 12:23:36 +02:00
beetrees
dfc5514527
Add f16 and f128 inline ASM support for x86 and x86-64 2024-06-13 16:12:23 +01:00
Veera
5da1b4189e E0229: Suggest Moving Type Constraints to Type Parameter Declaration 2024-06-12 19:32:31 -04:00
Michael Goulet
0d1d6ba58c
Rollup merge of #126340 - fee1-dead-contrib:fix-predicates_of-comments, r=compiler-errors
Fix outdated predacates_of.rs comments

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->
2024-06-12 14:26:29 -04:00
Deadbeef
54429cf279 Fix outdated predacates_of.rs comments 2024-06-12 16:19:25 +00:00
Guillaume Gomez
c21de3c91e
Rollup merge of #126228 - BoxyUwU:nested_repeat_expr_generics, r=compiler-errors
Provide correct parent for nested anon const

Fixes #126147

99% of this PR is just comments explaining what the issue is.

`tcx.parent(` and `hir().get_parent_item(` give different results as the hir owner for all the hir of anon consts is the enclosing function. I didn't attempt to change that as being a hir owner requires a `DefId` and long term we want to stop creating anon consts' `DefId`s before hir ty lowering.

So i just opted to change `generics_of` to use `tcx.parent` to get the parent for `AnonConst`'s. I'm not entirely sure about this being what we want, it does seem weird that we have two ways of getting the parent of an `AnonConst` and they both give different results.

Alternatively we could just go ahead and make `const_evaluatable_unchecked` a hard error and stop providing generics to repeat exprs. Then this isn't an issue. (The FCW has been around for almost 4 years now)

r? ````@compiler-errors````
2024-06-12 15:44:58 +02:00
bors
bbe9a9c20b Auto merge of #126319 - workingjubilee:rollup-lendnud, r=workingjubilee
Rollup of 16 pull requests

Successful merges:

 - #123374 (DOC: Add FFI example for slice::from_raw_parts())
 - #124514 (Recommend to never display zero disambiguators when demangling v0 symbols)
 - #125978 (Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking)
 - #125980 (Nvptx remove direct passmode)
 - #126187 (For E0277 suggest adding `Result` return type for function when using QuestionMark `?` in the body.)
 - #126210 (docs(core): make more const_ptr doctests assert instead of printing)
 - #126249 (Simplify `[T; N]::try_map` signature)
 - #126256 (Add {{target}} substitution to compiletest)
 - #126263 (Make issue-122805.rs big endian compatible)
 - #126281 (set_env: State the conclusion upfront)
 - #126286 (Make `storage-live.rs` robust against rustc internal changes.)
 - #126287 (Update a cranelift patch file for formatting changes.)
 - #126301 (Use `tidy` to sort crate attributes for all compiler crates.)
 - #126305 (Make PathBuf less Ok with adding UTF-16 then `into_string`)
 - #126310 (Migrate run make prefer rlib)
 - #126314 (fix RELEASES: we do not support upcasting to auto traits)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-06-12 11:10:50 +00:00
Jubilee
36e828fab5
Rollup merge of #126301 - nnethercote:sort-crate-attributes, r=davidtwco
Use `tidy` to sort crate attributes for all compiler crates.

We already do this for a number of crates, e.g. `rustc_middle`, `rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.

For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g. `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes), sometimes the order is alphabetical, and sometimes there is no particular order.
- Sometimes the attributes of a particular kind aren't even grouped all together, e.g. there might be a `feature`, then an `allow`, then another `feature`.

This commit extends the existing sorting to all compiler crates, increasing consistency. If any new attribute line is added there is now only one place it can go -- no need for arbitrary decisions.

Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`, because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's ignored in `rustfmt.toml`).

r? `@davidtwco`
2024-06-12 03:57:24 -07:00
Jubilee
e7b07ea7a1
Rollup merge of #125978 - fmease:cleanup-hir-ty-lowering-consolidate-assoc-item-access-checking, r=davidtwco
Cleanup: HIR ty lowering: Consolidate the places that do assoc item probing & access checking

Use `probe_assoc_item` (for hygienically probing an assoc item and checking if it's accessible wrt. visibility and stability) for assoc item constraints, too, not just for assoc type paths and make the privacy error translatable.
2024-06-12 03:57:19 -07:00
Oli Scherer
0bc2001879 Require any function with a tait in its signature to actually constrain a hidden type 2024-06-12 08:53:59 +00:00
Nicholas Nethercote
75b164d836 Use tidy to sort crate attributes for all compiler crates.
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.

For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
  `allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
  sometimes the order is alphabetical, and sometimes there is no
  particular order.
- Sometimes the attributes of a particular kind aren't even grouped
  all together, e.g. there might be a `feature`, then an `allow`, then
  another `feature`.

This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.

Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
  because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
  ignored in `rustfmt.toml`).
2024-06-12 15:49:10 +10:00
Boxy
bfb7757c3c Correct parent for nested anon consts 2024-06-10 14:32:50 +01:00
bors
1be24d70ce Auto merge of #125918 - oli-obk:const_block_ice, r=compiler-errors
Revert: create const block bodies in typeck via query feeding

as per the discussion in https://github.com/rust-lang/rust/pull/125806#discussion_r1622563948

It was a mistake to try to shoehorn const blocks and some specific anon consts into the same box and feed them during typeck. It turned out not simplifying anything (my hope was that we could feed `type_of` to start avoiding the huge HIR matcher, but that didn't work out), but instead making a few things more fragile.

reverts the const-block-specific parts of https://github.com/rust-lang/rust/pull/124650

`@bors` rollup=never had a small perf impact previously

fixes https://github.com/rust-lang/rust/issues/125846

r? `@compiler-errors`
2024-06-07 09:08:59 +00:00
Oli Scherer
cbee17d502 Revert "Create const block DefIds in typeck instead of ast lowering"
This reverts commit ddc5f9b6c1.
2024-06-07 08:33:58 +00:00
Michael Goulet
82ef3ad980 Uplift TypeError 2024-06-06 07:49:47 -04:00
bors
2d28b6384e Auto merge of #124482 - spastorino:unsafe-extern-blocks, r=oli-obk
Unsafe extern blocks

This implements RFC 3484.

Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484

This is better reviewed commit by commit.
2024-06-06 08:14:58 +00:00
Boxy
56092a345b Misc fixes (pattern type lowering, cfi, pretty printing) 2024-06-05 22:25:42 +01:00
Boxy
58feec9b85 Basic removal of Ty from places (boring) 2024-06-05 22:25:38 +01:00
Oli Scherer
c8a331ac52 Unify optional param info with object lifetime default boolean into an enum that exhaustively supports all call sites 2024-06-05 09:16:55 +00:00