save-analysis: Nest typeck tables when processing functions/methods

[Xanewok]

Fixes an issue where we did not nest tables correctly when resolving
associated types in formal argument/return type positions.

This was the minimized reproduction case that I tested the fix on:

pub trait Trait {
    type Assoc;
}

pub struct A;

pub fn func() {
    fn _inner1<U: Trait>(_: U::Assoc) {}
    fn _inner2<U: Trait>() -> U::Assoc { unimplemented!() }

    impl A {
        fn _inner1<U: Trait>(self, _: U::Assoc) {}
        fn _inner2<U: Trait>(self) -> U::Assoc { unimplemented!() }
    }
}

using debug_assertions-enabled rustc and by additionally passing -Zsave-analysis.

Unfortunately the original assertion fired is a debug one and from what I can tell we don't run the tests with these on, so I'm not adding a test here. If I missed it and there is a way to run tests with these on, I'd love to add a test case for this.

Closes #63663
Closes #50328
Closes #43982

[rust-highfive]

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

We can probably change the assertion to be a non-debug assertion?

[Xanewok]

We can probably change the assertion to be a non-debug assertion?

Started a try->perf run over at #64262

[Xanewok]

Perf run turned out to be okay, so I dropped the conditional compilation on debug assertions and added a test case.

[varkor]

@bors r+

[bors]

📌 Commit 7730ef1 has been approved by varkor

[Centril]

Failed in #64366 (comment), @bors r-

[Xanewok]

That's unfortunate, thanks for the heads up; will look into it tomorrow

Failure:

error: internal compiler error: src/librustc/ty/context.rs:211: node type <I>::Item (hir_id=HirId { owner: DefIndex(4366), local_id: 4 }) with HirId::owner DefId(0:4366 ~ core[db80]::iter[0]::adapters[0]::{{impl}}[25]::try_fold[0]::nth[0]::{{opaque}}[0]) cannot be placed in TypeckTables with local_id_root DefId(0:4364 ~ core[db80]::iter[0]::adapters[0]::{{impl}}[25]::try_fold[0]::nth[0])

Probably caused by

rust/src/libcore/iter/adapters/mod.rs

Line 544 in 34e82a7

fn nth<I: Iterator>(iter: &mut I, step: usize) -> impl FnMut() -> Option<I::Item> + '_ {

EDIT: Minimized to:

pub trait Trait {
    type Assoc;
}

pub fn func() {
    fn _inner<U: Trait>() -> impl Fn(U::Assoc) { |_| unimplemented!() }
}

[Xanewok]

This is updated and ready for review again.

The last bug was uncovered when processing type paths in return type impl Traits.

Specifically, this is because we try to resolve the qualified type path using the typeck tables but a debug assertion fires since the def id of the type path and that of the table don't share the same local id root.
That's because the impl Trait lowering creates a definition introducing a separate {{opaque}} def path segment with trait bounds as def children.

Unfortunately, the correct way under the current architecture would be to nest the tables further, however from what I can tell the newly lowered synthetic def path segment does not have typeck tables (probably rightly so? @nikomatsakis), so to prevent the underlying ICE and to enable the debug assertion for good now, I decided to only add explanatory comments and skip processing bounds in impl Traits in return type position for now.

As a side note, the current save-analysis infrastructure is slowly becoming dated as we introduce more supporting infrastructure with time (e.g. cleaning up resolution, definition infra from incremental), so it might be worth thinking how to handle it in the medium-term (leverage HIR directly instead of AST? maybe use it as a way to somehow bridge/push for librarification of the frontend?).

[jonas-schievink]

This also fixes #57298 and #55172

[varkor]

@bors r+

[bors]

📌 Commit a946b8d has been approved by varkor

[flip1995]

b456c82 lets Clippy ICE, when calling qpath_res on the HirId of a struct field type.

Call stack:

LateLintPass::check_struct_field(.., cx, field);
cx.tables.qpath_res(field.ty.node -> qpath, field.ty.hir_id);

This seems weird to me, since we're checking the QPath of a HIR node with the HirId of the same node. @Xanewok is this related to #64250 (comment)?

[Xanewok]

Left some explanation on why the assertion fires and how to fix it at rust-lang/rust-clippy#4545 (comment)