Add a new method `references_only_ty_error` to the `Ty` implementation
to determine if a type contains only type errors, ignoring const and
lifetime errors. Enhance test suite for const generic method resolution.
After a recent introduction of per-package flycheck for JSON projects, the code
assumed that `world.flycheck` indices matched `world.workspaces` indices.
However, not all workspaces have flycheck enabled (e.g., JSON projects
without a flycheck template configured), so the flycheck vector can be
shorter than the workspaces vector.
This caused an index-out-of-bounds panic when saving a file in a JSON
project without flycheck configured:
thread 'Worker' panicked at notification.rs:
index out of bounds: the len is 0 but the index is 0
Fix by looking up the flycheck handle by its ID (which is the workspace
index set during spawn) rather than using the workspace index directly
as a vector index.
Based on earlier work by León Orell Valerian Liehr.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Signed-off-by: Usman Akinyemi <uniqueusman@archlinux>
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#150846 (include `HirId`s directly in the THIR, not wrapped in `LintLevel`s)
- rust-lang/rust#150979 (Avoid ICEs after bad patterns, for the other syntactic variants)
- rust-lang/rust#151103 (mir_build: Simplify length-determination and indexing for array/slice patterns)
- rust-lang/rust#151130 (resolve: Downgrade `ambiguous_glob_imports` to warn-by-default)
r? @ghost
mir_build: Simplify length-determination and indexing for array/slice patterns
The existing length-determination code in `prefix_slice_suffix` has ended up overly complicated, partly because it doesn't know in advance whether the pattern is supposed to be an array pattern or a slice pattern.
Pulling most of that step out into the `PatKind::Array` arm makes the whole thing a bit nicer overall.
There should (hopefully) be no change to compiler output. The biggest “functional” change is that we now discard the subpatterns of an array pattern of unknowable length, instead of treating it as a slice pattern. I'm not aware of any way for this to make an observable difference, and it can only occur when compilation is already doomed to fail.
Avoid ICEs after bad patterns, for the other syntactic variants
This PR introduces changes equivalent to the ones in rust-lang/rust#126320, but also for struct and tuple patterns, instead of tuple struct patterns only.
Fixesrust-lang/rust#150507.
include `HirId`s directly in the THIR, not wrapped in `LintLevel`s
Occurrences of `LintLevel` in the THIR were always `LintLevel::Explicit`, containing a `HirId`, so we don't need to make it possible to put `LintLevel::Inherited` there. Removing the unused case where `HirId`s aren't present in the THIR slightly simplifies diagnostics/lints/tools that want to map from the THIR back to the HIR, e.g. rust-lang/rust#145569.
Since `LintLevel` is no longer present in the THIR, I've moved it in the second commit to live in `rustc_mir_build`; that's where it's actually used. I'm not sure exactly where exactly it should live there, but I put it in the `builder::scope` module since it's used by `Builder::in_scope` for determining when to introduce source scopes.
r? lcnr as the reviewer of rust-lang/rust#145569, since this was discussed there
