Why is this preferable?
I used resolve_path solely for stylistic reasons - it returns exactly what we want here (PathResolution), and returns "fully correct" result with all the adjustments like Def::Local -> Def::Upvar (even if they don't matter here).
I also don't like mixing "intermediate" resolution byproducts like LocalDef with final PathResolutions, again for stylistic reasons - high-level routines like resolve_pattern should work only with the latter. Can resolve_identifier return fully adjusted Result<PathResolution>, like resolve_path?

I changed from resolve_path to resolve_identifier specifically to avoid the adjustments.
For example, consider:

fn f(x: i32) {
    fn g(x: i32) {}
}

Here, if we call resolve_path on g's argument x, it "should" resolve to f's argument x. When this resolution gets adjusted, it would emit

can't capture dynamic environment in a fn item

(since we've already pushed the Ribs for g), which we clearly don't want.

I say "should" because right now, g's argument x does not resolve to f's argument x because of an implementation detail of the current hygiene algorithm. I'm working on a simplification of the hygiene algorithm after which g's argument x will resolve to f's argument x, and this change is groundwork for that.

Something is wrong here. Ideally, the adjustment routine should not report "can't capture" errors, it should just leave Locals outside of closures unadjusted.
Regarding

fn f(x: i32) {
    fn g(x: i32) {}
}

the consensus in #33118 seemed to be that items in block scopes are isolated from local variables, i.e. g shouldn't "see" the outer x and the inner x won't resolve to it.

@petrochenkov
I agree with that consensus, but haven't gotten around to implementing it yet. Once that's implemented and the inner x doesn't resolve to the outer x as you described, I agree that it would probably be better to use resolve_path or to have resolve_identifier do adjustment.

Ok, this is not a big deal anyway.