about summary refs log tree commit diff
path: root/compiler/rustc_hir_analysis/src/collect
AgeCommit message (Collapse)AuthorLines
2023-12-20Give `VariantData::Struct` named fields, to clairfy `recovered`.Alona Enraght-Moony-1/+1
2023-12-18Rename `Session::span_diagnostic` as `Session::dcx`.Nicholas Nethercote-1/+1
2023-12-17skip rpit constraint check if borrowck return type errorbohan-0/+4
2023-12-15Rollup merge of #119004 - matthiaskrgr:conv, r=compiler-errorsJubilee-1/+1
NFC don't convert types to identical types
2023-12-15NFC don't convert types to identical typesMatthias Krüger-1/+1
2023-12-15Rollup merge of #118727 - compiler-errors:lint-decorate, r=WaffleLapkinJubilee-2/+2
Don't pass lint back out of lint decorator Change the decorator function in the signature of the `emit_lint`/`span_lint`/etc family of methods from `impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>` to `impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>)`. I consider it easier to read this way, especially when there's control flow involved. r? nnethercote though feel free to reassign
2023-12-15Rollup merge of #118396 - compiler-errors:ast-lang-items, r=cjgillotJubilee-26/+0
Collect lang items from AST, get rid of `GenericBound::LangItemTrait` r? `@cjgillot` cc #115178 Looking forward, the work to remove `QPath::LangItem` will also be significantly more difficult, but I plan on doing it as well. Specifically, we have to change: 1. A lot of `rustc_ast_lowering` for things like expr `..` 2. A lot of astconv, since we actually instantiate lang and non-lang paths quite differently. 3. A ton of diagnostics and clippy lints that are special-cased via `QPath::LangItem` Meanwhile, it was pretty easy to remove `GenericBound::LangItemTrait`, so I just did that here.
2023-12-15banish hir::GenericBound::LangItemTraitMichael Goulet-26/+0
2023-12-15Don't pass lint back out of lint decoratorMichael Goulet-2/+2
2023-12-15Annotate some bugsMichael Goulet-8/+29
2023-12-13Auto merge of #118500 - ZetaNumbers:tcx_hir_refactor, r=petrochenkovbors-23/+21
Move some methods from `tcx.hir()` to `tcx` https://github.com/rust-lang/rust/pull/118256#issuecomment-1826442834 Renamed: - find -> opt_hir_node - get -> hir_node - find_by_def_id -> opt_hir_node_by_def_id - get_by_def_id -> hir_node_by_def_id
2023-12-12clippy::complexity fixesMatthias Krüger-7/+4
filter_map_identity needless_bool search_is_some unit_arg map_identity needless_question_mark derivable_impls
2023-12-12Move some methods from `tcx.hir()` to `tcx`zetanumbers-23/+21
Renamings: - find -> opt_hir_node - get -> hir_node - find_by_def_id -> opt_hir_node_by_def_id - get_by_def_id -> hir_node_by_def_id Fix rebase changes using removed methods Use `tcx.hir_node_by_def_id()` whenever possible in compiler Fix clippy errors Fix compiler Apply suggestions from code review Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com> Add FIXME for `tcx.hir()` returned type about its removal Simplify with with `tcx.hir_node_by_def_id`
2023-12-05Remove `#[rustc_host]`, use internal desugaringDeadbeef-10/+8
2023-12-02Rename `HandlerInner::delay_span_bug` as `HandlerInner::span_delayed_bug`.Nicholas Nethercote-5/+5
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug` follows the pattern used everywhere else: `span_err`, `span_warning`, etc.
2023-11-26rustc: `hir().local_def_id_to_hir_id()` -> `tcx.local_def_id_to_hir_id()` ↵Vadim Petrochenkov-16/+16
cleanup
2023-11-21Fix `clippy::needless_borrow` in the compilerNilstrieb-12/+12
`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-14finish `RegionKind` renamelcnr-4/+4
- `ReFree` -> `ReLateParam` - `ReEarlyBound` -> `ReEarlyParam`
2023-11-12Small improvements in object lifetime default codeNilstrieb-1/+1
I found those while trying to understand how the code works.
2023-11-03clone lessMatthias Krüger-1/+1
2023-10-30Also consider TAIT to be uncomputable if the MIR body is taintedMichael Goulet-3/+11
2023-10-23Let's see what those opaque types actually areMichael Goulet-3/+17
2023-10-17Auto merge of #116756 - fee1-dead-contrib:dupe-those-bounds, r=oli-obkbors-5/+32
Duplicate `~const` bounds with a non-const one in effects desugaring This should unblock #116058. r? `@oli-obk`
2023-10-15Auto merge of #116688 - compiler-errors:rustfmt-up, r=WaffleLapkin,Nilstriebbors-72/+101
Format all the let-chains in compiler crates Since rust-lang/rustfmt#5910 has landed, soon we will have support for formatting let-chains (as soon as rustfmt syncs and beta gets bumped). This PR applies the changes [from master rustfmt to rust-lang/rust eagerly](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/out.20formatting.20of.20prs/near/374997516), so that the next beta bump does not have to deal with a 200+ file diff and can remain concerned with other things like `cfg(bootstrap)` -- #113637 was a pain to land, for example, because of let-else. I will also add this commit to the ignore list after it has landed. The commands that were run -- I'm not great at bash-foo, but this applies rustfmt to every compiler crate, and then reverts the two crates that should probably be formatted out-of-tree. ``` ~/rustfmt $ ls -1d ~/rust/compiler/* | xargs -I@ cargo run --bin rustfmt -- `@/src/lib.rs` --config-path ~/rust --edition=2021 # format all of the compiler crates ~/rust $ git checkout HEAD -- compiler/rustc_codegen_{gcc,cranelift} # revert changes to cg-gcc and cg-clif ``` cc `@rust-lang/rustfmt` r? `@WaffleLapkin` or `@Nilstrieb` who said they may be able to review this purely mechanical PR :> cc `@Mark-Simulacrum` and `@petrochenkov,` who had some thoughts on the order of operations with big formatting changes in https://github.com/rust-lang/rust/pull/95262#issue-1178993801. I think the situation has changed since then, given that let-chains support exists on master rustfmt now, and I'm fairly confident that this formatting PR should land even if *bootstrap* rustfmt doesn't yet format let-chains in order to lessen the burden of the next beta bump.
2023-10-15Duplicate `~const` bounds with a non-const one in effects desugaringDeadbeef-5/+32
2023-10-13Fix a commentDeadbeef-1/+1
2023-10-13Format all the let chains in compilerMichael Goulet-72/+101
2023-09-26Don't store lazyness in DefKindMichael Goulet-2/+24
2023-09-24Added additional visit steps to visit_generic_param() in order to avoid ICE ↵Lenko Donchev-16/+15
on no bound vars.
2023-09-22Rollup merge of #116039 - estebank:nested-tait, r=compiler-errorsMatthias Krüger-2/+7
Account for nested `impl Trait` in TAIT Fix #116031. r? `@compiler-errors`
2023-09-21Record asyncness span in HIRMichael Goulet-1/+1
2023-09-21Account for nested `impl Trait` in TAITEsteban Küber-2/+7
Fix #116031.
2023-09-20Auto merge of #115486 - compiler-errors:dont-capture-late-pls, r=cjgillotbors-20/+51
Correctly deny late-bound lifetimes from parent in anon consts and TAITs Reuse the `AnonConstBoundary` scope (introduced in #108553, renamed in this PR to `LateBoundary`) to deny late-bound vars of *all* kinds (ty/const/lifetime) in anon consts and TAITs. Side-note, but I would like to consolidate this with the error reporting for RPITs (E0657): https://github.com/rust-lang/rust/blob/c4f25777a08cd64b710e8a9a6159e67cbb35e6f5/compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs#L733-L754 but the semantics about what we're allowed to capture there are slightly different, so I'm leaving that untouched. Fixes #115474
2023-09-11add `is_host_effect` to `GenericParamDefKind::Const` and address reviewDeadbeef-1/+4
2023-09-05Correctly deny late-bound lifetimes from parent in anon consts and TAITsMichael Goulet-20/+51
2023-09-01Don't manually walk through param indices when adding implicit Sized and ↵Michael Goulet-108/+93
ConstParamHasTy
2023-08-27More precisely detect cycle errors from type_of on opaqueMichael Goulet-77/+99
2023-08-08Auto merge of #114545 - fee1-dead-contrib:lower-impl-effect, r=oli-obkbors-1/+1
correctly lower `impl const` to bind to host effect param r? `@oli-obk`
2023-08-08Auto merge of #114602 - compiler-errors:rpit-outlives-sadness, r=oli-obkbors-66/+28
Map RPIT duplicated lifetimes back to fn captured lifetimes Use the [`lifetime_mapping`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.OpaqueTy.html#structfield.lifetime_mapping) to map an RPIT's captured lifetimes back to the early- or late-bound lifetimes from its parent function. We may be going thru several layers of mapping, since opaques can be nested, so we introduce `TyCtxt::map_rpit_lifetime_to_fn_lifetime` to loop through several opaques worth of mapping, and handle turning it into a `ty::Region` as well. We can then use this instead of the identity substs for RPITs in `check_opaque_meets_bounds` to address #114285. We can then also use `map_rpit_lifetime_to_fn_lifetime` to properly install bidirectional-outlives predicates for both RPITs and RPITITs. This addresses #114601. I based this on #114574, but I don't actually know how much of that PR we still need, so some code may be redundant now... :shrug: --- Fixes #114597 Fixes #114579 Fixes #114285 Also fixes #114601, since it turns out we had other bugs with RPITITs and their duplicated lifetime params :sweat_smile:. Supersedes #114574 r? `@oli-obk`
2023-08-08Install bidirectional outlives predicates for RPITITs (and RPITs) correctlyMichael Goulet-66/+28
2023-08-08Unconditionally record lifetime mappingMichael Goulet-1/+1
2023-08-08Rollup merge of #114566 - fmease:type-alias-laziness-is-crate-specific, ↵Matthias Krüger-2/+2
r=oli-obk Store the laziness of type aliases in their `DefKind` Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not. With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*: Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates. As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions. --- This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold. `@rustbot` label F-lazy_type_alias r? `@oli-obk`
2023-08-07Store the laziness of type aliases in the DefKindLeón Orell Valerian Liehr-2/+2
2023-08-06lower impl const to bind to host effect paramDeadbeef-1/+1
2023-08-05Consolidate opaque ty and async fn lowering codeMichael Goulet-1/+1
2023-08-02Remove constness from `TraitPredicate`Deadbeef-12/+4
2023-07-30Remap explicit item bounds of RPITIT's opaque back to ty::OpaqueMichael Goulet-2/+46
2023-07-28Type-check generic const itemsLeón Orell Valerian Liehr-70/+45
2023-07-28Lower generic const items to HIRLeón Orell Valerian Liehr-1/+1
2023-07-25inline format!() args from rustc_codegen_llvm to the end (4)Matthias Krüger-6/+5
r? @WaffleLapkin