Commit Graph

440 Commits

Author SHA1 Message Date
Matthias Krüger
ea9c370ffe
Rollup merge of #100970 - Xiretza:derive-multipart-suggestion, r=davidtwco
Allow deriving multipart suggestions

This turned into a bit more of a rewrite than I was initially hoping for... Still, I think the `SessionSubdiagnostic` derive is a little cleaner overall now, and closer to the `SessionDiagnostic` derive to make future code sharing easier.

r? ``@davidtwco``
2022-08-31 07:57:54 +02:00
Xiretza
8af7f4208a Code deduplication in tool_only_multipart_suggestion 2022-08-30 09:46:42 +02:00
Donough Liu
97b1a6146c Use more into_iter rather than drain(..) 2022-08-30 04:42:03 +01:00
Nilstrieb
d1ef8180f9 Revert let_chains stabilization
This reverts commit 3266460749.

This is the revert against master, the beta revert was already done in #100538.
2022-08-29 19:34:11 +02:00
Michael Goulet
18b640aee5 Suggest calling when operator types mismatch 2022-08-28 01:08:24 +00:00
David Wood
c18503f3ff
errors: IntoDiagnosticArg for io::Error/paths
Add impls of `IntoDiagnosticArg` for `std::io::Error`, `std::path::Path`
and `std::path::PathBuf`.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-08-24 06:50:44 +09:00
Xiretza
91ad4e38f5 Add Handler::struct_diagnostic()
This unifies the struct_{warn,error,fatal}() methods in one generic
method.
2022-08-21 09:17:43 +02:00
Matthias Krüger
8828af4d88
Rollup merge of #99935 - CAD97:unstable-syntax-lints, r=petrochenkov
Reenable disabled early syntax gates as future-incompatibility lints

- MCP: https://github.com/rust-lang/compiler-team/issues/535

The approach taken by this PR is

- Introduce a new lint, `unstable_syntax_pre_expansion`, and reenable the early syntax gates to emit it
- Use the diagnostic stashing mechanism to stash warnings the early warnings
- When the hard error occurs post expansion, steal and cancel the early warning
- Don't display any stashed warnings if errors are present to avoid the same noise problem that hiding type ascription errors is avoiding

Commits are working commits, but in a coherent steps-to-implement manner. Can be squashed if desired.

The preexisting `soft_unstable` lint seems like it would've been a good fit, but it is deny-by-default (appropriate for `#[bench]`) and these gates should be introduced as warn-by-default.

It may be desirable to change the stash mechanism's behavior to not flush lint errors in the presence of other errors either (like is done for warnings here), but upgrading a stash-using lint from warn to error perhaps is enough of a request to see the lint that they shouldn't be hidden; additionally, fixing the last error to get new errors thrown at you always feels bad, so if we know the lint errors are present, we should show them.

Using a new flag/mechanism for a "weak diagnostic" which is suppressed by other errors may also be desirable over assuming any stashed warnings are "weak," but this is the first user of stashing warnings and seems an appropriate use of stashing (it follows the "know more later to refine the diagnostic" pattern; here we learn that it's in a compiled position) so we get to define what it means to stash a non-hard-error diagnostic.

cc `````@petrochenkov````` (seconded MCP)
2022-08-20 19:45:10 +02:00
Dylan DPC
2fe2975391
Rollup merge of #100081 - RalfJung:unused-unsafe-in-unsafe-fn, r=jackh726
never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn)

Judging from https://github.com/rust-lang/rust/issues/71668#issuecomment-1200317370 the consensus nowadays seems to be that we should never consider an unsafe block unused if it was required with `deny(unsafe_op_in_unsafe_fn)`, no matter whether that lint is actually enabled or not. So let's adjust rustc accordingly.

The first commit does the change, the 2nd does some cleanup.
2022-08-19 12:26:40 +05:30
Matthias Krüger
8b180ed3c0
Rollup merge of #100651 - nidnogg:diagnostics_migration_expand_transcribe, r=davidtwco
Migrations for rustc_expand transcribe.rs

This PR includes some migrations to the new diagnostics API for the `rustc_expand` module.
r? ```@davidtwco```
2022-08-18 05:10:47 +02:00
nidnogg
c6f9a9c410 Moved structs to rustc_expand::errors, added several more migrations, fixed slug name 2022-08-17 11:18:19 -03:00
Christopher Durham
767239f740 Reenable early feature-gates as future-compat warnings 2022-08-17 06:53:18 -05:00
Christopher Durham
e9e46c95ce Don't treat stashed warnings as errors 2022-08-17 06:07:33 -05:00
Matthias Krüger
989e4ffc7c
Rollup merge of #100379 - davidtwco:triagebot-diag, r=Mark-Simulacrum
triagebot: add translation-related mention groups

- Move some code around so that triagebot can ping relevant parties when translation logic is modified.
- Add mention groups to triagebot for translation-related files/folders.
- Auto-label pull requests with changes to translation-related files/folders with `A-translation`.

r? `@Mark-Simulacrum`
2022-08-17 12:32:50 +02:00
Matthias Krüger
76dd1663d9
Rollup merge of #100590 - TaKO8Ki:suggest-adding-array-length, r=compiler-errors
Suggest adding an array length if possible

fixes #100448
2022-08-16 06:05:59 +02:00
Takayuki Maeda
4d1b5f0d99 suggest adding an array length if possible 2022-08-16 00:16:14 +09:00
David Wood
510ba031dc errors: move translation logic into module
Just moving code around so that triagebot can ping relevant parties when
translation logic is modified.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-08-15 12:26:35 +01:00
Mark Rousskov
154a09dd91 Adjust cfgs 2022-08-12 16:28:15 -04:00
David Wood
2eebd34cd5 errors: don't fail on broken primary translations
If a primary bundle doesn't contain a message then the fallback bundle
is used. However, if the primary bundle's message is broken (e.g. it
refers to a interpolated variable that the compiler isn't providing)
then this would just result in a compiler panic. While there aren't any
primary bundles right now, this is the type of issue that could come up
once translation is further along.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-08-10 11:48:25 +01:00
Matthias Krüger
e10f924e27
Rollup merge of #99573 - tbodt:stabilize-backtrace, r=yaahc
Stabilize backtrace

This PR stabilizes the std::backtrace module. As of #99431, the std::Error::backtrace item has been removed, and so the rest of the backtrace feature is set to be stabilized.

Previous discussion can be found in #72981, #3156.

Stabilized API summary:
```rust
pub mod std {
    pub mod backtrace {
        pub struct Backtrace { }
        pub enum BacktraceStatus {
            Unsupported,
            Disabled,
            Captured,
        }
        impl fmt::Debug for Backtrace {}
        impl Backtrace {
            pub fn capture() -> Backtrace;
            pub fn force_capture() -> Backtrace;
            pub const fn disabled() -> Backtrace;
            pub fn status(&self) -> BacktraceStatus;
        }
        impl fmt::Display for Backtrace {}
    }
}
```

`@yaahc`
2022-08-10 07:21:33 +02:00
Matthias Krüger
aaa054e53c
Rollup merge of #100071 - klensy:annotate-snippets-bump, r=Mark-Simulacrum
deps: dedupe `annotate-snippets` crate versions

Dedupes `annotate-snippets` crate versions (https://github.com/rust-lang/annotate-snippets-rs/blob/0.9.1/CHANGELOG.md). Should work, but there is not a lot of tests.

Looks like switching to that crate a bit stalled.
2022-08-07 01:19:32 +02:00
Michael Goulet
694a010a5c move DiagnosticArgFromDisplay into rustc_errors 2022-08-05 16:44:01 +00:00
Theodore Dubois
53a870c506 Stabilize backtrace 2022-08-02 16:21:20 -07:00
Ralf Jung
ee3fc9dff8 never consider unsafe blocks unused if they would be required with unsafe_op_in_unsafe_fn 2022-08-02 17:09:41 -04:00
klensy
754b52669f dedupe 'annotate-snippets' crate versions 2022-08-02 21:07:01 +03:00
bors
be9cfb307e Auto merge of #99058 - michaelwoerister:remove-stable-set-and-map, r=nagisa
Remove the unused StableSet and StableMap types from rustc_data_structures.

The current implementation is not "stable" in the same sense that `HashStable` and `StableHasher` are stable, i.e. across compilation sessions. So, in my opinion, it's better to remove those types (which are basically unused anyway) than to give the wrong impression that these are safe for incr. comp.

I plan to provide new "stable" collection types soon that can be used to replace `FxHashMap` and `FxHashSet` in query results (see [draft](69d03ac7a7)). It's unsound that `HashMap` and `HashSet` implement `HashStable` (see https://github.com/rust-lang/rust/issues/98890 for a recent P-critical bug caused by this) -- so we should make some progress there.
2022-07-20 22:19:30 +00:00
Michael Woerister
88f6c6d8a0 Remove unused StableMap and StableSet types from rustc_data_structures 2022-07-20 13:11:39 +02:00
Takayuki Maeda
56e7777755 avoid &str to String conversions 2022-07-20 18:19:57 +09:00
Michael Goulet
01b2379e49 Mention first and last macro in backtrace 2022-07-19 03:07:54 +00:00
Matthias Krüger
6277ac2fb8
Rollup merge of #99342 - TaKO8Ki:avoid-symbol-to-string-conversions, r=compiler-errors
Avoid some `Symbol` to `String` conversions

This patch removes some Symbol to String conversions.
2022-07-16 22:30:56 +02:00
Takayuki Maeda
c54d4ada26 avoid some Symbol to String conversions 2022-07-17 04:09:20 +09:00
David Wood
78b19a90b7 passes: migrate half of check_attr
Migrate half of the `rustc_passes::check_attr` diagnostics to using
diagnostic derives and being translatable.
2022-07-15 16:13:49 +01:00
David Wood
c3fdf74885 errors: lint on LintDiagnosticBuilder::build
Apply the `#[rustc_lint_diagnostics]` attribute to
`LintDiagnosticBuilder::build` so that diagnostic migration lints will
trigger for it.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-15 16:13:47 +01:00
David Wood
06f480661f errors: impl IntoDiagnosticArg for char
Implements `IntoDiagnosticArg` for `char` using its `Debug`
implementation and introduces a macro for those types which just
delegate the implementation to `ToString`.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-15 16:12:46 +01:00
Matthias Krüger
d89c183554
Rollup merge of #99075 - danobi:dup_type_hint_sugg, r=petrochenkov
Fix duplicated type annotation suggestion

Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.

This fixes #93506 .
2022-07-11 22:39:05 +02:00
Takayuki Maeda
018155c3a2 rename a method 2022-07-11 16:51:19 +09:00
Takayuki Maeda
12d11e9a35 implement is_accessible_span 2022-07-11 11:36:15 +09:00
Daniel Xu
34e9e6dff1 Fix duplicated type annotation suggestion
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.

This fixes #93506 .
2022-07-08 21:03:03 -05:00
Dylan DPC
dbae8309a0
Rollup merge of #98657 - compiler-errors:rustc-const-eval-session-diagnostic-1, r=davidtwco
Migrate some diagnostics from `rustc_const_eval` to `SessionDiagnostic`

I'm still trying to get the hang of this, so it doesn't migrate _all_ of `rustc_const_eval`. Working on that later.

r? `@davidtwco`
2022-07-08 18:25:50 +05:30
Matthias Krüger
b36e58a458
Rollup merge of #95635 - davidtwco:terminal-width-stabilization, r=oli-obk
sess: stabilize `--terminal-width` as `--diagnostic-width`

Formerly `-Zterminal-width`, `--terminal-width` allows the user or build
tool to inform rustc of the width of the terminal so that diagnostics
can be truncated.

Pending agreement to stabilize, see tracking issue at #84673.

r? ```@oli-obk```
2022-07-08 08:00:36 +02:00
Michael Goulet
ff9fd36aa4 Implement IntoDiagnosticArg for hir::ConstContext 2022-07-08 03:47:31 +00:00
David Wood
44c1fcc04d session: output-width -> diagnostic-width
Rename the `--output-width` flag to `--diagnostic-width` as this appears
to be the preferred name within the compiler team.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-06 17:43:33 +01:00
David Wood
cd23af6793 session: terminal-width -> output-width
Rename the `--terminal-width` flag to `--output-width` as the behaviour
doesn't just apply to terminals (and so is slightly less accurate).

Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-06 17:38:18 +01:00
David Wood
540eaf985d errors: introduce DecorateLint
Add a new trait to be generated by diagnostic derives which uses a
`LintDiagnosticBuilder`.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-05 16:00:20 +01:00
David Wood
2874f09534 lint: LintDiagnosticBuilder into rustc_errors
Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-05 16:00:20 +01:00
Dylan DPC
291df97fae
Rollup merge of #98624 - davidtwco:translation-on-lints, r=compiler-errors
lints: mostly translatable diagnostics

As lints are created slightly differently than other diagnostics, intended to try make them translatable first and then look into the applicability of diagnostic structs but ended up just making most of the diagnostics in the crate translatable (which will still be useful if I do make a lot of them structs later anyway).

r? ``@compiler-errors``
2022-07-05 16:04:32 +05:30
bors
ada8c80bed Auto merge of #98673 - pietroalbini:pa-bootstrap-update, r=Mark-Simulacrum
Bump bootstrap compiler

r? `@Mark-Simulacrum`
2022-07-03 06:55:50 +00:00
Pietro Albini
6b2d3d5f3c
update cfg(bootstrap)s 2022-07-01 15:48:23 +02:00
Matthias Krüger
8385d6bee4
Rollup merge of #98695 - tshepang:or-pattern, r=compiler-errors
use "or pattern"
2022-06-30 19:55:55 +02:00
David Wood
bd8fe82138 lint: port incomplete features diagnostics
Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-30 08:59:22 +01:00
David Wood
10676418fa lint: port keyword idents diagnostics
Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-30 08:59:22 +01:00
David Wood
14c3016583 lint: port variant size difference diagnostics
Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-30 08:59:21 +01:00
David Wood
7a9bef4d83 lint: port overflowing literals diagnostics
Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-30 08:59:21 +01:00
David Wood
7ee4aa7003 lint: port non-fmt-panic diagnostics
Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-30 08:59:21 +01:00
David Wood
7d2eba6311 middle: translation in LintDiagnosticBuilder
Accept `DiagnosticMessage` in `LintDiagnosticBuilder::build` so that
lints can be built with translatable diagnostic messages.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-30 08:58:41 +01:00
Tshepang Mbambo
398e7784dd use "or pattern" 2022-06-30 03:05:51 +02:00
Michael Goulet
98af1bfecc Migrate some rustc_borrowck diagnostics to SessionDiagnostic 2022-06-28 22:41:56 +00:00
Maybe Waffle
ffb593bf4d remove MAX_SUGGESTION_HIGHLIGHT_LINES 2022-06-20 00:25:51 +04:00
bors
0cb9899e78 Auto merge of #97892 - klensy:fix-spaces, r=oli-obk
diagnostics: remove trailing spaces

Remove few occurrences of trailing spaces and drive by fix of needless alloc of const string.
2022-06-17 17:30:16 +00:00
Dylan DPC
74aa55b3fc
Rollup merge of #97798 - WaffleLapkin:allow_for_suggestions_that_are_quite_far_away_from_each_other, r=estebank
Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown

This is an attempt to fix suggestions one part of which is 6 lines or more far from the first. I've noticed "the problem" (of not showing some parts of the suggestion) here: https://github.com/rust-lang/rust/pull/97759#discussion_r889689230.

I'm not sure about the implementation (this big closure is just bad and makes already complicated code even more so), but I want to at least discuss the result.

Here is an example of how this changes the output:

Before:
```text
help: consider enclosing expression in a block
  |
3 ~     'l: { match () { () => break 'l,
4 |
5 |
6 |
7 |
8 |
...
```

After:
```text
help: consider enclosing expression in a block
  |
3 ~     'l: { match () { () => break 'l,
4 |
...
31|
32~ } };
  |
```

r? `@estebank`
`@rustbot` label +A-diagnostics +A-suggestion-diagnostics
2022-06-17 12:21:48 +02:00
Maybe Waffle
3c55672795 Add back MAX_SUGGESTION_HIGHLIGHT_LINES so clippy is happy & buildable 2022-06-16 17:08:26 +04:00
Maybe Waffle
cf6f821c33 Try to clean up code...
I'm not sure if I succeeded
2022-06-16 17:08:26 +04:00
Maybe Waffle
87fded1edd Improve suggestions when its parts are far from each other
Previously we only show at most 6 lines of suggestions and, if the
suggestions are more than 6 lines apart, we've just showed ... at the
end. This is probably fine, but quite confusing in my opinion.

This commit is an attempt to show ... in places where there is nothing
to suggest instead, for example:

Before:
```text
help: consider enclosing expression in a block
  |
3 ~     'l: { match () { () => break 'l,
4 |
5 |
6 |
7 |
8 |
...
```

After:
```text
help: consider enclosing expression in a block
  |
3 ~     'l: { match () { () => break 'l,
4 |
...
31|
32~ } };
  |
```
2022-06-16 17:08:26 +04:00
Maybe Waffle
260c5fd587 Fix a typo
!(a & b) = !a | !b
2022-06-16 17:08:26 +04:00
klensy
68ea8ff16f drive by fix needless allocation of const string number 2022-06-16 14:40:30 +03:00
klensy
989d1a732f fix one more case of trailing space 2022-06-16 14:40:29 +03:00
klensy
0ff8ae3111 diagnostics: fix trailing space 2022-06-16 14:40:28 +03:00
Matthias Krüger
95be954af4
Rollup merge of #97757 - xFrednet:rfc-2383-expect-with-force-warn, r=wesleywiser,flip1995
Support lint expectations for `--force-warn` lints (RFC 2383)

Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.

This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.

This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.

---

r? `@wesleywiser`

cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃

Follow-up of: https://github.com/rust-lang/rust/pull/87835

Issue: https://github.com/rust-lang/rust/issues/85549

Yeah, and that's it.
2022-06-16 09:10:20 +02:00
xFrednet
8527a3d369
Support lint expectations for --force-warn lints (RFC 2383) 2022-06-16 08:16:43 +02:00
Dylan DPC
d8333a7b59
Rollup merge of #97948 - davidtwco:diagnostic-translation-lints, r=oli-obk
lint: add diagnostic translation migration lints

Introduce allow-by-default lints for checking whether diagnostics are written in
`SessionDiagnostic` or `AddSubdiagnostic` impls and whether diagnostics are translatable. These lints can be denied for modules once they are fully migrated to impls and translation.

These lints are intended to be temporary - once all diagnostics have been changed then we can just change the APIs we have and that will enforce these constraints thereafter.

r? `````@oli-obk`````
2022-06-14 10:35:31 +02:00
David Wood
5ba81faba6 lint: add diagnostic translation migration lints
Introduce allow-by-default lints for checking whether diagnostics are
written in `SessionDiagnostic`/`AddSubdiagnostic` impls and whether
diagnostics are translatable. These lints can be denied for modules once
they are fully migrated to impls and translation.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-10 15:50:06 +01:00
Yuki Okushi
18404540d7
Rollup merge of #97718 - xFrednet:95540-delayed-good-path-ice-for-expect, r=wesleywiser
Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)

Fixes a small ICE with the `delayed_good_path_bug` check.

---

r? ``@wesleywiser``

cc: ``@eddyb`` this might be interesting, since you've added a `FIXME` comment above the modified check which kind of discusses a case like this

closes: https://github.com/rust-lang/rust/issues/95540

cc: https://github.com/rust-lang/rust/issues/85549
2022-06-10 17:22:28 +09:00
bors
bb55bd449e Auto merge of #95565 - jackh726:remove-borrowck-mode, r=nikomatsakis
Remove migrate borrowck mode

Closes #58781
Closes #43234

# Stabilization proposal

This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors, then MIR borrowck (NLL) never occurs. If there *aren't* any errors, then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program, this should not break any programs. It does, however, change diagnostics significantly and allows a slightly larger set of programs to compile.

Tracking issue: #43234
RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md
Version: 1.63 (2022-06-30 => beta, 2022-08-11 => stable).

## Motivation

Over time, the Rust borrow checker has become "smarter" and thus allowed more programs to compile. There have been three different implementations: AST borrowck, MIR borrowck, and polonius (well, in progress). Additionally, there is the "lexical region resolver", which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker, but does emit some errors.

The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017, work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017, for the most part. During 2018, efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into "migrate" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition.

In early 2019, migrate mode was turned on by default in the 2015 edition as well, but with MIR borrowck errors emitted as warnings. By late 2019, these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker.

In the period since, various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver.

While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics), those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff.

## What is stabilized

As said previously, this does not fundamentally change the landscape of accepted programs. However, there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)`, but not otherwise.

There are two notable patterns that are "fixed" by this stabilization. First, the `scoped_threads` feature, which is a continutation of a pre-1.0 API, can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second, actually seen in the standard library. In the `Extend` impl for `HashMap`, there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl.

As mentioned before, there are a large number of diagnostic differences. Most of them are better, but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general "lifetime may not live long enough" error. While this may *seem* bad, the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however, on paper, they end up being roughly the same with roughly the same kinds of solutions.

## What isn't stabilized

This PR does not completely remove the lexical region resolver. In the future, it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck.

## Tests

Many test outputs get updated by this PR. However, there are number of tests specifically geared towards NLL under `src/test/ui/nll`

## History

* On 2017-07-14, [tracking issue opened](https://github.com/rust-lang/rust/issues/43234)
* On 2017-07-20, [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271)
* On 2017-08-29, [RFC opened](https://github.com/rust-lang/rfcs/pull/2094)
* On 2017-11-16, [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825)
* On 2017-12-20, [NLL feature complete](https://github.com/rust-lang/rust/pull/46862)
* On 2018-07-07, [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083)
* On 2018-07-27, [Add migrate mode](https://github.com/rust-lang/rust/pull/52681)
* On 2019-04-22, [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114)
* On 2019-08-26, [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221)
* On 2019-08-27, [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)
2022-06-07 05:04:14 +00:00
bors
4322a785cc Auto merge of #97697 - WaffleLapkin:no_ref_vec, r=WaffleLapkin
Replace `&Vec<_>`s with `&[_]`s

It's generally preferable to use `&[_]` since it's one less indirection and it can be created from types other that `Vec`.

I've left `&Vec` in some locals where it doesn't really matter, in cases where `TypeFoldable` is expected (`TypeFoldable: Clone` so slice can't implement it) and in cases where it's `&TypeAliasThatIsActiallyVec`. Nothing important, really, I was just a little annoyed by `visit_generic_param_vec` :D

r? `@compiler-errors`
2022-06-05 09:30:53 +00:00
xFrednet
157e68d01b
Fix delayed_good_path_bug ice for expected diagnostics (RFC 2383) 2022-06-04 00:43:24 +02:00
Jack Huey
410dcc9674 Fully stabilize NLL 2022-06-03 17:16:41 -04:00
bjorn3
62a4f91a5a Use serde_json for json error messages 2022-06-03 16:46:19 +00:00
Maybe Waffle
afaa9854fa Replace &Vec<_>s with &[_]s 2022-06-03 20:42:42 +04:00
Esteban Küber
310b1a9062 Mention filename in suggestion when it differs from primary span 2022-06-01 09:52:03 -07:00
bors
7be9ec2765 Auto merge of #97357 - davidtwco:diagnostic-translation-typed-subdiagnostic-simplification, r=oli-obk
errors: simplify referring to fluent attributes

To render the message of a Fluent attribute, the identifier of the Fluent message must be known. `DiagnosticMessage::FluentIdentifier` contains both the message's identifier and optionally the identifier of an attribute. Generated constants for each attribute would therefore need to be named uniquely (amongst all error messages) or be able to refer to only the attribute identifier which will be combined with a message identifier later. In this commit, the latter strategy is implemented as part of the `Diagnostic` type's functions for adding subdiagnostics of various kinds.

r? `@oli-obk`
2022-05-30 22:49:36 +00:00
David Wood
f669b78ffc errors: simplify referring to fluent attributes
To render the message of a Fluent attribute, the identifier of the
Fluent message must be known. `DiagnosticMessage::FluentIdentifier`
contains both the message's identifier and optionally the identifier of
an attribute. Generated constants for each attribute would therefore
need to be named uniquely (amongst all error messages) or be able to
refer to only the attribute identifier which will be combined with a
message identifier later. In this commit, the latter strategy is
implemented as part of the `Diagnostic` type's functions for adding
subdiagnostics of various kinds.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-05-30 13:38:19 +01:00
Yuki Okushi
5a4e9363a3
Ensure source file present when calculating max line number
Co-authored-by: Ross MacArthur <ross@macarthur.io>
2022-05-29 11:29:49 +09:00
David Wood
552eb3295a macros: introduce fluent_messages macro
Adds a new `fluent_messages` macro which performs compile-time
validation of the compiler's Fluent resources (i.e. that the resources
parse and don't multiply define the same messages) and generates
constants that make using those messages in diagnostics more ergonomic.

For example, given the following invocation of the macro..

```ignore (rust)
fluent_messages! {
    typeck => "./typeck.ftl",
}
```
..where `typeck.ftl` has the following contents..

```fluent
typeck-field-multiply-specified-in-initializer =
    field `{$ident}` specified more than once
    .label = used more than once
    .label-previous-use = first use of `{$ident}`
```
...then the macro parse the Fluent resource, emitting a diagnostic if it
fails to do so, and will generate the following code:

```ignore (rust)
pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[
    include_str!("./typeck.ftl"),
];

mod fluent_generated {
    mod typeck {
        pub const field_multiply_specified_in_initializer: DiagnosticMessage =
            DiagnosticMessage::fluent("typeck-field-multiply-specified-in-initializer");
        pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage =
            DiagnosticMessage::fluent_attr(
                "typeck-field-multiply-specified-in-initializer",
                "previous-use-label"
            );
    }
}
```

When emitting a diagnostic, the generated constants can be used as
follows:

```ignore (rust)
let mut err = sess.struct_span_err(
    span,
    fluent::typeck::field_multiply_specified_in_initializer
);
err.span_default_label(span);
err.span_label(
    previous_use_span,
    fluent::typeck::field_multiply_specified_in_initializer_label_previous_use
);
err.emit();
```

Signed-off-by: David Wood <david.wood@huawei.com>
2022-05-24 16:48:17 +01:00
Jacob Pratt
49c82f31a8
Remove crate visibility usage in compiler 2022-05-20 20:04:54 -04:00
David Wood
de3e8ca2f3 errors: set_arg takes IntoDiagnosticArg
Manual implementors of translatable diagnostics will need to call
`set_arg`, not just the derive, so make this function a bit more
ergonomic by taking `IntoDiagnosticArg` rather than
`DiagnosticArgValue`.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-05-12 07:21:51 +01:00
Fridtjof Stoldt
9516a40f1e
Fixed typo in docs and correct doc links
Co-authored-by: Philipp Krones <hello@philkrones.com>
2022-05-08 17:24:15 +02:00
xFrednet
7f03681cd9
Only assert for unstable expectation ids after conversion (RFC 2383)
This ICE was reported by `@matthiaskrgr`. A big THANK YOU to him. See `rust#94953`
2022-05-08 14:37:14 +02:00
Elliot Roberts
7907385999 fix most compiler/ doctests 2022-05-02 17:40:30 -07:00
David Wood
49ec909ca7 macros: subdiagnostic derive
Add a new derive, `#[derive(SessionSubdiagnostic)]`, which enables
deriving structs for labels, notes, helps and suggestions.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-29 02:05:20 +01:00
David Wood
73fa217bc1 errors: span_suggestion takes impl ToString
Change `span_suggestion` (and variants) to take `impl ToString` rather
than `String` for the suggested code, as this simplifies the
requirements on the diagnostic derive.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-29 02:05:20 +01:00
Jeremy Fitzhardinge
c6bafa7322 Add --json unused-externs-silent with original behaviour
Since Cargo wants to do its own fatal error handling for unused
dependencies, add the option `--json unused-externs-silent` which
has the original behaviour of not indicating non-zero exit status for
`deny`/`forbid`-level unused dependencies.
2022-04-27 10:04:25 -07:00
Jeremy Fitzhardinge
0529a13b5d Plumb through rustc_lint_defs::Level as enum rather than string. 2022-04-27 10:04:25 -07:00
Jeremy Fitzhardinge
39f2f18463 Make --json unused-extern deny/forbid level messages cause exit with error status
Closes: https://github.com/rust-lang/rust/issues/96068
2022-04-27 10:04:25 -07:00
Dylan DPC
93db30aa7f
Rollup merge of #96149 - est31:remove_unused_macro_matchers, r=petrochenkov
Remove unused macro rules

Removes rules of internal macros that weren't triggered.
2022-04-26 01:21:20 +02:00
bors
27af517549 Auto merge of #96082 - michaelwoerister:less_impl_stable_hash_via_hash, r=compiler-errors
incr. comp.: Don't export impl_stable_hash_via_hash!() and warn about using it.

Fixes https://github.com/rust-lang/rust/issues/96013.
2022-04-20 03:51:09 +00:00
Dylan DPC
5f10d1312d
Rollup merge of #96086 - jsgf:remove-extern-location, r=davidtwco
Remove `--extern-location` and all associated code

`--extern-location` was an experiment to investigate the best way to
generate useful diagnostics for unused dependency warnings by enabling a
build system to identify the corresponding build config.

While I did successfully use this, I've since been convinced the
alternative `--json unused-externs` mechanism is the way to go, and
there's no point in having two mechanisms with basically the same
functionality.

This effectively reverts https://github.com/rust-lang/rust/pull/72603
2022-04-19 14:43:17 +02:00
Michael Woerister
c0be619724 incr. comp.: Don't export impl_stable_hash_via_hash!() and warn about using it. 2022-04-19 10:43:20 +02:00
est31
3c1e1661e7 Remove unused macro rules 2022-04-18 23:28:06 +02:00
Camille GILLOT
a9e13fa553 Lint elided lifetimes in path on the AST. 2022-04-17 11:03:34 +02:00
Dylan DPC
91847c43cc
Rollup merge of #96023 - matthiaskrgr:clippyper1304, r=lcnr
couple of clippy::perf fixes
2022-04-16 14:25:56 +02:00
Dylan DPC
ba9c3a13ee
Rollup merge of #96026 - matthiaskrgr:clippy_compl_1304, r=Dylan-DPC
couple of clippy::complexity fixes
2022-04-15 20:50:47 +02:00
Jeremy Fitzhardinge
1be1157d75 Remove --extern-location and all associated code
`--extern-location` was an experiment to investigate the best way to
generate useful diagnostics for unused dependency warnings by enabling a
build system to identify the corresponding build config.

While I did successfully use this, I've since been convinced the
alternative `--json unused-externs` mechanism is the way to go, and
there's no point in having two mechanisms with basically the same
functionality.

This effectively reverts https://github.com/rust-lang/rust/pull/72603
2022-04-15 11:19:06 -07:00
Matthias Krüger
7c2d57e0fa couple of clippy::complexity fixes 2022-04-13 22:51:34 +02:00
Matthias Krüger
bbd7ce6904 couple of clippy::perf fixes 2022-04-13 22:18:28 +02:00
David Wood
9bfe0e39e4 errors: lazily load fallback fluent bundle
Loading the fallback bundle in compilation sessions that won't go on to
emit any errors unnecessarily degrades compile time performance, so
lazily create the Fluent bundle when it is first required.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-13 02:44:59 +01:00
David Wood
3c2f864ffb session: opt for enabling directionality markers
Add an option for enabling and disabling Fluent's directionality
isolation markers in output. Disabled by default as these can render in
some terminals and applications.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-05 07:01:03 +01:00
David Wood
a88717cef0 macros: support translatable labels
Extends support for generating `DiagnosticMessage::FluentIdentifier`
messages from `SessionDiagnostic` derive to `#[label]`.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-05 07:01:03 +01:00
David Wood
d0fd8d7880 macros: translatable struct attrs and warnings
Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-05 07:01:03 +01:00
David Wood
9956d4f99d macros: add args for non-subdiagnostic fields
Non-subdiagnostic fields (i.e. those that don't have `#[label]`
attributes or similar and are just additional context) have to be added
as arguments for Fluent messages to refer them. This commit extends the
`SessionDiagnostic` derive to do this for all fields that do not have
attributes and introduces an `IntoDiagnosticArg` trait that is
implemented on all types that can be converted to a argument for Fluent.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-05 07:01:02 +01:00
David Wood
d5119c5b9f errors: implement sysroot/testing bundle loading
Extend loading of Fluent bundles so that bundles can be loaded from the
sysroot based on the language requested by the user, or using a nightly
flag.

Sysroot bundles are loaded from `$sysroot/share/locale/$locale/*.ftl`.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-05 07:01:02 +01:00
David Wood
7f91697b50 errors: implement fallback diagnostic translation
This commit updates the signatures of all diagnostic functions to accept
types that can be converted into a `DiagnosticMessage`. This enables
existing diagnostic calls to continue to work as before and Fluent
identifiers to be provided. The `SessionDiagnostic` derive just
generates normal diagnostic calls, so these APIs had to be modified to
accept Fluent identifiers.

In addition, loading of the "fallback" Fluent bundle, which contains the
built-in English messages, has been implemented.

Each diagnostic now has "arguments" which correspond to variables in the
Fluent messages (necessary to render a Fluent message) but no API for
adding arguments has been added yet. Therefore, diagnostics (that do not
require interpolation) can be converted to use Fluent identifiers and
will be output as before.
2022-04-05 07:01:02 +01:00
David Wood
c45f29595d span: move MultiSpan
`MultiSpan` contains labels, which are more complicated with the
introduction of diagnostic translation and will use types from
`rustc_errors` - however, `rustc_errors` depends on `rustc_span` so
`rustc_span` cannot use types like `DiagnosticMessage` without
dependency cycles. Introduce a new `rustc_error_messages` crate that can
contain `DiagnosticMessage` and `MultiSpan`.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-05 07:01:00 +01:00
David Wood
8c684563a5 errors: introduce DiagnosticMessage
Introduce a `DiagnosticMessage` type that will enable diagnostic
messages to be simple strings or Fluent identifiers.
`DiagnosticMessage` is now used in the implementation of the standard
`DiagnosticBuilder` APIs.

Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-05 06:53:39 +01:00
Esteban Kuber
3aac307ca6 Mention implementers of unsatisfied trait
When encountering an unsatisfied trait bound, if there are no other
suggestions, mention all the types that *do* implement that trait:

```
error[E0277]: the trait bound `f32: Foo` is not satisfied
  --> $DIR/impl_wf.rs:22:6
   |
LL | impl Baz<f32> for f32 { }
   |      ^^^^^^^^ the trait `Foo` is not implemented for `f32`
   |
   = help: the following other types implement trait `Foo`:
             Option<T>
             i32
             str
note: required by a bound in `Baz`
  --> $DIR/impl_wf.rs:18:31
   |
LL | trait Baz<U: ?Sized> where U: Foo { }
   |                               ^^^ required by this bound in `Baz`
```

Mention implementers of traits in `ImplObligation`s.

Do not mention other `impl`s for closures, ranges and `?`.
2022-04-04 21:01:42 +00:00
Yuri Astrakhan
7e8201ae0a Spellchecking some comments
This PR attempts to clean up some minor spelling mistakes in comments
2022-03-30 01:39:38 -04:00
Michael Goulet
928388bad2 Make fatal DiagnosticBuilder yield never 2022-03-27 22:25:32 -07:00
Camille GILLOT
0b49d05ea3 Filter OnceNote in diagnostic infra. 2022-03-20 20:36:26 +01:00
Camille GILLOT
056951d628 Take &mut Diagnostic in emit_diagnostic.
Taking a Diagnostic by move would break the usual pattern
`diag.label(..).emit()`.
2022-03-20 20:36:08 +01:00
mark
bb8d4307eb rustc_error: make ErrorReported impossible to construct
There are a few places were we have to construct it, though, and a few
places that are more invasive to change. To do this, we create a
constructor with a long obvious name.
2022-03-16 10:35:24 -05:00
Matthias Krüger
6548a368c8
Rollup merge of #94670 - xFrednet:rfc-2383-expect-impl-after-party, r=flip1995,wesleywiser
Improve `expect` impl and handle `#[expect(unfulfilled_lint_expectations)]` (RFC 2383)

This PR updates unstable `ExpectationIds` in stashed diagnostics and adds some asserts to ensure that the stored expectations are really empty in the end. Additionally, it handles the `#[expect(unfulfilled_lint_expectations)]` case.

According to the [Errors and lints docs](https://rustc-dev-guide.rust-lang.org/diagnostics.html#diagnostic-levels) the `error` level should only be used _"when the compiler detects a problem that makes it unable to compile the program"_. As this isn't the case with `#[expect(unfulfilled_lint_expectations)]` I decided to only create a warning. To avoid adding a new lint only for this case, I simply emit a `unfulfilled_lint_expectations` diagnostic with an additional note.

---

r? `@wesleywiser` I'm requesting a review from you since you reviewed the previous PR https://github.com/rust-lang/rust/pull/87835. You are welcome to reassign it if you're busy 🙃

rfc: [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html)

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

cc: `@flip1995` In case you're also interested in this :)
2022-03-14 17:24:58 +01:00
T-O-R-U-S
72a25d05bf Use implicit capture syntax in format_args
This updates the standard library's documentation to use the new syntax. The
documentation is worthwhile to update as it should be more idiomatic
(particularly for features like this, which are nice for users to get acquainted
with). The general codebase is likely more hassle than benefit to update: it'll
hurt git blame, and generally updates can be done by folks updating the code if
(and when) that makes things more readable with the new format.

A few places in the compiler and library code are updated (mostly just due to
already having been done when this commit was first authored).
2022-03-10 10:23:40 -05:00
Esteban Kuber
ac2afa0334 Account for suggestions for complete removal of lines
Fix  #94192.
2022-03-09 23:51:10 +00:00
xFrednet
d39d60971b
Handle #[expect(unfulfilled_lint_expectations)] with a lint message 2022-03-07 19:59:10 +01:00
Michael Howell
fbd4cfa0f8 diagnostics: only talk about Cargo.toml if running under Cargo
Fixes #94646
2022-03-07 10:54:17 -07:00
xFrednet
47f3f66240
Update unstable ExpectationIds in stored diagnostics 2022-03-07 18:08:30 +01:00
bors
10913c0001 Auto merge of #87835 - xFrednet:rfc-2383-expect-attribute-with-ids, r=wesleywiser
Implementation of the `expect` attribute (RFC 2383)

This is an implementation of the `expect` attribute as described in [RFC-2383](https://rust-lang.github.io/rfcs/2383-lint-reasons.html). The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the `unfulfilled_lint_expectations` lint at the `expect` attribute.

### Example
#### input
```rs
// required feature flag
#![feature(lint_reasons)]

#[expect(unused_mut)] // Will warn about an unfulfilled expectation
#[expect(unused_variables)] // Will be fulfilled by x
fn main() {
    let x = 0;
}
```

#### output

```txt
warning: this lint expectation is unfulfilled
  --> $DIR/trigger_lint.rs:3:1
   |
LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation
   |          ^^^^^^^^^^
   |
   = note: `#[warn(unfulfilled_lint_expectations)]` on by default
```

### Implementation

This implementation introduces `Expect` as a new lint level for diagnostics, which have been expected. All lint expectations marked via the `expect` attribute are collected in the [`LintLevelsBuilder`] and assigned an ID that is stored in the new lint level. The `LintLevelsBuilder` stores all found expectations and the data needed to emit the `unfulfilled_lint_expectations` in the [`LintLevelsMap`] which is the result of the [`lint_levels()`] query.

The [`rustc_errors::HandlerInner`] is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level `Expect` are suppressed during this emission, while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the [`LintLevelsBuilder`] in the [`LintLevelsMap`] have been marked as fulfilled in the [`rustc_errors::HandlerInner`]. Otherwise, a new lint message will be emitted.

The implementation of the `LintExpectationId` required some special handling to make it stable between sessions. Lints can be emitted during [`EarlyLintPass`]es. At this stage, it's not possible to create a stable identifier. The level instead stores an unstable identifier, which is later converted to a stable `LintExpectationId`.

### Followup TO-DOs
All open TO-DOs have been marked with `FIXME` comments in the code. This is the combined list of them:

* [ ] The current implementation doesn't cover cases where the `unfulfilled_lint_expectations` lint is actually expected by another `expect` attribute.
   * This should be easily possible, but I wanted to get some feedback before putting more work into this.
   * This could also be done in a new PR to not add to much more code to this one
* [ ] Update unstable documentation to reflect this change.
* [ ] Update unstable expectation ids in [`HandlerInner::stashed_diagnostics`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html#structfield.stashed_diagnostics)

### Open questions
I also have a few open questions where I would like to get feedback on:
1. The RFC discussion included a suggestion to change the `expect` attribute to something else. (Initiated by `@Ixrec` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378424091), suggestion from `@scottmcm` to use `#[should_lint(...)]` [here](https://github.com/rust-lang/rfcs/pull/2383#issuecomment-378648877)). No real conclusion was drawn on that point from my understanding. Is this still open for discussion, or was this discarded with the merge of the RFC?
2. How should the expect attribute deal with the new `force-warn` lint level?

---

This approach was inspired by a discussion with `@LeSeulArtichaut.`

RFC tracking issue: #54503

Mentoring/Implementation issue: #85549

[`LintLevelsBuilder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/levels/struct.LintLevelsBuilder.html
[`LintLevelsMap`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/lint/struct.LintLevelMap.html
[`lint_levels()`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TyCtxt.html#method.lint_levels
[`rustc_errors::HandlerInner`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_errors/struct.HandlerInner.html
[`EarlyLintPass`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint/trait.EarlyLintPass.html
2022-03-03 18:59:32 +00:00
xFrednet
defc056ccc
Address review comments 2022-03-02 17:46:12 +01:00
xFrednet
4887eb7b2d
Added panics for unreachable states for expectations (RFC 2383) 2022-03-02 17:46:11 +01:00
xFrednet
aa2a0a83d9
Expect each lint in attribute individually (RFC-2383) 2022-03-02 17:46:09 +01:00
xFrednet
33a5945069
Make LintExpectationId stable between compilation sessions (RFC-2383) 2022-03-02 17:46:08 +01:00
xFrednet
2ca9037b61
Set LintExpectationId in level and collect fulfilled ones (RFC-2383)
* Collect lint expectations and set expectation ID in level (RFC-2383)
* Collect IDs of fulfilled lint expectations from diagnostics (RFC 2383)
2022-03-02 17:46:07 +01:00
xFrednet
9fef3d9e0a
Added Expect lint level and attribute (RFC-2383)
* Also added the `LintExpectationId` which will be used in future commits
2022-03-02 17:46:05 +01:00
mark
e489a94dee rename ErrorReported -> ErrorGuaranteed 2022-03-02 09:45:25 -06:00
bors
48132caac2 Auto merge of #94427 - cjgillot:inline-fresh-expn, r=oli-obk
Only create a single expansion for each inline integration.

The inlining integrator used to create one expansion for each span from the callee body.
This PR reverses the logic to create a single expansion for the whole call,
which is more consistent with how macro expansions work for macros.

This should remove the large memory regression in #91743.
2022-02-28 08:25:26 +00:00
Camille GILLOT
e77e4fcf89 Only create a single expansion for each inline integration. 2022-02-27 19:05:56 +01:00
Mark Rousskov
22c3a71de1 Switch bootstrap cfgs 2022-02-25 08:00:52 -05:00
bors
d4de1f230c Auto merge of #93368 - eddyb:diagbld-guarantee, r=estebank
rustc_errors: let `DiagnosticBuilder::emit` return a "guarantee of emission".

That is, `DiagnosticBuilder` is now generic over the return type of `.emit()`, so we'll now have:
* `DiagnosticBuilder<ErrorReported>` for error (incl. fatal/bug) diagnostics
  * can only be created via a `const L: Level`-generic constructor, that limits allowed variants via a `where` clause, so not even `rustc_errors` can accidentally bypass this limitation
  * asserts `diagnostic.is_error()` on emission, just in case the construction restriction was bypassed (e.g. by replacing the whole `Diagnostic` inside `DiagnosticBuilder`)
  * `.emit()` returns `ErrorReported`, as a "proof" token that `.emit()` was called
    (though note that this isn't a real guarantee until after completing the work on
     #69426)
* `DiagnosticBuilder<()>` for everything else (warnings, notes, etc.)
  * can also be obtained from other `DiagnosticBuilder`s by calling `.forget_guarantee()`

This PR is a companion to other ongoing work, namely:
* #69426
  and it's ongoing implementation:
  #93222
  the API changes in this PR are needed to get statically-checked "only errors produce `ErrorReported` from `.emit()`", but doesn't itself provide any really strong guarantees without those other `ErrorReported` changes
* #93244
  would make the choices of API changes (esp. naming) in this PR fit better overall

In order to be able to let `.emit()` return anything trustable, several changes had to be made:
* `Diagnostic`'s `level` field is now private to `rustc_errors`, to disallow arbitrary "downgrade"s from "some kind of error" to "warning" (or anything else that doesn't cause compilation to fail)
  * it's still possible to replace the whole `Diagnostic` inside the `DiagnosticBuilder`, sadly, that's harder to fix, but it's unlikely enough that we can paper over it with asserts on `.emit()`
* `.cancel()` now consumes `DiagnosticBuilder`, preventing `.emit()` calls on a cancelled diagnostic
  * it's also now done internally, through `DiagnosticBuilder`-private state, instead of having a `Level::Cancelled` variant that can be read (or worse, written) by the user
  * this removes a hazard of calling `.cancel()` on an error then continuing to attach details to it, and even expect to be able to `.emit()` it
  * warnings were switched to *only* `can_emit_warnings` on emission (instead of pre-cancelling early)
  * `struct_dummy` was removed (as it relied on a pre-`Cancelled` `Diagnostic`)
* since `.emit()` doesn't consume the `DiagnosticBuilder` <sub>(I tried and gave up, it's much more work than this PR)</sub>,
  we have to make `.emit()` idempotent wrt the guarantees it returns
  * thankfully, `err.emit(); err.emit();` can return `ErrorReported` both times, as the second `.emit()` call has no side-effects *only* because the first one did do the appropriate emission
* `&mut Diagnostic` is now used in a lot of function signatures, which used to take `&mut DiagnosticBuilder` (in the interest of not having to make those functions generic)
  * the APIs were already mostly identical, allowing for low-effort porting to this new setup
  * only some of the suggestion methods needed some rework, to have the extra `DiagnosticBuilder` functionality on the `Diagnostic` methods themselves (that change is also present in #93259)
  * `.emit()`/`.cancel()` aren't available, but IMO calling them from an "error decorator/annotator" function isn't a good practice, and can lead to strange behavior (from the caller's perspective)
  * `.downgrade_to_delayed_bug()` was added, letting you convert any `.is_error()` diagnostic into a `delay_span_bug` one (which works because in both cases the guarantees available are the same)

This PR should ideally be reviewed commit-by-commit, since there is a lot of fallout in each.

r? `@estebank` cc `@Manishearth` `@nikomatsakis` `@mark-i-m`
2022-02-25 00:46:04 +00:00
Mark Rousskov
34319ff4e1 Avoid emitting full macro body into JSON 2022-02-24 11:16:45 -05:00
Eduard-Mihai Burtescu
b7e95dee65 rustc_errors: let DiagnosticBuilder::emit return a "guarantee of emission". 2022-02-23 06:38:52 +00:00
Eduard-Mihai Burtescu
0b9d70cf6d rustc_errors: take self by value in DiagnosticBuilder::cancel. 2022-02-23 06:08:06 +00:00
Eduard-Mihai Burtescu
8562d6b752 rustc_errors: remove struct_dummy. 2022-02-23 05:38:24 +00:00
Eduard-Mihai Burtescu
d4fc5ae25c rustc_errors: handle force_warn only through DiagnosticId::Lint. 2022-02-23 05:38:24 +00:00
Eduard-Mihai Burtescu
02ff9e0aef Replace &mut DiagnosticBuilder, in signatures, with &mut Diagnostic. 2022-02-23 05:38:19 +00:00
Eduard-Mihai Burtescu
f24ff1815f rustc_errors: add downgrade_to_delayed_bug to Diagnostic itself. 2022-02-23 03:46:51 +00:00
Mark Rousskov
60b71f56e7 Remove support for JSON deserialization to Rust
This is no longer used by the compiler itself, and removing this support opens
the door to massively simplifying the Decodable/Decoder API by dropping the
self-describing deserialization support (necessary for JSON).
2022-02-20 18:58:21 -05:00
est31
2ef8af6619 Adopt let else in more places 2022-02-19 17:27:43 +01:00
lcnr
a1a30f7548 add a rustc::query_stability lint 2022-02-01 10:15:59 +01:00
Eduard-Mihai Burtescu
f5a32711dc rustc_errors: add a new assert for the size of PResult<()>. 2022-01-24 15:14:40 +00:00
Eduard-Mihai Burtescu
a8dfa3757c rustc_errors: only box the diagnostic field in DiagnosticBuilder. 2022-01-24 11:23:14 +00:00
Eduard-Mihai Burtescu
68fa81baa3 rustc_errors: remove allow_suggestions from DiagnosticBuilder. 2022-01-24 10:49:10 +00:00
Matthias Krüger
a1645e5b57
Rollup merge of #93229 - mark-i-m:noquiet, r=eddyb
Remove DiagnosticBuilder.quiet

r? `@eddyb`

cc https://github.com/rust-lang/rust/issues/69426 `@GuillaumeGomez` `@Manishearth`
2022-01-23 20:13:07 +01:00
mark
cf382de0cc Remove DiagnosticBuilder.quiet 2022-01-23 00:11:13 -06:00
Nicholas Nethercote
416399dc10 Make Decodable and Decoder infallible.
`Decoder` has two impls:
- opaque: this impl is already partly infallible, i.e. in some places it
  currently panics on failure (e.g. if the input is too short, or on a
  bad `Result` discriminant), and in some places it returns an error
  (e.g. on a bad `Option` discriminant). The number of places where
  either happens is surprisingly small, just because the binary
  representation has very little redundancy and a lot of input reading
  can occur even on malformed data.
- json: this impl is fully fallible, but it's only used (a) for the
  `.rlink` file production, and there's a `FIXME` comment suggesting it
  should change to a binary format, and (b) in a few tests in
  non-fundamental ways. Indeed #85993 is open to remove it entirely.

And the top-level places in the compiler that call into decoding just
abort on error anyway. So the fallibility is providing little value, and
getting rid of it leads to some non-trivial performance improvements.

Much of this commit is pretty boring and mechanical. Some notes about
a few interesting parts:
- The commit removes `Decoder::{Error,error}`.
- `InternIteratorElement::intern_with`: the impl for `T` now has the same
  optimization for small counts that the impl for `Result<T, E>` has,
  because it's now much hotter.
- Decodable impls for SmallVec, LinkedList, VecDeque now all use
  `collect`, which is nice; the one for `Vec` uses unsafe code, because
  that gave better perf on some benchmarks.
2022-01-22 10:38:31 +11:00
bors
2e2c86eba2 Auto merge of #92070 - rukai:replace_vec_into_iter_with_array_into_iter, r=Mark-Simulacrum
Replace usages of vec![].into_iter with [].into_iter

`[].into_iter` is idiomatic over `vec![].into_iter` because its simpler and faster (unless the vec is optimized away in which case it would be the same)

So we should change all the implementation, documentation and tests to use it.

I skipped:
* `src/tools` - Those are copied in from upstream
* `src/test/ui` - Hard to tell if `vec![].into_iter` was used intentionally or not here and not much benefit to changing it.
*  any case where `vec![].into_iter` was used because we specifically needed a `Vec::IntoIter<T>`
*  any case where it looked like we were intentionally using `vec![].into_iter` to test it.
2022-01-11 14:23:24 +00:00
Lamb
3a77bb86ff Compute most of Public/Exported access level in rustc_resolve
Mak DefId to AccessLevel map in resolve for export

hir_id to accesslevel in resolve and applied in privacy
using local def id
removing tracing probes
making function not recursive and adding comments

Move most of Exported/Public res to rustc_resolve

moving public/export res to resolve

fix missing stability attributes in core, std and alloc

move code to access_levels.rs

return for some kinds instead of going through them

Export correctness, macro changes, comments

add comment for import binding

add comment for import binding

renmae to access level visitor, remove comments, move fn as closure, remove new_key

fmt

fix rebase

fix rebase

fmt

fmt

fix: move macro def to rustc_resolve

fix: reachable AccessLevel for enum variants

fmt

fix: missing stability attributes for other architectures

allow unreachable pub in rustfmt

fix: missing impl access level + renaming export to reexport

Missing impl access level was found thanks to a test in clippy
2022-01-09 21:33:14 +00:00
Lucas Kent
08829853d3 eplace usages of vec![].into_iter with [].into_iter 2022-01-09 14:09:25 +11:00
PFPoitras
304ede6bcc Stabilize iter::zip. 2021-12-14 18:50:31 -04:00
Matthias Krüger
d96ce3ea8e
Rollup merge of #91394 - Mark-Simulacrum:bump-stage0, r=pietroalbini
Bump stage0 compiler

r? `@pietroalbini` (or anyone else)
2021-12-02 15:52:03 +01:00
Joshua Nelson
9de8a4a6fa Include lint errors in error count for -Ztreat-err-as-bug
This was a regression from https://github.com/rust-lang/rust/pull/87337;
the `panic_if_treat_err_as_bug` function only checked the number of hard
errors, not the number of lint errors.
2021-12-01 16:39:55 +00:00
Mark Rousskov
b221c877e8 Apply cfg-bootstrap switch 2021-11-30 10:51:42 -05:00
Yuki Okushi
56c838cdc7
Rollup merge of #91358 - kd-collective:fix_typo, r=cjgillot
Fix small typo

Fix a typo in code commenting!
`accross` -> `across`
2021-11-30 17:29:10 +09:00
kijima
3c42a11895 Fix small typo 2021-11-30 01:31:10 +09:00
Lucas Kent
df3e7a28f7 Refactor EmitterWriter::emit_suggestion_default 2021-11-27 01:13:37 +11:00
Esteban Kuber
143f784199 replace_tabs -> normalize_whitespace 2021-11-23 20:37:21 +00:00
Esteban Kuber
a96fe02f6c Replace ZWJ with nothing in terminal output 2021-11-23 20:36:14 +00:00
Esteban Kuber
8f433adf75 Align multiline messages to their label (add left margin) 2021-11-20 19:19:33 +00:00
Josh Triplett
8c9bfaa5f3 Stabilize format_args_capture
Works as expected, and there are widespread reports of success with it,
as well as interest in it.
2021-11-15 10:14:29 +01:00
Joshua Nelson
0ac13bd430 Don't abort compilation after giving a lint error
The only reason to use `abort_if_errors` is when the program is so broken that either:
1. later passes get confused and ICE
2. any diagnostics from later passes would be noise

This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints.
So it can continue to lint and compile even if there are lint errors.
2021-11-08 01:22:28 +00:00
Esteban Küber
c0b134582a
Lint against RTL unicode codepoints in literals and comments
Address CVE-2021-42574.
2021-10-31 13:14:04 +01:00
Mark Rousskov
3215eeb99f
Revert "Add rustc lint, warning when iterating over hashmaps" 2021-10-28 11:01:42 -04:00
bors
41d8c94d45 Auto merge of #89427 - estebank:collect-overlapping-impls, r=jackh726
Point at overlapping impls when type annotations are needed

Address https://github.com/rust-lang/rust/issues/89254.
2021-10-24 22:26:41 +00:00
Esteban Kuber
881a50c0b7 Always sort suggestions before emitting them 2021-10-24 20:28:44 +00:00
Matthias Krüger
87822b27ee
Rollup merge of #89558 - lcnr:query-stable-lint, r=estebank
Add rustc lint, warning when iterating over hashmaps

r? rust-lang/wg-incr-comp
2021-10-24 15:48:42 +02:00
Matthias Krüger
0f81c7faf5
Rollup merge of #89468 - FabianWolff:issue-89358, r=jackh726
Report fatal lexer errors in `--cfg` command line arguments

Fixes #89358. The erroneous behavior was apparently introduced by `@Mark-Simulacrum` in a678e31911; the idea is to silence individual parser errors and instead emit one catch-all error message after parsing. However, for the example in #89358, a fatal lexer error is created here:
edebf77e00/compiler/rustc_parse/src/lexer/mod.rs (L340-L349)

This fatal error aborts the compilation, and so the call to `new_parser_from_source_str()` never returns and the catch-all error message is never emitted. I have therefore changed the `SilentEmitter` to silence only non-fatal errors; with my changes, for the rustc invocation described in #89358:
```sh
rustc --cfg "abc\""
```
I get the following output:
```
error[E0765]: unterminated double quote string
  |
  = note: this error occurred on the command line: `--cfg=abc"`
```
2021-10-23 05:28:22 +02:00
bors
1af55d19c7 Auto merge of #89933 - est31:let_else, r=michaelwoerister
Adopt let_else across the compiler

This performs a substitution of code following the pattern:

```
let <id> = if let <pat> = ... { identity } else { ... : ! };
```

To simplify it to:

```
let <pat> = ... { identity } else { ... : ! };
```

By adopting the `let_else` feature (cc #87335).

The PR also updates the syn crate because the currently used version of the crate doesn't support `let_else` syntax yet.

Note: Generally I'm the person who *removes* usages of unstable features from the compiler, not adds more usages of them, but in this instance I think it hopefully helps the feature get stabilized sooner and in a better state. I have written a [comment](https://github.com/rust-lang/rust/issues/87335#issuecomment-944846205) on the tracking issue about my experience and what I feel could be improved before stabilization of `let_else`.
2021-10-19 14:41:39 +00:00
est31
1418df5888 Adopt let_else across the compiler
This performs a substitution of code following the pattern:

let <id> = if let <pat> = ... { identity } else { ... : ! };

To simplify it to:

let <pat> = ... { identity } else { ... : ! };

By adopting the let_else feature.
2021-10-16 07:18:05 +02:00
David Wood
d2dc0f3b0f emitter: current substitution can be multi-line
In `splice_lines`, there is some arithmetic to compute the required
alignment such that future substitutions in a suggestion are aligned
correctly. However, this assumed that the current substitution's span
was only on a single line. In circumstances where this was not true, it
could result in a arithmetic overflow when the substitution's end
column was less than the substitution's start column.

Signed-off-by: David Wood <david.wood@huawei.com>
2021-10-15 15:30:43 +00:00
lcnr
00e5abe9b6 allow potential_query_instability everywhere 2021-10-15 10:58:18 +02:00
Eliza Weisman
e00eac8b9c
use structured fields in some existing warnings
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
2021-10-07 10:48:48 -07:00
Fabian Wolff
041212f8fb Report fatal lexer errors in --cfg command line arguments 2021-10-02 19:15:55 +02:00
the8472
5948a7b407
Rollup merge of #89046 - oli-obk:fix_oflo, r=estebank
"Fix" an overflow in byte position math

r? `@estebank`

help! I fixed the ICE only to brick the diagnostic.

I mean, it was wrong previously (using an already expanded macro span), but it is really bad now XD
2021-09-22 19:03:22 +02:00
Mark Rousskov
c746be2219 Migrate to 2021 2021-09-20 22:21:42 -04:00
Oli Scherer
4281380717 Add some more tracing 2021-09-20 15:24:47 +00:00
Mark Rousskov
440d9372a2 Workaround ICE with if-let and RFC 2229 2021-09-20 08:45:39 -04:00
Yuki Okushi
378300a63d
Make diagnostics clearer for ? operators 2021-09-17 13:13:28 +09:00
bors
9bb77da74d Auto merge of #87915 - estebank:fancy-spans, r=oli-obk
Use smaller spans for some structured suggestions

Use more accurate suggestion spans for

* argument parse error
* fully qualified path
* missing code block type
* numeric casts
2021-09-13 16:31:12 +00:00
Mark Rousskov
b4e7649d6d Bump stage0 compiler to 1.56 2021-09-08 20:51:05 -04:00
bors
8f3aa5e8b9 Auto merge of #88493 - chenyukang:fix-duplicated-diagnostic, r=estebank
Fix #88256 remove duplicated diagnostics

Fix #88256
2021-09-06 00:14:41 +00:00
yukang
ca27f03ca8 Fix #88256, remove duplicated diagnostic 2021-09-04 19:26:25 +08:00
Michael Woerister
af1b65cb18 Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. 2021-08-27 11:50:44 +02:00
Léo Lanteri Thauvin
fde1b76b4b Use if-let guards in the codebase 2021-08-25 20:24:35 +02:00
Esteban Kuber
955e913612 review comments 2021-08-23 14:31:48 +00:00
Esteban Kuber
31d07edc94 remove unnecessary info!() logging 2021-08-23 11:58:19 +00:00
Esteban Kuber
5626346ac9 Fixes to span locations 2021-08-23 11:58:19 +00:00
Esteban Kuber
a29a624f86 wip 2021-08-23 11:58:19 +00:00
Esteban Kuber
75fd1bf1e6 Account for tabs when highlighting multiline code suggestions 2021-08-23 11:58:18 +00:00
Esteban Kuber
34d19634f5 Use smaller spans for some structured suggestions
Use more accurate suggestion spans for

* argument parse error
* fully qualified path
* missing code block type
* numeric casts
* E0212
2021-08-12 09:52:38 +00:00
Esteban Küber
99f2977031 Modify structured suggestion output
* On suggestions that include deletions, use a diff inspired output format
* When suggesting addition, use `+` as underline
* Color highlight modified span
2021-08-11 09:46:24 +00:00
Guillaume Gomez
5cf300d695 Remove warnings/errors from compiler when using typeck_body in rustdoc span map builder 2021-08-05 23:08:29 +02:00
Fabian Wolff
f8372f876c Remove trailing whitespace from error messages 2021-08-04 10:48:30 +02:00