Commit Graph

261133 Commits

Author SHA1 Message Date
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
Esteban Küber
2259db6af0 Add svg test for incorrect literal type suggestion 2024-07-18 18:20:32 +00:00
bors
5affbb1715 Auto merge of #127924 - matthiaskrgr:rollup-1gn6afv, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #124881 (Use ThreadId instead of TLS-address in `ReentrantLock`)
 - #127656 (make pub_use_of_private_extern_crate show up in cargo's future breakage reports)
 - #127748 (Use Option's discriminant as its size hint)
 - #127854 (Add internal lint for detecting non-glob imports of `rustc_type_ir::inherent`)
 - #127908 (Update extern linking documentation)
 - #127919 (Allow a git command for getting the current branch in bootstrap to fail)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-18 18:12:47 +00:00
Esteban Küber
67ec1326ee Fix ICE in suggestion caused by being recovered as ==
The second suggestion shown here would previously incorrectly assume that the span corresponding to `⩵` was 2 bytes wide composed by 2 1 byte wide chars, so a span pointing at `==` could point only at one of the `=` to remove it. Instead, we now replace the whole thing (as we should have the whole time):

```
error: unknown start of token: \u{2a75}
  --> $DIR/unicode-double-equals-recovery.rs:1:16
   |
LL | const A: usize ⩵ 2;
   |                ^
   |
help: Unicode character '⩵' (Two Consecutive Equals Signs) looks like '==' (Double Equals Sign), but it is not
   |
LL | const A: usize == 2;
   |                ~~

error: unexpected `==`
  --> $DIR/unicode-double-equals-recovery.rs:1:16
   |
LL | const A: usize ⩵ 2;
   |                ^
   |
help: try using `=` instead
   |
LL | const A: usize = 2;
   |                ~
```
2024-07-18 17:47:31 +00:00
Oneirical
741cf91678 rewrite lto-smoke-c to rmake 2024-07-18 13:42:15 -04:00
Matthias Krüger
6c108224e1
Rollup merge of #127919 - Kobzol:fix-git-command, r=onur-ozkan
Allow a git command for getting the current branch in bootstrap to fail

Found by `@lukas-code` [here](https://github.com/rust-lang/rust/pull/127680#discussion_r1682868094). The bug was introduced in https://github.com/rust-lang/rust/pull/127680 (before, the command was allowed to fail).

r? `@onur-ozkan`
2024-07-18 18:10:18 +02:00
Matthias Krüger
ac26f6ac53
Rollup merge of #127908 - fasterthanlime:patch-1, r=jieyouxu
Update extern linking documentation

In particular, remove the note saying cdylibs can't link against dylibs — that hasn't been true for over four years.

  * 2019-11-07: note is written: b54e8ecc2e
  * 2020-01-23: restriction is lifted (without updating docs): 72aaa3a414
2024-07-18 18:10:17 +02:00
Matthias Krüger
4ad2c99b6d
Rollup merge of #127854 - fmease:glob-import-type_ir_inherent-lint, r=compiler-errors
Add internal lint for detecting non-glob imports of `rustc_type_ir::inherent`

https://github.com/rust-lang/rust/pull/127627#issuecomment-2225295951

r? compiler-errors
2024-07-18 18:10:16 +02:00
Matthias Krüger
6f7fa03a06
Rollup merge of #127748 - scottmcm:option_len, r=joboet
Use Option's discriminant as its size hint

I was looking at this in MIR after a question on discord, and noticed that it ends up with a switch in MIR (<https://rust.godbolt.org/z/3q4cYnnb3>), which it doesn't need because (as `Option::as_slice` uses) the discriminant is already the length.
2024-07-18 18:10:16 +02:00
Matthias Krüger
ec6110f00c
Rollup merge of #127656 - RalfJung:pub_use_of_private_extern_crate, r=petrochenkov
make pub_use_of_private_extern_crate show up in cargo's future breakage reports

This has been a lint for many years.

However, turns out that outright removing it right now would lead to [tons of crater regressions](https://github.com/rust-lang/rust/pull/127656#issuecomment-2233288534) due to crates depending on an ancient version of `bitflags`. 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.

r? `@petrochenkov`
2024-07-18 18:10:15 +02:00
Matthias Krüger
f62aa415c3
Rollup merge of #124881 - Sp00ph:reentrant_lock_tid, r=joboet
Use ThreadId instead of TLS-address in `ReentrantLock`

Fixes #123458

`ReentrantLock` currently uses the address of a thread local variable as an ID that's unique across all currently running threads. This can lead to uninituitive behavior as in #123458 if TLS blocks get reused. This PR changes `ReentrantLock` to instead use the `ThreadId` provided by `std` as the unique ID. `ThreadId` guarantees uniqueness across the lifetime of the whole process, so we don't need to worry about reusing IDs of terminated threads. The main appeal of this PR is thus the possibility of changing the `ReentrantLock` API to guarantee that if a thread leaks a lock guard, no other thread may ever acquire that lock again.

This does entail some complications:
- previously, the only way to retrieve the current thread ID would've been using `thread::current().id()` which creates a temporary `Arc` and which isn't available in TLS destructors. As part of this PR, the thread ID instead gets cached in its own thread local, as suggested [here](https://github.com/rust-lang/rust/issues/123458#issuecomment-2038207704).
- `ThreadId` is always 64-bit whereas the current implementation uses a usize-sized ID. Since this ID needs to be updated atomically, we can't simply use a single atomic variable on 32 bit platforms. Instead, we fall back to using a (sound) seqlock on 32-bit platforms, which works because only one thread at a time can write to the ID. This seqlock is technically susceptible to the ABA problem, but the attack vector to create actual unsoundness has to be very specific:
  - You would need to be able to lock+unlock the lock exactly 2^31 times (or a multiple thereof) while a thread trying to lock it sleeps
  - The sleeping thread would have to suspend after reading one half of the thread id but before reading the other half
  - The teared result from combining the halves of the thread ID would have to exactly line up with the sleeping thread's ID

The risk of this occurring seems slim enough to be acceptable to me, but correct me if I'm wrong. This also means that the size of the lock increases by 8 bytes on 32-bit platforms, but this also shouldn't be an issue.

Performance wise, I did some crude testing of the only case where this could lead to real slowdowns, which is the case of locking a `ReentrantLock` that's already locked by the current thread. On both aarch64 and x86-64, there is (expectedly) pretty much no performance hit. I didn't have any 32-bit platforms to test the seqlock performance on, so I did the next best thing and just forced the 64-bit platforms to use the seqlock implementation. There, the performance degraded by ~1-2ns/(lock+unlock) on x86-64 and ~6-8ns/(lock+unlock) on aarch64, which is measurable but seems acceptable to me seeing as 32-bit platforms should be a small minority anyways.

cc `@joboet` `@RalfJung` `@CAD97`
2024-07-18 18:10:14 +02:00
Oneirical
fc4404c230 Rewrite and rename issue-26006 to rmake 2024-07-18 11:14:07 -04:00
Oneirical
9dc08e30bd Rewrite and rename issue-22131 to rmake 2024-07-18 11:13:59 -04:00
onur-ozkan
5901c8c0cb create check-default-config-profiles.sh for mingw-check
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-07-18 17:31:56 +03:00
Markus Everling
fe89962237 Update ReentrantLock implementation, add CURRENT_ID thread local.
This changes `ReentrantLock` to use `ThreadId` for the thread ownership check instead of the address of a thread local. Unlike TLS blocks, `ThreadId` is guaranteed to be unique across the lifetime of the process, so if any thread ever terminates while holding a `ReentrantLockGuard`, no other thread may ever acquire that lock again.

On platforms with 64-bit atomics, this is a very simple change. On other platforms, the approach used is slightly more involved, as explained in the module comment.

This also adds a `CURRENT_ID` thread local in addition to the already existing `CURRENT`. This allows us to access the current `ThreadId` without the relatively heavy machinery used by `thread::current().id()`.
2024-07-18 14:09:25 +00:00
Jakub Beránek
4dc8e66074
Allow a git command for getting the current branch in bootstrap to fail
It can fail when in git is in detached HEAD mode.
2024-07-18 15:49:10 +02:00
bors
5753b30676 Auto merge of #117967 - adetaylor:fix-lifetime-elision-bug, r=lcnr
Fix ambiguous cases of multiple & in elided self lifetimes

This change proposes simpler rules to identify the lifetime on `self` parameters which may be used to elide a return type lifetime.

## The old rules

(copied from [this comment](https://github.com/rust-lang/rust/pull/117967#discussion_r1420554242))

Most of the code can be found in [late.rs](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html) and acts on AST types. The function [resolve_fn_params](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2006), in the success case, returns a single lifetime which can be used to elide the lifetime of return types.

Here's how:
* If the first parameter is called self then we search that parameter using "`self` search rules", below
* If no unique applicable lifetime was found, search all other parameters using "regular parameter search rules", below

(In practice the code does extra work to assemble good diagnostic information, so it's not quite laid out like the above.)

### `self` search rules

This is primarily handled in [find_lifetime_for_self](https://doc.rust-lang.org/stable/nightly-rustc/src/rustc_resolve/late.rs.html#2118) , and is described slightly [here](https://github.com/rust-lang/rust/issues/117715#issuecomment-1813115477) already. The code:

1. Recursively walks the type of the `self` parameter (there's some complexity about resolving various special cases, but it's essentially just walking the type as far as I can see)
2. Each time we find a reference anywhere in the type, if the **direct** referent is `Self` (either spelled `Self` or by some alias resolution which I don't fully understand), then we'll add that to a set of candidate lifetimes
3. If there's exactly one such unique lifetime candidate found, we return this lifetime.

### Regular parameter search rules

1. Find all the lifetimes in each parameter, including implicit, explicit etc.
2. If there's exactly one parameter containing lifetimes, and if that parameter contains exactly one (unique) lifetime, *and if we didn't find a `self` lifetime parameter already*, we'll return this lifetime.

## The new rules

There are no changes to the "regular parameter search rules" or to the overall flow, only to the `self` search rules which are now:

1. Recursively walks the type of the `self` parameter, searching for lifetimes of reference types whose referent **contains** `Self`.[^1]
2. Keep a record of:
   * Whether 0, 1 or n unique lifetimes are found on references encountered during the walk
4. If no lifetime was found, we don't return a lifetime. (This means other parameters' lifetimes may be used for return type lifetime elision).
5. If there's one lifetime found, we return the lifetime.
6. If multiple lifetimes were found, we abort elision entirely (other parameters' lifetimes won't be used).

[^1]: this prevents us from considering lifetimes from inside of the self-type

## Examples that were accepted before and will now be rejected

```rust
fn a(self: &Box<&Self>) -> &u32
fn b(self: &Pin<&mut Self>) -> &String
fn c(self: &mut &Self) -> Option<&Self>
fn d(self: &mut &Box<Self>, arg: &usize) -> &usize // previously used the lt from arg
```

### Examples that change the elided lifetime

```rust
fn e(self: &mut Box<Self>, arg: &usize) -> &usize
//         ^ new                ^ previous
```

## Examples that were rejected before and will now be accepted

```rust
fn f(self: &Box<Self>) -> &u32
```

---

*edit: old PR description:*

```rust
  struct Concrete(u32);

  impl Concrete {
      fn m(self: &Box<Self>) -> &u32 {
          &self.0
      }
  }
```

resulted in a confusing error.

```rust
  impl Concrete {
      fn n(self: &Box<&Self>) -> &u32 {
          &self.0
      }
  }
```

resulted in no error or warning, despite apparent ambiguity over the elided lifetime.

Fixes https://github.com/rust-lang/rust/issues/117715
2024-07-18 13:33:38 +00:00
Oneirical
47c21012ef rewrite archive-duplicate-names to rmake 2024-07-18 09:28:50 -04:00
Oneirical
aeca91e08d rewrite manual-link to rmake 2024-07-18 09:28:30 -04:00
Oneirical
06dcdbb2ee rewrite macos-fat-archive to rmake 2024-07-18 09:28:30 -04:00
onur-ozkan
6310da9ab9 remove debug-logging default from tools profile
`debug-logging` conflicts with `download-rustc` option, and doesn't really
make sense to enable it for a profile that is used for tool development.

Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-07-18 16:22:02 +03:00
onur-ozkan
0c5864f906 check default config profiles on CI
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-07-18 14:50:49 +03:00
Ralf Jung
0871175a4d make pub_use_of_private_extern_crate show up in future breakage reports 2024-07-18 13:43:56 +02:00
León Orell Valerian Liehr
2507301de0
Add internal lint for detecting non-glob imports of rustc_type_ir::inherent 2024-07-18 13:03:26 +02:00
bors
b01a977b07 Auto merge of #127906 - tgross35:rollup-41bhgce, r=tgross35
Rollup of 7 pull requests

Successful merges:

 - #127491 (Migrate 8 very similar FFI `run-make` tests to rmake)
 - #127687 (Const-to-pattern-to-MIR cleanup)
 - #127822 (Migrate `issue-85401-static-mir`, `missing-crate-dependency` and `unstable-flag-required` `run-make` tests to rmake)
 - #127842 (Remove `TrailingToken`.)
 - #127864 (cleanup: remove support for 3DNow! cpu features)
 - #127899 (Mark myself as on leave)
 - #127901 (Add missing GHA group for building `llvm-bitcode-linker`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-18 11:01:19 +00:00
Amos Wenger
d3303b02b5
Update extern linking documentation
In particular, remove the note saying cdylibs can't link against dylibs — that hasn't been true for over four years.

  * 2019-11-07: note is written: b54e8ecc2e
  * 2020-01-23: restriction is lifted (without updating docs): 72aaa3a414
2024-07-18 12:39:42 +02:00
Trevor Gross
16d2b61335
Rollup merge of #127901 - Kobzol:llvm-bitcode-linker-gha-group, r=onur-ozkan
Add missing GHA group for building `llvm-bitcode-linker`

Found while investigating https://github.com/rust-lang/rust/issues/127869.

r? `@onur-ozkan`
2024-07-18 05:14:09 -05:00
Trevor Gross
73eba8e3b4
Rollup merge of #127899 - oli-obk:leave, r=lqd
Mark myself as on leave

I will be on leave starting August 2nd, but I don't want to collect PRs until then that I won't be able to review
2024-07-18 05:14:08 -05:00
Trevor Gross
e4bc3d52bf
Rollup merge of #127864 - durin42:farewell-3dnow, r=nikic
cleanup: remove support for 3DNow! cpu features

In llvm/llvm-project@f0eb5587ce all support for 3DNow! intrinsics and instructions were removed. Per the commit message there, only AMD chips between 1998 and 2011 or so actually supported these instructions, and they were effectively replaced by SSE which was available on many more chips. I'd be very surprised if anyone had ever used these from Rust.

`@rustbot` label: +llvm-main
2024-07-18 05:14:07 -05:00
Trevor Gross
e2e0681e3a
Rollup merge of #127842 - nnethercote:rm-TrailingToken, r=petrochenkov
Remove `TrailingToken`.

It's used in `Parser::collect_tokens_trailing_token` to decide whether to capture a trailing token. But the callers actually know whether to capture a trailing token, so it's simpler for them to just pass in a bool.

Also, the `TrailingToken::Gt` case was weird, because it didn't result in a trailing token being captured. It could have been subsumed by the `TrailingToken::MaybeComma` case, and it effectively is in the new code.

r? `@petrochenkov`
2024-07-18 05:14:07 -05:00
Trevor Gross
d817c0f87a
Rollup merge of #127822 - Oneirical:amazon-rainfortest, r=jieyouxu
Migrate `issue-85401-static-mir`, `missing-crate-dependency` and `unstable-flag-required` `run-make` tests to rmake

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

try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc
try-job: aarch64-apple
try-job: dist-x86_64-linux
2024-07-18 05:14:06 -05:00
Trevor Gross
a2178dffc8
Rollup merge of #127687 - RalfJung:pattern-cleanup, r=oli-obk,lcnr
Const-to-pattern-to-MIR cleanup

Now that all uses of constants without structural equality are hard errors, there's a bunch of cleanup we can do in the code that handles patterns: we can always funnel patterns through valtrees first (rather than having a fallback path for when valtree construction fails), and we can make sure that if we emit a `PartialEq` call it is not calling anything user-defined.

To keep the error messages the same, I made valtree construction failures return the information of *which* type it is that cannot be valtree'd. `search_for_structural_match_violation` is now not needed any more at all, so I removed it.

r? `@oli-obk`
2024-07-18 05:14:05 -05:00
Trevor Gross
78fe5f76bf
Rollup merge of #127491 - Oneirical:bulletproof-test, r=jieyouxu
Migrate 8 very similar FFI `run-make` tests to rmake

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

There are some more of these, but while the code is almost always the same, I want to keep the number reasonable so my doc comments can be inspected for potential inaccuracies. Tell me if 8 is too much, I can cut this down.

For the tracking issue:

- issue-25581
- extern-fn-with-extern-types
- extern-fn-struct-passing-abi
- longjmp-across-rust
- static-extern-type
- extern-fn-explicit-align
- extern-fn-with-packed-struct
- extern-fn-mangle
2024-07-18 05:14:04 -05:00
Ralf Jung
303a2db236 remove saw_const_match_error; check if pattern contains an Error instead 2024-07-18 11:58:16 +02:00
Ralf Jung
67c99d6338 avoid creating an Instance only to immediately disassemble it again 2024-07-18 11:58:16 +02:00
Ralf Jung
86ce911f90 pattern lowering: make sure we never call user-defined PartialEq instances 2024-07-18 11:58:16 +02:00
Ralf Jung
e613bc92a1 const_to_pat: cleanup leftovers from when we had to deal with non-structural constants 2024-07-18 11:58:16 +02:00
Ralf Jung
fa74a9e6aa valtree construction: keep track of which type was valtree-incompatible 2024-07-18 11:58:16 +02:00
Jakub Beránek
69157bde3b
Add missing GHA group for building llvm-bitcode-linker 2024-07-18 10:08:45 +02:00
Nicholas Nethercote
487802d6c8 Remove TrailingToken.
It's used in `Parser::collect_tokens_trailing_token` to decide whether
to capture a trailing token. But the callers actually know whether to
capture a trailing token, so it's simpler for them to just pass in a
bool.

Also, the `TrailingToken::Gt` case was weird, because it didn't result
in a trailing token being captured. It could have been subsumed by the
`TrailingToken::MaybeComma` case, and it effectively is in the new code.
2024-07-18 17:28:49 +10:00
Oli Scherer
7f3f34db74 Mark myself as on leave 2024-07-18 06:32:53 +00:00
bors
52f3c71c8d Auto merge of #127898 - matthiaskrgr:rollup-lkkpoui, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #127077 (Make language around `ToOwned` for `BorrowedFd` more precise)
 - #127783 (Put the dots back in RTN pretty printing)
 - #127787 (Migrate `atomic-lock-free` to `rmake`)
 - #127810 (Rename `tcx` to `cx` in `rustc_type_ir`)
 - #127878 (Fix associated item removal suggestion)
 - #127886 (Accurate `use` rename suggestion span)
 - #127888 (More accurate span for type parameter suggestion)
 - #127889 (More accurate span for anonymous argument suggestion)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-07-18 06:11:35 +00:00
Matthias Krüger
77e5bbf341
Rollup merge of #127889 - estebank:anon-arg-sugg, r=compiler-errors
More accurate span for anonymous argument suggestion

Use smaller span for suggesting adding `_:` ahead of a type:

```
error: expected one of `(`, `...`, `..=`, `..`, `::`, `:`, `{`, or `|`, found `)`
  --> $DIR/anon-params-denied-2018.rs:12:47
   |
LL |     fn foo_with_qualified_path(<Bar as T>::Baz);
   |                                               ^ expected one of 8 possible tokens
   |
   = note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: explicitly ignore the parameter name
   |
LL |     fn foo_with_qualified_path(_: <Bar as T>::Baz);
   |                                ++
```
2024-07-18 08:09:02 +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
b52883decf
Rollup merge of #127886 - estebank:as-rename-suggestion, r=compiler-errors
Accurate `use` rename suggestion span

When suggesting to rename an import with `as`, use a smaller span to render the suggestion with a better format:

```
error[E0252]: the name `baz` is defined multiple times
  --> $DIR/issue-25396.rs:4:5
   |
LL | use foo::baz;
   |     -------- previous import of the module `baz` here
LL | use bar::baz;
   |     ^^^^^^^^ `baz` reimported here
   |
   = note: `baz` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
   |
LL | use bar::baz as other_baz;
   |              ++++++++++++
```
2024-07-18 08:09:01 +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
Matthias Krüger
b2b14deca5
Rollup merge of #127810 - compiler-errors:less-tcx, r=lcnr
Rename `tcx` to `cx` in `rustc_type_ir`

Self-explanatory. Forgot that we had to do this in type_ir too, and not just the new solver crate lol.

r? lcnr
2024-07-18 08:09:00 +02:00
Matthias Krüger
2013bf9077
Rollup merge of #127787 - Rejyr:migrate-atomic-lock-free-rmake, r=jieyouxu
Migrate `atomic-lock-free` to `rmake`

Also adds `llvm_components_contain` to `run-make-support`.

Part of #121876.

r? ``@jieyouxu``

try-job: dist-x86_64-linux
2024-07-18 08:08:59 +02:00
Matthias Krüger
97d5edf4b1
Rollup merge of #127783 - compiler-errors:rtn-pretty, r=fee1-dead
Put the dots back in RTN pretty printing

Also don't render RTN-like bounds for methods with ty/const params.
2024-07-18 08:08:59 +02:00
Matthias Krüger
3aafbd28e5
Rollup merge of #127077 - tbu-:pr_doc_fd_to_owned, r=workingjubilee
Make language around `ToOwned` for `BorrowedFd` more precise
2024-07-18 08:08:58 +02:00