Commit Graph

986 Commits

Author SHA1 Message Date
Michael Goulet
6d064295c8 clippy::useless_conversion 2024-09-11 17:52:53 -04:00
Camille GILLOT
6dfc4033be Do not ICE on expect(warnings). 2024-09-07 01:34:59 +00:00
Camille GILLOT
94f8347bae Check AttrId for expectations. 2024-09-06 20:51:06 +00:00
Matthias Krüger
cfb12716e9
Rollup merge of #129875 - Sajjon:sajjon_fix_typos_batch_1, r=compiler-errors,jieyouxu
chore: Fix typos in 'compiler' (batch 1)

Batch 1/3: Fixes typos in `compiler`

(See [issue](https://github.com/rust-lang/rust/issues/129874) tracking all PRs with typos fixes)
2024-09-02 22:35:20 +02:00
Alexander Cyon
ac69544a17
chore: Fix typos in 'compiler' (batch 1) 2024-09-02 07:42:38 +02:00
Camille GILLOT
5f1f45b095 Remove attr_id from stable lint ids. 2024-08-31 14:01:07 +00:00
Camille GILLOT
4928b22fa8 Use AttrId key for unstable<->stable expectation map. 2024-08-31 13:58:01 +00:00
Nicholas Nethercote
5fd503ab44 Add warn(unreachable_pub) to rustc_errors. 2024-08-27 12:03:37 +10:00
Pavel Grigorenko
53ce92770d Fix elided_named_lifetimes in code 2024-08-24 19:21:32 +03:00
Xiretza
c864238baf Update annotate-snippets to 0.11 2024-08-19 20:22:07 +00:00
Jaic1
8557b56ec7 Add | to make the html doc of Level rendered correctly 2024-08-14 13:38:03 +08: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
Matthias Krüger
32e0fe129d
Rollup merge of #128762 - fmease:use-more-slice-pats, r=compiler-errors
Use more slice patterns inside the compiler

Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.

r? ghost
2024-08-11 07:51:51 +02:00
Nadrieril
c256de2253 Update std and compiler 2024-08-10 12:07:17 +02:00
Matthias Krüger
2066002b86
Rollup merge of #128852 - folkertdev:multipart-suggestion-stable-sort, r=compiler-errors
use stable sort to sort multipart diagnostics

I think a stable sort should be used to sort the different parts of a multipart selection. The current unstable sort uses the text of the suggestion as a tie-breaker. That just doesn't seem right, and the order of the input is a better choice I think, because it gives the diagnostic author more control.

This came up when I was building a suggestion where

```rust
fn foo() {}
```

must be turned into an unsafe function, and an attribute must be added

```rust
#[target_feature(enable = "...")]
unsafe fn foo() {}
```

In this example, the two suggestions occur at the same position, but the order is extremely important: unsafe must come after the attribute. But the situation changes if there is a pub/pub(crate), and if the unsafe is already present. It just out that because of the suggestion text, there is no way for me to order the suggestions correctly.

This change probably should be tested, but are there tests of the diagnostics code itself in the tests?

r? ```@estebank```
2024-08-09 18:24:58 +02:00
Folkert
38874a6927
use stable sort to sort multipart diagnostics 2024-08-09 09:45:01 +02:00
Matthias Krüger
f106496b82
Rollup merge of #128806 - estebank:color-config, r=jieyouxu
Split `ColorConfig` off of `HumanReadableErrorType`

The previous setup tied two unrelated things together. Splitting these two is a better model.

Identified by https://github.com/rust-lang/rust/pull/126597/files#r1667800754
2024-08-09 00:03:36 +02:00
Esteban Küber
95c1c34fff review comments 2024-08-08 14:58:52 +00:00
Esteban Küber
ae696f847d Split ColorConfig off of HumanReadableErrorType
The previous setup tied two unrelated things together. Splitting these two is a better model.
2024-08-08 14:41:33 +00:00
bors
d3a393932e Auto merge of #128465 - GrigorenkoPV:128200, r=estebank
Some `const { }` asserts for #128200

The correctness of code in #128200 relies on an array being sorted (so that it can be used in binary search later), which is currently enforced with `// tidy-alphabetical` (and characters being written in `\u{XXXX}` form), as well as lack of duplicate entries with conflicting keys, which is not currently enforced.

This PR changes it to using a `const{ }` assertion (and also checks for duplicate entries). Sadly, we cannot use the recently-stabilized `is_sorted_by_key` here, because it is not const (but it would not allow us to check for uniqueness anyways). Instead, let's write a manual loop.

Alternative approach (perfect hash function): #128463

r? `@ghost`
2024-08-08 09:59:09 +00:00
León Orell Valerian Liehr
c4c518d2d4
Use more slice patterns inside the compiler 2024-08-07 13:37:52 +02:00
Esteban Küber
034b73ba54 fix test 2024-08-06 19:09:52 +00:00
Esteban Küber
db6c05f9b9 Maintain highlighting in note and help even when they have a span 2024-08-06 17:54:37 +00:00
bors
93ea767e29 Auto merge of #126804 - estebank:short-error-primary-label, r=davidtwco
On short error format, append primary span label to message

The `error-format=short` output only displays the path, error code and main error message all in the same line. We now add the primary span label as well after the error message, to provide more context.
2024-08-06 07:06:24 +00:00
Pavel Grigorenko
15982b2fca rustc_errors: fix inaccurate comment 2024-08-06 09:26:47 +03:00
Pavel Grigorenko
b0a8944120 rustc_errors: enforce OUTPUT_REPLACEMENTS is sorted with a compile-time assertion 2024-08-06 09:26:47 +03:00
Esteban Küber
1bbaf6eb2f On short error format, append primary span label to message
The `error-format=short` output only displays the path, error code and
main error message all in the same line. We now add the primary span label
as well after the error message, to provide more context.
2024-08-06 04:08:10 +00:00
bors
8c7e0e1608 Auto merge of #128200 - estebank:normalize-whitespace, r=pnkfelix
Change output normalization logic to be linear against size of output

Modify the rendered output normalization routine to scan each character *once* and construct a `String` to be printed out to the terminal *once*, instead of using `String::replace` in a loop multiple times. The output doesn't change, but the time spent to prepare a diagnostic is now faster (or rather, closer to what it was before #127528).
2024-08-06 03:44:38 +00:00
Esteban Küber
8ce8c42e0b Do not underline suggestions for code that is already there
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.

Fix clippy lint suggestion incorrectly treated as `span_help`.
2024-08-01 18:53:42 +00:00
Esteban Küber
51b5bb1798 Enforce sort order 2024-07-30 00:18:38 +00:00
Esteban Küber
3945480ce7 Use fold instead of flat_map 2024-07-29 19:03:25 +00:00
Esteban Küber
6d9ee6ee26 Change output normalization logic to be linear against size of output
Scan strings to be normalized for printing in a linear scan and collect
the resulting `String` only once.

Use a binary search when looking for chars to be replaced, instead of a
`HashMap::get`.
2024-07-29 18:40:58 +00: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
Matthias Krüger
cce2db06c0
Rollup merge of #127528 - estebank:ascii-control-chars, r=oli-obk
Replace ASCII control chars with Unicode Control Pictures

Replace ASCII control chars like `CR` with Unicode Control Pictures like `␍`:

```
error: bare CR not allowed in doc-comment
  --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32
   |
LL | /// doc comment with bare CR: '␍'
   |                                ^
```

Centralize the checking of unicode char width for the purposes of CLI display in one place. Account for the new replacements. Remove unneeded tracking of "zero-width" unicode chars, as we calculate these in the `SourceMap` as needed now.
2024-07-25 04:43:19 +02:00
Matthias Krüger
8e206c0387
Rollup merge of #126994 - Alexendoo:explain-markdown, r=tgross35
Support lists and stylings in more places for `rustc --explain`

Adds support for `*foo*`, stylings not immediately following whitespace e.g. ``(`Foo`)`` and lists starting with whitespace:

```md
* previously supported
```
```md
 * now also supported
 ```

These are fairly common in the existing error docs, some before/after examples:

### E0460

![image](https://github.com/rust-lang/rust/assets/1830331/4d0dc5dd-b71f-48b1-97ae-9f7199e952ed)
![image](https://github.com/rust-lang/rust/assets/1830331/4bbcb1e4-99ba-4d0d-b338-fe19d96a5eb1)

### E0059

![image](https://github.com/rust-lang/rust/assets/1830331/8457f69a-3126-4777-aa4a-953f7b29f59b)
![image](https://github.com/rust-lang/rust/assets/1830331/ac2189f8-512e-4b3b-886d-6c4a619d17f2)
2024-07-23 19:42:35 +02:00
Esteban Küber
9dffe9573b Make unicode text flow control chars visible as �
We already point these out quite aggressively, telling people not to use them, but would normally be rendered as nothing. Having them visible will make it easier for people to actually deal with them.

```
error: unicode codepoint changing visible direction of text present in literal
  --> $DIR/unicode-control-codepoints.rs:26:22
   |
LL |     println!("{:?}", '�');
   |                      ^-^
   |                      ||
   |                      |'\u{202e}'
   |                      this literal contains an invisible unicode text flow control codepoint
   |
   = note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen
   = help: if their presence wasn't intentional, you can remove them
help: if you want to keep them but make them visible in your source code, you can escape them
   |
LL |     println!("{:?}", '\u{202e}');
   |                       ~~~~~~~~
```

vs the previous

```
error: unicode codepoint changing visible direction of text present in literal
  --> $DIR/unicode-control-codepoints.rs:26:22
   |
LL |     println!("{:?}", '');
   |                      ^-
   |                      ||
   |                      |'\u{202e}'
   |                      this literal contains an invisible unicode text flow control codepoint
   |
   = note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen
   = help: if their presence wasn't intentional, you can remove them
help: if you want to keep them but make them visible in your source code, you can escape them
   |
LL |     println!("{:?}", '\u{202e}');
   |                       ~~~~~~~~
```
2024-07-18 20:08:43 +00:00
Esteban Küber
2d7795dfb9 Be more accurate about calculating display_col from a BytePos
No longer track "zero-width" chars in `SourceMap`, read directly from the line when calculating the `display_col` of a `BytePos`. Move `char_width` to `rustc_span` and use it from the emitter.

This change allows the following to properly align in terminals (depending on the font, the replaced control codepoints are rendered as 1 or 2 width, on my terminal they are rendered as 1, on VSCode text they are rendered as 2):

```
error: this file contains an unclosed delimiter
  --> $DIR/issue-68629.rs:5:17
   |
LL | ␜␟ts␀![{i
   |       -- unclosed delimiter
   |       |
   |       unclosed delimiter
LL | ␀␀  fn rݻoa>rݻm
   |                ^
```
2024-07-18 20:08:38 +00:00
Esteban Küber
89f273f40d Replace ASCII control chars with Unicode Control Pictures
```
error: bare CR not allowed in doc-comment
  --> $DIR/lex-bare-cr-string-literal-doc-comment.rs:3:32
   |
LL | /// doc comment with bare CR: '␍'
   |                                ^
```
2024-07-18 19:23:42 +00:00
Alex Macleod
5824ab178b Support lists and stylings in more places for rustc --explain 2024-07-10 13:41:36 +00:00
Matthias Krüger
c4ee2df539
Rollup merge of #120248 - WaffleLapkin:bonk-ptr-object-casts, r=compiler-errors,oli-obk,lnicola
Make casts of pointers to trait objects stricter

This is an attempt to `fix` https://github.com/rust-lang/rust/issues/120222 and https://github.com/rust-lang/rust/issues/120217.

This is done by adding restrictions on casting pointers to trait objects.

Before this PR the rules were as follows:

> When casting `*const X<dyn A>` -> `*const Y<dyn B>`, principal traits in `A` and `B` must refer to the same trait definition (or no trait).

With this PR the rules are changed to

> When casting `*const X<dyn Src>` -> `*const Y<dyn Dst>`
> - if `Dst` has a principal trait `DstP`,
>   - `Src` must have a principal trait `SrcP`
>   - `dyn SrcP` and `dyn DstP` must be the same type (modulo the trait object lifetime, `dyn T+'a` -> `dyn T+'b` is allowed)
>   - Auto traits in `Dst` must be a subset of auto traits in `Src`
>     - Not adhering to this is currently a FCW (warn-by-default + `FutureReleaseErrorReportInDeps`), instead of an error
> - if `Src` has a principal trait `Dst` must as well
>   - this restriction will be removed in a follow up PR

This ensures that
1. Principal trait's generic arguments match (no `*const dyn Tr<A>` -> `*const dyn Tr<B>` casts, which are a problem for [#120222](https://github.com/rust-lang/rust/issues/120222))
2. Principal trait's lifetime arguments match (no `*const dyn Tr<'a>` -> `*const dyn Tr<'b>` casts, which are a problem for [#120217](https://github.com/rust-lang/rust/issues/120217))
3. No auto traits can be _added_ (this is a problem for arbitrary self types, see [this comment](https://github.com/rust-lang/rust/pull/120248#discussion_r1463835350))

Some notes:
 - We only care about the metadata/last field, so you can still cast `*const dyn T` to `*const WithHeader<dyn T>`, etc
- The lifetime of the trait object itself (`dyn A + 'lt`) is not checked, so you can still cast `*mut FnOnce() + '_` to `*mut FnOnce() + 'static`, etc
  - This feels fishy, but I couldn't come up with a reason it must be checked

The diagnostics are currently not great, to say the least, but as far as I can tell this correctly fixes the issues.

cc `@oli-obk` `@compiler-errors` `@lcnr`
2024-07-08 16:28:15 +02:00
Maybe Lapkin
b16f803431 Make DiagSymbolList more generic 2024-07-04 17:57:31 +02:00
Esteban Küber
a06a18a47f Properly handle removal suggestion rendering
Do not leave a `+ ` line with only whitespace. In reality, the user will want to remove the entire line.
2024-07-04 05:04:48 +00:00
bors
7b21c18fe4 Auto merge of #126996 - oli-obk:do_not_count_errors, r=nnethercote
Automatically taint InferCtxt when errors are emitted

r? `@nnethercote`

Basically `InferCtxt::dcx` now returns a `DiagCtxt` that refers back to the `Cell<Option<ErrorGuaranteed>>` of the `InferCtxt` and thus when invoking `Diag::emit`, and the diagnostic is an error, we taint the `InferCtxt` directly.

That change on its own has no effect at all, because `InferCtxt` already tracks whether errors have been emitted by recording the global error count when it gets opened, and checking at the end whether the count changed. So I removed that error count check, which had a bit of fallout that I immediately fixed by invoking `InferCtxt::dcx` instead of `TyCtxt::dcx` in a bunch of places.

The remaining new errors are because an error was reported in another query, and never bubbled up. I think they are minor enough for this to be ok, and sometimes it actually improves diagnostics, by not silencing useful diagnostics anymore.

fixes #126485 (cc `@olafes)`

There are more improvements we can do (like tainting in hir ty lowering), but I would rather do that in follow up PRs, because it requires some refactorings.
2024-07-01 06:35:58 +00:00
Oli Scherer
bd111f5c4b Document new field and function 2024-06-27 09:45:26 +00:00
Oli Scherer
86c8eae774 Automatically taint InferCtxt when errors are emitted 2024-06-26 16:01:45 +00:00
Oli Scherer
5988078aa2 Restrict diagnostic context lifetime of InferCtxt to itself instead of TyCtxt 2024-06-26 16:01:44 +00:00
Urgau
7666534381
Clarify comment on changing to warn future breakage items
https://github.com/rust-lang/rust/pull/120924/files#r1653512240
2024-06-26 17:00:46 +02:00
xFrednet
1d667a0937
Prevent ICE from expected future breakage 2024-06-25 22:32:46 +02:00
Esteban Küber
284437d434 Special case when a code line only has multiline span starts
```
3 |       X0 Y0 Z0
  |  _____^  -  -
  | | _______|  |
  | || _________|
4 | |||   X1 Y1 Z1
5 | |||   X2 Y2 Z2
  | |||____^__-__- `Z` label
  | ||_____|__|
  | |______|  `Y` is a good letter too
  |        `X` is a good letter
```
2024-06-23 22:00:52 +00:00