summary refs log tree commit diff
path: root/compiler/rustc_query_system
AgeCommit message (Collapse)AuthorLines
2024-01-29Stop using `String` for error codes.Nicholas Nethercote-1/+2
Error codes are integers, but `String` is used everywhere to represent them. Gross! This commit introduces `ErrCode`, an integral newtype for error codes, replacing `String`. It also introduces a constant for every error code, e.g. `E0123`, and removes the `error_code!` macro. The constants are imported wherever used with `use rustc_errors::codes::*`. With the old code, we have three different ways to specify an error code at a use point: ``` error_code!(E0123) // macro call struct_span_code_err!(dcx, span, E0123, "msg"); // bare ident arg to macro call \#[diag(name, code = "E0123")] // string struct Diag; ``` With the new code, they all use the `E0123` constant. ``` E0123 // constant struct_span_code_err!(dcx, span, E0123, "msg"); // constant \#[diag(name, code = E0123)] // constant struct Diag; ``` The commit also changes the structure of the error code definitions: - `rustc_error_codes` now just defines a higher-order macro listing the used error codes and nothing else. - Because that's now the only thing in the `rustc_error_codes` crate, I moved it into the `lib.rs` file and removed the `error_codes.rs` file. - `rustc_errors` uses that macro to define everything, e.g. the error code constants and the `DIAGNOSTIC_TABLES`. This is in its new `codes.rs` file.
2024-01-22Tweak error counting.Nicholas Nethercote-1/+1
We have several methods indicating the presence of errors, lint errors, and delayed bugs. I find it frustrating that it's very unclear which one you should use in any particular spot. This commit attempts to instill a basic principle of "use the least general one possible", because that reflects reality in practice -- `has_errors` is the least general one and has by far the most uses (esp. via `abort_if_errors`). Specifics: - Add some comments giving some usage guidelines. - Prefer `has_errors` to comparing `err_count` to zero. - Remove `has_errors_or_span_delayed_bugs` because it's a weird one: in the cases where we need to count delayed bugs, we should really be counting lint errors as well. - Rename `is_compilation_going_to_fail` as `has_errors_or_lint_errors_or_span_delayed_bugs`, for consistency with `has_errors` and `has_errors_or_lint_errors`. - Change a few other `has_errors_or_lint_errors` calls to `has_errors`, as per the "least general" principle. This didn't turn out to be as neat as I hoped when I started, but I think it's still an improvement.
2024-01-20Auto merge of #108359 - Zoxc:side-effects-tweak, r=cjgillotbors-6/+8
Avoid code generation for ThinVec<Diagnostic>'s destructor in the query system This avoids 2 instances of the destructor of `ThinVec<Diagnostic>` from being included in `execute_job`. It also outlines the cold branch in `store_side_effects` / `store_side_effects_for_anon_node`.
2024-01-20Avoid code generation for ThinVec<Diagnostic>'s destructor in the query systemJohn Kåre Alsaker-6/+8
2024-01-19Auto merge of #120006 - cjgillot:no-hir-owner, r=wesleywiserbors-58/+2
Get rid of the hir_owner query. This query was meant as a firewall between `hir_owner_nodes` which is supposed to change often, and the queries that only depend on the item signature. That firewall was inefficient, leaking the contents of the HIR body through `HirId`s. `hir_owner` incurs a significant cost, as we need to hash HIR twice in multiple modes. This PR proposes to remove it, and simplify the hashing scheme. For the future, `def_kind`, `def_span`... are much more efficient for incremental decoupling, and should be preferred.
2024-01-16Simplify BodyId hashing.Camille GILLOT-58/+2
2024-01-16Auto merge of #119977 - Mark-Simulacrum:defid-cache, r=cjgillotbors-2/+80
Cache local DefId-keyed queries without hashing This caches local DefId-keyed queries using just an IndexVec. This costs ~5% extra max-rss at most but brings significant runtime improvement, up to 13% cycle counts (mean: 4%) on primary benchmarks. It's possible that further tweaks could reduce the memory overhead further but this win seems worth landing despite the increased memory, particularly with regards to eliminating the present set in non-incr or storing it inline (skip list?) with the main data. We tried applying this scheme to all keys in the [first perf run] but found that it carried a significant memory hit (50%). instructions/cycle counts were also much more mixed, though that may have been due to the lack of the present set optimization (needed for fast iter() calls in incremental scenarios). Closes https://github.com/rust-lang/rust/issues/45275 [first perf run]: https://perf.rust-lang.org/compare.html?start=30dfb9e046aeb878db04332c74de76e52fb7db10&end=6235575300d8e6e2cc6f449cb9048722ef43f9c7&stat=instructions:u
2024-01-15Cache local DefId-keyed queries without hashingMark Rousskov-2/+80
Foreign maps are used to cache external DefIds, typically backed by metadata decoding. In the future we might skip caching `V` there (since loading from metadata usually is already cheap enough), but for now this cuts down on the impact to memory usage and time to None-init a bunch of memory. Foreign data is usually much sparser, since we're not usually loading *all* entries from the foreign crate(s).
2024-01-14Inline 2 functions that appear in dep-graph profiles.Camille GILLOT-0/+1
2024-01-10Add `DiagCtxt::delayed_bug`.Nicholas Nethercote-10/+7
We have `span_delayed_bug` and often pass it a `DUMMY_SP`. This commit adds `delayed_bug`, which matches pairs like `err`/`span_err` and `warn`/`span_warn`.
2024-01-09Rollup merge of #119527 - klensy:ordering, r=compiler-errorsGuillaume Gomez-7/+7
don't reexport atomic::ordering via rustc_data_structures, use std import This looks simpler.
2024-01-08Don't check for recursion in generator witness fieldsMichael Goulet-3/+4
2024-01-08Value recovery can take the whole CycleErrorMichael Goulet-13/+16
2024-01-08Make `DiagnosticBuilder::emit` consuming.Nicholas Nethercote-1/+1
This works for most of its call sites. This is nice, because `emit` very much makes sense as a consuming operation -- indeed, `DiagnosticBuilderState` exists to ensure no diagnostic is emitted twice, but it uses runtime checks. For the small number of call sites where a consuming emit doesn't work, the commit adds `DiagnosticBuilder::emit_without_consuming`. (This will be removed in subsequent commits.) Likewise, `emit_unless` becomes consuming. And `delay_as_bug` becomes consuming, while `delay_as_bug_without_consuming` is added (which will also be removed in subsequent commits.) All this requires significant changes to `DiagnosticBuilder`'s chaining methods. Currently `DiagnosticBuilder` method chaining uses a non-consuming `&mut self -> &mut Self` style, which allows chaining to be used when the chain ends in `emit()`, like so: ``` struct_err(msg).span(span).emit(); ``` But it doesn't work when producing a `DiagnosticBuilder` value, requiring this: ``` let mut err = self.struct_err(msg); err.span(span); err ``` This style of chaining won't work with consuming `emit` though. For that, we need to use to a `self -> Self` style. That also would allow `DiagnosticBuilder` production to be chained, e.g.: ``` self.struct_err(msg).span(span) ``` However, removing the `&mut self -> &mut Self` style would require that individual modifications of a `DiagnosticBuilder` go from this: ``` err.span(span); ``` to this: ``` err = err.span(span); ``` There are *many* such places. I have a high tolerance for tedious refactorings, but even I gave up after a long time trying to convert them all. Instead, this commit has it both ways: the existing `&mut self -> Self` chaining methods are kept, and new `self -> Self` chaining methods are added, all of which have a `_mv` suffix (short for "move"). Changes to the existing `forward!` macro lets this happen with very little additional boilerplate code. I chose to add the suffix to the new chaining methods rather than the existing ones, because the number of changes required is much smaller that way. This doubled chainging is a bit clumsy, but I think it is worthwhile because it allows a *lot* of good things to subsequently happen. In this commit, there are many `mut` qualifiers removed in places where diagnostics are emitted without being modified. In subsequent commits: - chaining can be used more, making the code more concise; - more use of chaining also permits the removal of redundant diagnostic APIs like `struct_err_with_code`, which can be replaced easily with `struct_err` + `code_mv`; - `emit_without_diagnostic` can be removed, which simplifies a lot of machinery, removing the need for `DiagnosticBuilderState`.
2024-01-06don't reexport atomic::ordering via rustc_data_structures, use std importklensy-7/+7
2024-01-03Rollup merge of #119086 - RossSmyth:query_panics, r=compiler-errorsLeón Orell Valerian Liehr-11/+21
Query panic!() to useful diagnostic Changes some more ICEs from bare panic!()s Adds an `expect_job()` helper method as that is a moral equivalent of what was happening at the uses. re:#118955
2024-01-03Add useful panic messages if queries fail to startRoss Smyth-11/+21
2023-12-26Auto merge of #119146 - nnethercote:rm-DiagCtxt-api-duplication, ↵bors-7/+7
r=compiler-errors Remove `DiagCtxt` API duplication `DiagCtxt` defines the internal API for creating and emitting diagnostics: methods like `struct_err`, `struct_span_warn`, `note`, `create_fatal`, `emit_bug`. There are over 50 methods. Some of these methods are then duplicated across several other types: `Session`, `ParseSess`, `Parser`, `ExtCtxt`, and `MirBorrowckCtxt`. `Session` duplicates the most, though half the ones it does are unused. Each duplicated method just calls forward to the corresponding method in `DiagCtxt`. So this duplication exists to (in the best case) shorten chains like `ecx.tcx.sess.parse_sess.dcx.emit_err()` to `ecx.emit_err()`. This API duplication is ugly and has been bugging me for a while. And it's inconsistent: there's no real logic about which methods are duplicated, and the use of `#[rustc_lint_diagnostic]` and `#[track_caller]` attributes vary across the duplicates. This PR removes the duplicated API methods and makes all diagnostic creation and emission go through `DiagCtxt`. It also adds `dcx` getter methods to several types to shorten chains. This approach scales *much* better than API duplication; indeed, the PR adds `dcx()` to numerous types that didn't have API duplication: `TyCtxt`, `LoweringCtxt`, `ConstCx`, `FnCtxt`, `TypeErrCtxt`, `InferCtxt`, `CrateLoader`, `CheckAttrVisitor`, and `Resolver`. These result in a lot of changes from `foo.tcx.sess.emit_err()` to `foo.dcx().emit_err()`. (You could do this with more types, but it gets into diminishing returns territory for types that don't emit many diagnostics.) After all these changes, some call sites are more verbose, some are less verbose, and many are the same. The total number of lines is reduced, mostly because of the removed API duplication. And consistency is increased, because calls to `emit_err` and friends are always preceded with `.dcx()` or `.dcx`. r? `@compiler-errors`
2023-12-24Auto merge of #119139 - michaelwoerister:cleanup-stable-source-file-id, ↵bors-3/+3
r=cjgillot Unify SourceFile::name_hash and StableSourceFileId This PR adapts the existing `StableSourceFileId` type so that it can be used instead of the `name_hash` field of `SourceFile`. This simplifies a few things that were kind of duplicated before. The PR should also fix issues https://github.com/rust-lang/rust/issues/112700 and https://github.com/rust-lang/rust/issues/115835, but I was not able to reproduce these issues in a regression test. As far as I can tell, the root cause of these issues is that the id of the originating crate is not hashed in the `HashStable` impl of `Span` and thus cache entries that should have been considered invalidated were loaded. After this PR, the `stable_id` field of `SourceFile` includes information about the originating crate, so that ICE should not occur anymore.
2023-12-24Remove more `Session` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-3/+3
2023-12-24Remove `Session` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-4/+4
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier access.
2023-12-23Give `DiagnosticBuilder` a default type.Nicholas Nethercote-4/+4
`IntoDiagnostic` defaults to `ErrorGuaranteed`, because errors are the most common diagnostic level. It makes sense to do likewise for the closely-related (and much more widely used) `DiagnosticBuilder` type, letting us write `DiagnosticBuilder<'a, ErrorGuaranteed>` as just `DiagnosticBuilder<'a>`. This cuts over 200 lines of code due to many multi-line things becoming single line things.
2023-12-19Unify SourceFile::name_hash and StableSourceFileIdMichael Woerister-3/+3
2023-12-18Use `.into_diagnostic()` less.Nicholas Nethercote-4/+2
This commit replaces this pattern: ``` err.into_diagnostic(dcx) ``` with this pattern: ``` dcx.create_err(err) ``` in a lot of places. It's a little shorter, makes the error level explicit, avoids some `IntoDiagnostic` imports, and is a necessary prerequisite for the next commit which will add a `level` arg to `into_diagnostic`. This requires adding `track_caller` on `create_err` to avoid mucking up the output of `tests/ui/track-diagnostics/track4.rs`. It probably should have been there already.
2023-12-18Rename many `DiagCtxt` and `EarlyDiagCtxt` locals.Nicholas Nethercote-2/+2
2023-12-18Rename many `DiagCtxt` arguments.Nicholas Nethercote-2/+2
2023-12-18Rename `Session::span_diagnostic` as `Session::dcx`.Nicholas Nethercote-2/+2
2023-12-18Rename `Handler` as `DiagCtxt`.Nicholas Nethercote-3/+3
2023-12-14Rollup merge of #118933 - nnethercote:cleanup-errors-even-more, ↵Jubilee-2/+2
r=compiler-errors Cleanup errors handlers even more A sequel to #118587. r? `@compiler-errors`
2023-12-15Split `Handler::emit_diagnostic` in two.Nicholas Nethercote-2/+2
Currently, `emit_diagnostic` takes `&mut self`. This commit changes it so `emit_diagnostic` takes `self` and the new `emit_diagnostic_without_consuming` function takes `&mut self`. I find the distinction useful. The former case is much more common, and avoids a bunch of `mut` and `&mut` occurrences. We can also restrict the latter with `pub(crate)` which is nice.
2023-12-12clippy::complexity fixesMatthias Krüger-13/+1
filter_map_identity needless_bool search_is_some unit_arg map_identity needless_question_mark derivable_impls
2023-12-10remove redundant importssurechen-2/+0
detects redundant imports that can be eliminated. for #117772 : In order to facilitate review and modification, split the checking code and removing redundant imports code into two PR.
2023-12-05Rollup merge of #118123 - RalfJung:internal-lib-features, r=compiler-errorsMichael Goulet-1/+1
Add support for making lib features internal We have the notion of an "internal" lang feature: a feature that is never intended to be stabilized, and using which can cause ICEs and other issues without that being considered a bug. This extends that idea to lib features as well. It is an alternative to https://github.com/rust-lang/rust/pull/115623: instead of using an attribute to declare lib features internal, we simply do this based on the name. Everything ending in `_internals` or `_internal` is considered internal. Then we rename `core_intrinsics` to `core_intrinsics_internal`, which fixes https://github.com/rust-lang/rust/issues/115597.
2023-12-02Use `Session::diagnostic` in more places.Nicholas Nethercote-1/+1
2023-12-02Rename `HandlerInner::delayed_span_bugs` as `HandlerInner::span_delayed_bugs`.Nicholas Nethercote-1/+1
For reasons similar to the previous commit.
2023-12-02Rename `HandlerInner::delay_span_bug` as `HandlerInner::span_delayed_bug`.Nicholas Nethercote-2/+2
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug` follows the pattern used everywhere else: `span_err`, `span_warning`, etc.
2023-11-29Auto merge of #118348 - Mark-Simulacrum:feature-code-size, r=compiler-errorsbors-4/+4
Cut code size for feature hashing This locally cuts ~32 kB of .text instructions. This isn't really a clear win in terms of readability. IMO the code size benefits are worth it (even if they're not necessarily present in the x86_64 hyperoptimized build, I expect them to translate similarly to other platforms). Ultimately there's lots of "small ish" low hanging fruit like this that I'm seeing that seems worth tackling to me, and could translate into larger wins in aggregate.
2023-11-27QueryContext: rename try_collect_active_jobs -> collect_active_jobs and ↵klensy-8/+5
change it's return type from Option<QueryMap> to QueryMap As there currently always Some(...) inside
2023-11-26Cut code size for feature hashingMark Rousskov-4/+4
This locally cuts ~32 kB of .text instructions.
2023-11-26Auto merge of #117301 - saethlin:finish-rmeta-encoding, r=WaffleLapkinbors-1/+1
Call FileEncoder::finish in rmeta encoding Fixes https://github.com/rust-lang/rust/issues/117254 The bug here was that rmeta encoding never called FileEncoder::finish. Now it does. Most of the changes here are needed to support that, since rmeta encoding wants to finish _then_ access the File in the encoder, so finish can't move out. I tried adding a `cfg(debug_assertions)` exploding Drop impl to FileEncoder that checked for finish being called before dropping, but fatal errors cause unwinding so this isn't really possible. If we encounter a fatal error with a dirty FileEncoder, the Drop impl ICEs even though the implementation is correct. If we try to paper over that by wrapping FileEncoder in ManuallyDrop then that just erases the fact that Drop automatically checks that we call finish on all paths. I also changed the name of DepGraph::encode to DepGraph::finish_encoding, because that's what it does and it makes the fact that it is the path to FileEncoder::finish less confusing. r? `@WaffleLapkin`
2023-11-26Use `rustc_fluent_macro::fluent_messages!` directly.Nicholas Nethercote-3/+1
Currently we always do this: ``` use rustc_fluent_macro::fluent_messages; ... fluent_messages! { "./example.ftl" } ``` But there is no need, we can just do this everywhere: ``` rustc_fluent_macro::fluent_messages! { "./example.ftl" } ``` which is shorter.
2023-11-26Avoid need for `{D,Subd}iagnosticMessage` imports.Nicholas Nethercote-1/+0
The `fluent_messages!` macro produces uses of `crate::{D,Subd}iagnosticMessage`, which means that every crate using the macro must have this import: ``` use rustc_errors::{DiagnosticMessage, SubdiagnosticMessage}; ``` This commit changes the macro to instead use `rustc_errors::{D,Subd}iagnosticMessage`, which avoids the need for the imports.
2023-11-23Rollup merge of #118169 - SparrowLii:deadlock_issue, r=compiler-errorsMatthias Krüger-6/+12
print query map for deadlock when using parallel front end print query map for deadlock when using parallel front end, so that we can analyze where and why deadlock occurs
2023-11-22Call FileEncoder::finish in rmeta encodingBen Kimock-1/+1
2023-11-23Nit of deadlock detectedSparrowLii-1/+1
2023-11-22also make 'core_intrinsics' internalRalf Jung-1/+1
2023-11-22Replace `custom_encodable` with `encodable`.Nicholas Nethercote-0/+1
By default, `newtype_index!` types get a default `Encodable`/`Decodable` impl. You can opt out of this with `custom_encodable`. Opting out is the opposite to how Rust normally works with autogenerated (derived) impls. This commit inverts the behaviour, replacing `custom_encodable` with `encodable` which opts into the default `Encodable`/`Decodable` impl. Only 23 of the 59 `newtype_index!` occurrences need `encodable`. Even better, there were eight crates with a dependency on `rustc_serialize` just from unused default `Encodable`/`Decodable` impls. This commit removes that dependency from those eight crates.
2023-11-22print query map for deadlock when using parallel front endSparrowLii-6/+12
2023-11-21Fix `clippy::needless_borrow` in the compilerNilstrieb-6/+6
`x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`. Then I had to remove a few unnecessary parens and muts that were exposed now.
2023-11-21Add HashStable_NoContext to simplify HashStable implementations in rustc_type_irMichael Goulet-2/+0