Commit Graph

261750 Commits

Author SHA1 Message Date
Trevor Gross
a70dc297a8
Rollup merge of - mu001999-contrib:dead/enhance, r=pnkfelix
Extend rules of dead code analysis for impls for adts to impls for types refer to adts

The rules of dead code analysis for impl blocks can be extended to self types which refer to adts.

So that we can lint the following unused struct and trait:
```rust
struct Foo; //~ ERROR struct `Foo` is never constructed

trait Trait { //~ ERROR trait `Trait` is never used
    fn foo(&self) {}
}

impl Trait for &Foo {}
```

r? `@pnkfelix`
2024-07-26 02:20:29 -04:00
Trevor Gross
ceae37188b
Rollup merge of - 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]()).

---

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 ?

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  (sugg diag fix).
Fixes  (wontfix, acknowledgement, sugg diag applic fix).
Fixes  (sugg diag applic fix).
Fixes  (wontfix, acknowledgement, sugg diag applic fix).
Fixes  (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
bors
48bbe123c2 Auto merge of - flip1995:clippy-subtree-update, r=matthiaskrgr
Clippy subtree update

r? `@Manishearth`

Updates Cargo.lock due to the Clippy version update and the ui_test bump to v0.24
2024-07-26 03:36:34 +00:00
bors
72d73cec61 Auto merge of - matthiaskrgr:rollup-v40q1j3, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 -  (Fix supertrait associated type unsoundness)
 -  (Graciously handle `Drop` impls introducing more generic parameters than the ADT)
 -  (Use `#[rustfmt::skip]` on some `use` groups to prevent reordering.)
 -  (Various notes on match lowering)
 -  (Stop using `unsized_const_parameters` in core/std)
 -  (LLVM: LLVM-20.0 removes MMX types)
 -  (fix: compilation issue w/ refactored type)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-26 01:13:26 +00:00
Matthias Krüger
d87fa5e788
Rollup merge of - juliusl:pr/align-change-time, r=tgross35
fix: compilation issue w/ refactored type

Fixes a compilation issue related to 
2024-07-26 00:57:24 +02:00
Matthias Krüger
d03c56f45d
Rollup merge of - maurer:fix-mmx, r=cuviper
LLVM: LLVM-20.0 removes MMX types

See 

`@rustbot` label: +llvm-main
2024-07-26 00:57:23 +02:00
Matthias Krüger
ba990ae8af
Rollup merge of - BoxyUwU:std_only_sized_const_params, r=workingjubilee
Stop using `unsized_const_parameters` in core/std

`feature(unsized_const_parameters)` is an incomplete feature and should not be used by core/std as it makes it can make it significantly harder to evolve the feature. It also just generally opens the possibility of introducing bugs on stable through std's backdoor.

The only usage of this feature in std is the `simd_shuffle_intrinsic` added in . It doesn't seem to be used anywhere as far as I can tell so it is removed in this PR. All tests and codegen logic etc have been kept however.

r? `@workingjubilee`
2024-07-26 00:57:22 +02:00
Matthias Krüger
f345c5e845
Rollup merge of - Zalathar:notes, r=Nadrieril
Various notes on match lowering

This is an assortment of comments for things that I found unclear or confusing when I was learning how match lowering works.

This PR only adds/modifies comments, so there are no functional changes.

I have tried to avoid touching code that would conflict with .

r? `@Nadrieril`
2024-07-26 00:57:22 +02:00
Matthias Krüger
ab2dd3aeb9
Rollup merge of - nnethercote:rustfmt-skip-on-use-decls, r=cuviper
Use `#[rustfmt::skip]` on some `use` groups to prevent reordering.

`use` declarations will be reformatted in . Very rarely, there is a desire to force a group of `use` declarations together in a way that auto-formatting will break up. E.g. when you want a single comment to apply to a group.  dealt with all of these in the codebase, ensuring that no comments intended for multiple `use` declarations would end up in the wrong place. But some people were unhappy with it.

This commit uses `#[rustfmt::skip]` to create these custom `use` groups in an idiomatic way for a few of the cases changed in . This works because rustfmt treats any `use` item annotated with `#[rustfmt::skip]` as a barrier and won't reorder other `use` items around it.

r? `@cuviper`
2024-07-26 00:57:21 +02:00
Matthias Krüger
29314e4fca
Rollup merge of - BoxyUwU:dropck_handle_extra_impl_params, r=compiler-errors
Graciously handle `Drop` impls introducing more generic parameters than the ADT

Follow up to 
Fixes 
Fixes 

## 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
Matthias Krüger
a88354831b
Rollup merge of - compiler-errors:supertrait-assoc-ty-unsoundness, r=lcnr
Fix supertrait associated type unsoundness

### What?

Object safety allows us to name `Self::Assoc` associated types in certain positions if they come from our trait or one of our supertraits. When this check was implemented, I think it failed to consider that supertraits can have different args, and it was only checking def-id equality.

This is problematic, since we can sneak different implementations in by implementing `Supertrait<NotActuallyTheSupertraitSubsts>` for a `dyn` type. This can be used to implement an unsound transmute function. See the committed test.

### How do we fix it?

We consider the whole trait ref when checking for supertraits. Right now, this is implemented using equality *without* normalization. We erase regions since those don't affect trait selection.

This is a limitation that could theoretically affect code that should be accepted, but doesn't matter in practice -- there are 0 crater regression. We could make this check stronger, but I would be worried about cycle issues. I assume that most people are writing `Self::Assoc` so they don't really care about the trait ref being normalized.

---

### What is up w the stacked commit

This is built on top of https://github.com/rust-lang/rust/pull/122804 though that's really not related, it's just easier to make this modification with the changes to the object safety code that I did in that PR. The only thing is that PR may make this unsoundness slightly easier to abuse, since there are more positions that allow self-associated-types -- I am happy to stall that change until this PR merges.

---

Fixes 

r? lcnr
2024-07-26 00:57:20 +02:00
bors
2f26b2a99a Auto merge of - GrigorenkoPV:derivative, r=compiler-errors
Switch from `derivative` to `derive-where`

This is a part of the effort to get rid of `syn 1.*` in compiler's dependencies: 

Derivative has not been maintained in nearly 3 years[^1]. It also depends on `syn 1.*`.

This PR replaces `derivative` with `derive-where`[^2], a not dead alternative, which uses `syn 2.*`.

A couple of `Debug` formats have changed around the skipped fields[^3], but I doubt this is an issue.

[^1]: https://github.com/mcarton/rust-derivative/issues/117
[^2]: https://lib.rs/crates/derive-where
[^3]: See the changes in `tests/ui`
2024-07-25 22:50:58 +00:00
Julius Liu
e141b07164 fix: compilation issue w/ refactored type 2024-07-25 15:27:20 -07:00
bors
7120fdac7a Auto merge of - runtimeverification:smir_serde_derive, r=celinval
Add basic Serde serialization capabilities to Stable MIR

This PR adds basic Serde serialization capabilities to Stable MIR. It is intentionally minimal (just wrapping all stable MIR types with a Serde `derive`), so that any important design decisions can be discussed before going further. A simple test is included with this PR to validate that JSON can actually be emitted.

## Notes

When I wrapped the Stable MIR error types in `compiler/stable_mir/src/error.rs`, it caused test failures (though I'm not sure why) so I backed those out.

## Future Work

So, this PR will support serializing basic stable MIR, but it _does not_ support serializing interned values beneath `Ty`s and `AllocId`s, etc... My current thinking about how to handle this is as follows:

1.  Add new `visited_X` fields to the `Tables` struct for each interned category of interest.

2.  As serialization is occuring, serialize interned values as usual _and_ also record the interned value we referenced in `visited_X`.

    (Possibly) In addition, if an interned value recursively references other interned values, record those interned values as well.

3.  Teach the stable MIR `Context` how to access the `visited_X` values and expose them with wrappers in `stable_mir/src/lib.rs` to users (e.g. to serialize and/or further analyze them).

### Pros

This approach does not commit to any specific serialization format regarding interned values or other more complex cases, which avoids us locking into any behaviors that may not be desired long-term.

### Cons

The user will need to manually handle serializing interned values.

### Alternatives

1.  We can directly provide access to the underlying `Tables` maps for interned values; the disadvantage of this approach is that it either requires extra processing for users to filter out to only use the values that they need _or_ users may serialize extra values that they don't need. The advantage is that the implementation is even simpler. The other pros/cons are similar to the above.

2.  We can directly serialize interned values by expanding them in-place. The pro is that this may make some basic inputs easier to consume. However, the cons are that there will need to be special provisions for dealing with cyclical values on both the producer and consumer _and_ global values will possibly need to be de-duplicated on the consumer side.
2024-07-25 20:27:51 +00:00
Boxy
8174f9b44b Stop using unsized_const_parameters in core/std 2024-07-25 19:47:21 +01:00
bors
aa877bc71c Auto merge of - matthiaskrgr:rollup-195dfdf, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 -  (Use Cow<'static, str> for InlineAsmTemplatePiece::String)
 -  (Inject arm32 shims into Windows metadata generation)
 -  (CStr: derive PartialEq, Eq; add test for Ord)
 -  (Fix a span error when parsing a wrong param of function.)
 -  (Fix 1.80.0 version in RELEASES.md)
 -  (Turn an unreachable code path into an ICE)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-25 18:05:00 +00:00
Matthew Maurer
38931cd227 LLVM: LLVM-20.0 removes MMX types
See 
2024-07-25 17:58:37 +00:00
Matthias Krüger
cf1ce4beca
Rollup merge of - oli-obk:tainting_stuff, r=compiler-errors
Turn an unreachable code path into an ICE

We're probably replacing the resolution with a `Res::Err` nowadays instead of just erroring but keeping the `Res`, so this code path should be unreachable
2024-07-25 18:58:00 +02:00
Matthias Krüger
f378b4fd53
Rollup merge of - Urgau:fix-1.80.0-release-version, r=pietroalbini
Fix 1.80.0 version in RELEASES.md

https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/1.2E80/near/453937871

r? ``@Mark-Simulacrum`` (or who ever wants)
Fixes https://github.com/rust-lang/rust/issues/128188
2024-07-25 18:57:59 +02:00
Matthias Krüger
9fd5679d52
Rollup merge of - surechen:fix_128042_2, r=compiler-errors
Fix a span error when parsing a wrong param of function.

fixes 

Before this change, the span of param `*mut Self` in  `fn oof(*mut Self)` contains `(` before it, so the suggestion in E0424 will be error.
2024-07-25 18:57:59 +02:00
Matthias Krüger
512277ff70
Rollup merge of - GrigorenkoPV:cstr-derive, r=dtolnay
CStr: derive PartialEq, Eq; add test for Ord

While working on , I've spotted a peculiarity: `CStr` has `PartialEq, Eq, PartialOrd, Ord` implemented manually and not derived.

While we can't derive `PartialOrd, Ord` (due to inner `[c_char]` being `[i8]` or `[u8]` on different platforms), we *can* derive `PartialEq, Eq` (I think), allowing as to remove `#[allow(clippy::derived_hash_with_manual_eq)]` as well.

(I really hope `c_char: Eq` on all platforms)
2024-07-25 18:57:58 +02:00
Matthias Krüger
c96311bf8a
Rollup merge of - ChrisDenton:arm32, r=Amanieu
Inject arm32 shims into Windows metadata generation

I had been keen to eventually move to using windows-sys as a normal Cargo dependency. But for linking, compile times and other reasons that's unlikely to ever happen.

So if we're sticking with generated bindings then injecting any necessary missing type definitions (i.e. for the MS unsupported arm32) is simpler than defining whole functions ourselves just because we need to manually implement those types on a tier 3 platform. This also reduces the places we need to change when making changes to how we use `#[link]`.

r? libs
2024-07-25 18:57:57 +02:00
Matthias Krüger
155ba22f3c
Rollup merge of - GnomedDev:cow-inline-asm-temp-piece, r=compiler-errors
Use Cow<'static, str> for InlineAsmTemplatePiece::String

This removes a bunch of `&'static str -> String` allocations in codegen cranelift.
2024-07-25 18:57:56 +02:00
Philipp Krones
0949ff928a
Update Cargo.lock 2024-07-25 18:29:27 +02:00
Philipp Krones
b270543f8f
Merge commit '37f4fbb92913586b73a35772efd00eccd1cbbe13' into clippy-subtree-update 2024-07-25 18:29:17 +02:00
bors
37f4fbb929 Auto merge of - flip1995:rustup, r=flip1995
Rustup

r? `@ghost`

changelog: none
2024-07-25 16:25:19 +00:00
Philipp Krones
71b0f0fcac
Bump Clippy version -> 0.1.82 2024-07-25 18:23:37 +02:00
Philipp Krones
09419e44e9
Bump nightly version -> 2024-07-25 2024-07-25 18:23:33 +02:00
Philipp Krones
9f53fc32cf
Merge remote-tracking branch 'upstream/master' into rustup 2024-07-25 18:23:27 +02:00
bors
eb10639928 Auto merge of - matthiaskrgr:rollup-01b7t98, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 -  (Implement lint against ambiguous negative literals)
 -  (Fix connect timeout for non-linux targets, read readiness of socket connection, Read readiness to detect errors. `Fixes #127018`)
 -  (`#[naked]`: use an allowlist for allowed options on `asm!` in naked functions)
 -  (std: unsafe-wrap personality::gcc)
 -  (Make sure that args are compatible in `resolve_associated_item`)
 -  (Don't ICE if HIR and middle types disagree in borrowck error reporting)
 -  (Remove crashes for misuses of intrinsics)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-25 15:41:00 +00:00
Oli Scherer
0706cc6397 Turn an unreachable code path into an ICE 2024-07-25 15:33:34 +00:00
Urgau
f0ba8c4ffb
Fix 1.80.0 version in RELEASES.md 2024-07-25 16:57:57 +02:00
Matthias Krüger
c98d704c46
Rollup merge of - compiler-errors:misused-intrinsics, r=oli-obk
Remove crashes for misuses of intrinsics

All of these do not crash if the feature gate is removed. An ICE due *opting into* the intrinsics feature gate is not a bug that needs to be fixed, but instead a misuse of an internal-only API.

See https://github.com/rust-lang/compiler-team/issues/620

The last two issues are already closed anyways, but:
Fixes 
Fixes 
Fixes 
2024-07-25 16:48:22 +02:00
Matthias Krüger
4cf4196907
Rollup merge of - compiler-errors:non-self-arg, r=chenyukang
Don't ICE if HIR and middle types disagree in borrowck error reporting

We try to match up the `middle::ty::Ty` and `hir::Ty` types in borrowck error reporting, but due to things like `Self` self type alias, or regular type aliases, these might not match up. Don't ICE.

This PR also tries to recover the error by looking up the self type of the impl in case we see `Self`. The diagnostic is frankly quite confusing, but I also didn't really want to look at it because I don't understand the conflict error reporting logic. 🤷

Fixes 
2024-07-25 16:48:21 +02:00
Matthias Krüger
5a853d02f1
Rollup merge of - compiler-errors:arg-compat, r=oli-obk
Make sure that args are compatible in `resolve_associated_item`

Implements a similar check to the one that we have in projection for GATs (, ), where we check that the args of an impl item are compatible before returning it. This is done in `resolve_assoc_item`, which is backing `Instance::resolve`, so this is conceptually generalizing the check from GATs to methods/assoc consts. This is important to make sure that the inliner will only visit and substitute MIR bodies that are compatible w/ their trait definitions.

This shouldn't happen in codegen, but there are a few ways to get the inliner to be invoked (via calls to `optimized_mir`) before codegen, namely polymorphization and CTFE.

Fixes 
Fixes 
Fixes 
Fixes 
2024-07-25 16:48:21 +02:00
Matthias Krüger
606c9fcb4d
Rollup merge of - workingjubilee:unsafe-wrap-personality-gcc, r=ChrisDenton
std: unsafe-wrap personality::gcc

Nothing seems obviously wrong with these implementations except for some unanswered questions. Admittedly, I don't want to burn excessive time on exceptional exception handlers. Thus this is mostly a brute-force syntactic wrapping and some comments where they seemed correct, creating another largely whitespace diff.

try-job: armhf-gnu
2024-07-25 16:48:20 +02:00
Matthias Krüger
e76bb3fab6
Rollup merge of - folkertdev:asm-option-allowlist, r=lcnr
`#[naked]`: use an allowlist for allowed options on `asm!` in naked functions

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

this is mostly just a refactor, but using an allowlist (rather than a denylist) for which asm options are allowed in naked functions is a little safer.

These options are disallowed because naked functions are effectively global asm, but defined using inline asm.
2024-07-25 16:48:20 +02:00
Matthias Krüger
d1070df553
Rollup merge of - biabbas:fix_connect_timeout, r=tgross35
Fix connect timeout for non-linux targets, read readiness of socket connection, Read readiness to detect errors. `Fixes #127018`

Fixes 
Connect_timeout would call `poll` and check `pollfd.revents` for POLLHUP error, rather that checking readiness. This behavior was meant for Linux as it returns POLLHUP | POLLOUT | POLLERR in case of errors. But on targets that do not return POLLHUP in `pollfd.revents`, this would indicate a false success and result in this issue. To resolve this we will check readiness of socket using  `getsockopt():`  and return success from connect_timeout when there are no errors.
Changes were tested on Linux and an rtos.
![Screenshot 2024-07-04 105820](https://github.com/rust-lang/rust/assets/88673422/5ef5a87f-f2af-4fb7-98da-7612d5e27e9a)
Thank you.
2024-07-25 16:48:19 +02:00
Matthias Krüger
ae71900ef6
Rollup merge of - Urgau:unary_precedence, r=compiler-errors
Implement lint against ambiguous negative literals

This PR implements a lint against ambiguous negative literals with a literal and method calls right after it.

## `ambiguous_negative_literals`

(deny-by-default)

The `ambiguous_negative_literals` lint checks for cases that are confusing between a negative literal and a negation that's not part of the literal.

### Example

```rust,compile_fail
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
```

### Explanation

Method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.

<details>
<summary>Old proposed lint</summary>

## `ambiguous_unary_precedence`

(deny-by-default)

The `ambiguous_unary_precedence` lint checks for use the negative unary operator with a literal and method calls.

### Example

```rust
-1i32.abs(); // equals -1, while `(-1i32).abs()` equals 1
```

### Explanation

Unary operations take precedence on binary operations and method calls take precedence over unary precedence. Setting the precedence explicitly makes the code clearer and avoid potential bugs.

</details>

-----

Note: This is a strip down version of https://github.com/rust-lang/rust/pull/117161, without the binary op precedence.

Fixes https://github.com/rust-lang/rust/issues/117155
`@rustbot` labels +I-lang-nominated
cc `@scottmcm`
r? compiler
2024-07-25 16:48:17 +02:00
surechen
4ac60601d3 Fix a span error when parsing a wrong param of function.
fixes 
2024-07-25 22:33:45 +08:00
bors
df0cb6c51e Auto merge of - xFrednet:changelog-1-80, r=dswij
Changelog for Clippy 1.80 🌞

Roses are red,
Violets are blue,
Summer is fun,
So much sun

---

### The cat of this release is *Maunzer* submitted by `@llogiq:`

<img height=500 src="https://github.com/rust-lang/rust-clippy/assets/4200835/a1da6948-446d-4ccf-95a7-c816a8afdc3f" alt="The cats of this Clippy release" />

Cats for the next release can be nominated in the comments :D

---

changelog: none

I wish everyone reading this a beautiful and happy day =^.^=
2024-07-25 12:48:54 +00:00
bors
be8234098b Auto merge of - xFrednet:lintcheck-limit-summery-output, r=Alexendoo
Lintcheck: Rework and limit diff output for GH's CI

### Background

While working on https://github.com/rust-lang/rust-clippy/pull/13136 I found an amazing limitation of GH's CI. The summary can at most have be 1MB of text. Here is the warning message:

> $GITHUB_STEP_SUMMARY upload aborted, supports content up to a size of 1024k, got 46731k. For more information see: https://docs.github.com/actions/using-workflows/workflow-commands-for-github-actions#adding-a-markdown-summary

[The PR](https://github.com/rust-lang/rust-clippy/pull/13136) produced a *casual* 61808 changes. Guess that's why those lints are not *warn-by-default* :P.

### Changes:

This PR limits the lintcheck diff output in two ways.

1. The diff is limited to 200 messages per lint per section. Hidden messages are indicated by a message at the end of the section.
2. The output is first written to a file and only the first 1MB is written to ` >> $GITHUB_STEP_SUMMARY`. The entire file is also written to the normal CI log. This helps for cases where several lints change and the total size exceeds the 1MB limit.

An example of these changes can be seen here: https://github.com/xFrednet/rust-clippy/actions/runs/10028799118?pr=4

---

changelog: none

r? `@Alexendoo`

Sorry for bombarding you with so many PR's lately 😅 Feel free to pass some of you reviews to me.
2024-07-25 12:11:35 +00:00
bors
54be9ad5eb Auto merge of - Oneirical:real-testate, r=Kobzol
Migrate `extern-diff-internal-name`, `extern-multiple-copies` and `extern-multiple-copies2` `run-make` tests to rmake

Part of  and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

Please try:

try-job: test-various
2024-07-25 12:09:24 +00:00
Pavel Grigorenko
cf9816c17e CStr: derive PartialEq, Eq; add test for Ord 2024-07-25 14:18:40 +03:00
B I Mohammed Abbas
17b4fbc388 In connect timeout, read readiness of socket for vxworks. Check pollhup or pollerr for refused connections in linux 2024-07-25 15:11:26 +05:30
bors
28e684b470 Auto merge of - workingjubilee:say-turings-prayer, r=BoxyUwU
compiler: Never debug_assert in codegen

In the name of Turing and his Hoarey heralds, assert our truths before creating a monster!

The `rustc_codegen_llvm` and `rustc_codegen_ssa` crates are fairly critical for rustc's correctness. Small mistakes here can easily result in undefined behavior, since a "small mistake" can mean something like "link and execute the wrong code". We should probably run any and all asserts in these modules unconditionally on whether this is a "debug build", and damn the costs in performance.

...Especially because the costs in performance seem to be *nothing*. It is not clear how much correctness we gain here, but I'll take free correctness improvements.
2024-07-25 07:52:31 +00:00
Zalathar
31f31aa471 Remove an obsolete comment
The test mentioned by this comment was deleted long ago by
<https://github.com/rust-lang/rust/pull/80290>.
2024-07-25 16:41:51 +10:00
Zalathar
118a70f38c Various notes on match lowering 2024-07-25 16:22:55 +10:00
bors
004e155c46 Auto merge of - matthiaskrgr:rollup-ylsoq30, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 -  (Reorder trait bound modifiers *after* `for<...>` binder in trait bounds)
 -  (Replace ASCII control chars with Unicode Control Pictures)
 -  (Migrate `pointer-auth-link-with-c`, `c-dynamic-rlib` and `c-dynamic-dylib` `run-make` tests to rmake)
 -  (Do not use question as label)
 -  (Don't ICE when auto trait has assoc ty in old solver)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-25 04:17:47 +00:00
Michael Goulet
34819b7298 Don't add crashes for misuses of intrinsics 2024-07-24 23:49:29 -04:00