summary refs log tree commit diff
path: root/src/librustc_errors
AgeCommit message (Collapse)AuthorLines
2020-03-05stash API: remove panic to fix ICE.Mazdak Farrokhzad-14/+4
2020-03-05Fix a leak in `DiagnosticBuilder::into_diagnostic`.Nicholas Nethercote-6/+5
Fixes #69600.
2020-02-21Correct ICE caused by macros generating invalid spans.Michael Burge-1/+8
2020-01-27don't clone types that are copy, round two.Matthias Krüger-6/+6
2020-01-26rustc_span: return an impl Iterator instead of a Vec from macro_backtrace.Eduard-Mihai Burtescu-6/+6
2020-01-26rustc_span: replace MacroBacktrace with ExpnData.Eduard-Mihai Burtescu-10/+11
2020-01-26Auto merge of #68522 - estebank:impl-trait-sugg-2, r=oli-obkbors-3/+8
Further improve `impl Trait`/`dyn Trait` suggestions After reading [_Returning Trait Objects_ by Bryce Fisher-Fleig](https://bryce.fisher-fleig.org/blog/returning-trait-objects/), [I noticed that](https://www.reddit.com/r/rust/comments/esueur/returning_trait_objects/ffczl4k/) #68195 had a few bugs due to not ignoring `ty::Error`. - Account for `ty::Error`. - Account for `if`/`else` and `match` blocks when pointing at return types and referencing their types. - Increase the multiline suggestion output from 6 lines to 20.
2020-01-25Revert suggestion window size changeEsteban Küber-1/+1
2020-01-24Do not ICE on multipart suggestions touching multiple filesEsteban Küber-5/+6
When encountering a multipart suggestion with spans belonging to different contexts, skip that suggestion.
2020-01-24review commentsEsteban Küber-1/+1
2020-01-24Increase suggestion code window from 6 lines to 20Esteban Küber-3/+8
2020-01-18remove rustc_error_codes deps except in rustc_driverMazdak Farrokhzad-4/+1
2020-01-17Rollup merge of #68256 - estebank:bad-sugg-span, r=petrochenkovTyler Mandry-4/+22
Do not ICE on malformed suggestion spans Under the assumption that suggestions are by their very nature always "best effort", it is ok if we don't display them instead of having an ICE. The underlying issue of the malformed span being _created_ is left unaddressed. Fix #67567. r? @petrochenkov
2020-01-16review commentsEsteban Küber-16/+14
2020-01-16Do not ICE on malformed suggestion spansEsteban Küber-1/+21
2020-01-16don't clone types that are copyMatthias Krüger-1/+1
found via clippy
2020-01-11use winapi for non-stdlib Windows bindingsAndy Russell-22/+8
2020-01-10Fix invalid bounding boxEsteban Küber-1/+1
2020-01-08Remove `-Z continue-parse-after-error`Vadim Petrochenkov-20/+0
2020-01-08- remove syntax::{span_warn!, span_err!, span_fatal!. struct_err!}Mazdak Farrokhzad-0/+19
- remove syntax::{help!, span_help!, span_note!} - remove unused syntax::{struct_span_fatal, struct_span_err_or_warn!, span_err_or_warn!} - lintify check_for_bindings_named_same_as_variants + conflicting_repr_hints - inline syntax::{struct_span_warn!, diagnostic_used!} - stringify_error_code! -> error_code! & use it more. - find_plugin_registrar: de-fatalize an error - de-fatalize metadata errors - move type_error_struct! to rustc_typeck - struct_span_err! -> rustc_errors
2020-01-05Handle multiple error fix suggestions carefulyLaurent Bonnans-5/+13
The existing code seems to assume that substitutions spans are disjoint, which is not always the case. In the example: pub trait AAAA {} pub trait B {} pub trait C {} pub type T<P: AAAA + B + C> = P; , we get three substituions starting from ':' and ending respectively at the end of each trait token. With the former offset calculation, this would cause `underline_start` to eventually become negative before being converted to `usize`... The new version may report erroneous results for non perfectly overlapping substitutions but I don't know if such examples exist. Alternatively, we could detect these cases and trim out overlapping substitutions.
2020-01-03Address review comments + Fix rebaseVadim Petrochenkov-1/+2
2020-01-03Introduce an option for disabling deduplication of diagnosticsVadim Petrochenkov-5/+7
2020-01-01Rename `syntax_pos` to `rustc_span` in source codeVadim Petrochenkov-18/+18
2019-12-30Make things build againVadim Petrochenkov-1/+1
2019-12-29Auto merge of #67614 - Mark-Simulacrum:global-callbacks, r=Zoxcbors-6/+4
Set callbacks globally This sets the callbacks from syntax and rustc_errors just once, utilizing static (rather than thread-local) storage.
2019-12-25Store callbacks in global staticsMark Rousskov-6/+4
The callbacks have precisely two states: the default, and the one present throughout almost all of the rustc run (the filled in value which has access to TyCtxt). We used to store this as a thread local, and reset it on each thread to the non-default value. But this is somewhat wasteful, since there is no reason to set it globally -- while the callbacks themselves access TLS, they do not do so in a manner that fails in when we do not have TLS to work with.
2019-12-24Deprecate Error::description for realDavid Tolnay-5/+1
`description` has been documented as soft-deprecated since 1.27.0 (17 months ago). There is no longer any reason to call it or implement it. This commit: - adds #[rustc_deprecated(since = "1.41.0")] to Error::description; - moves description (and cause, which is also deprecated) below the source and backtrace methods in the Error trait; - reduces documentation of description and cause to take up much less vertical real estate in rustdocs, while preserving the example that shows how to render errors without needing to call description; - removes the description function of all *currently unstable* Error impls in the standard library; - marks #[allow(deprecated)] the description function of all *stable* Error impls in the standard library; - replaces miscellaneous uses of description in example code and the compiler.
2019-12-24x.py fmt after previous deignoreMark Rousskov-291/+310
2019-12-22Format the worldMark Rousskov-489/+413
2019-12-08async/await: more improvements to non-send errorsDavid Wood-0/+10
Signed-off-by: David Wood <david@davidtw.co>
2019-11-27Draw vertical lines in compiler error messages with multiline annotations ↵Christoph Schmidler-3/+3
correctly when non-1space unicode characters are to the left For this we use the correct calculation of the 'left' identation
2019-11-26Move ErrorReported to rustc_errorsMark Rousskov-0/+7
2019-11-23review comments: remove unnecessary `&str` to `String` conversionsEsteban Küber-2/+2
2019-11-23Highlight parts of fn in type errorsEsteban Küber-0/+7
When a type error arises between two fn items, fn pointers or tuples, highlight only the differing parts of each.
2019-11-21Auto merge of #66610 - alexreg:trait-upcasting-cosmetic, r=Centrilbors-1/+1
Aggregation of drive-by cosmetic changes for trait-upcasting PR Cherry-picked from #60900. As requested by @Centril (and @nikomatsakis, I believe). r? @Centril
2019-11-21Aggregation of drive-by cosmetic changes.Alexander Regueiro-1/+1
2019-11-21Auto merge of #66389 - estebank:type-err-labels, r=petrochenkovbors-58/+77
Specific labels when referring to "expected" and "found" types
2019-11-18Auto merge of #58281 - mark-i-m:synthesis, r=estebankbors-1/+20
Add outlives suggestions for some lifetime errors This PR implements suggestion diagnostics for some lifetime mismatch errors. When the borrow checker finds that some lifetime 'a doesn't outlive some other lifetime 'b that it should outlive, then in addition to the current lifetime error, we also emit a suggestion for how to fix the problem by adding a bound: - If a and b are normal named regions, suggest to add the bound `'a: 'b` - If b is static, suggest to replace a with static - If b also needs to outlive a, they must be the same, so suggest unifying them We start with a simpler implementation that avoids diagnostic regression or implementation complexity: - We only makes suggestions for lifetimes the user can already name (eg not closure regions or elided regions) - For now, we only emit a help note, not an actually suggestion because it is significantly easier. Finally, there is one hack: it seems that implicit regions in async fn are given the name '_ incorrectly. To avoid suggesting '_: 'x, we simply filter out such lifetimes by name. For more info, see this internals thread: https://internals.rust-lang.org/t/mechanical-suggestions-for-some-borrow-checker-errors/9049/3 TL;DR Make suggestions to add a `where 'a: 'b` constraint for some lifetime errors. Details are in the paper linked from the internals thread above. r? @estebank TODO - [x] Clean up code - [x] Only make idiomatic suggestions - [x] don't suggest naming `&'a self` - [x] rather than `'a: 'static`, suggest replacing `'a` with `'static` - [x] rather than `'a: 'b, 'b: 'a`, suggest replacing `'a` with `'b` or vice versa - [x] Performance (maybe need a perf run when this is closer to the finish line?) - perf run was clean... - EDIT: perf run seems to only check non-error performance... How do we check that error performance didn't regress? - [x] Needs ui tests - [x] Integrate the `help` message into the main lifetime `error`
2019-11-18Specific labels when referring to "expected" and "found" typesEsteban Küber-58/+77
2019-11-16review comments and fix rebaseEsteban Küber-0/+1
2019-11-15Move JSON emitter to rustc_errorsMark Rousskov-0/+640
2019-11-15Remove SourceMapper traitMark Rousskov-45/+24
SourceMap is now in the root of all rustc-specific crates, syntax_pos, so there's no need for the trait object to decouple the dependencies between librustc_errors and libsyntax as was needed previously.
2019-11-15Move FatalError to syntax_posMark Rousskov-30/+1
This is a bit unfortunate, but code needs to be able to fatally error early on (in particular, syntax_pos after we move SourceMap there). It's also a tiny bit of code, which means it's ultimately not that bad.
2019-11-11Tiny cleanup to size assertionsVadim Petrochenkov-3/+1
2019-11-07move PResult to librustc_errorsMazdak Farrokhzad-1/+9
2019-11-06Rollup merge of #66139 - euclio:pluralize, r=nagisaMazdak Farrokhzad-3/+3
use American spelling for `pluralize!`
2019-11-05use American spelling for `pluralize!`Andy Russell-3/+3
2019-11-03use silent emitter for rustdoc highlighting passAndy Russell-0/+8
2019-11-03Auto merge of #65827 - AnthonyMikh:out_of_the_loop, r=estebankbors-4/+3
Remove a loop which runs exactly once Though the code seems to work properly, it is worth removing the loop entirely in order to not confuse the reader. r? @estebank