add name bindings for bad imports

[nrc]

e.g.,

use foo::bar;

fn main() {
    bar();
}

Assuming bar doesn't exist, we signal two errors here - one on the use and one on the call. We should insert a dummy definition for bar so we don't signal the second error.

Note that this is somewhat fixing a regression caused by #31065

[dirk]

@nrc: Trying to understand where the dummy definition inserting should occur. From looking at the linked PR and librustc_resolve, it looks like the insertion could occur in/around resolve_import_for_module. Is this a good guess, or should I be looking elsewhere?

[nrc]

Should probably happen in this function: https://dxr.mozilla.org/rust/source/src/librustc_resolve/lib.rs#1861-1888

Or possibly one of its callers.

[dirk]

@nrc: Ohhh, that definitely seems like the right place. I'll give this a shot tomorrow; thanks for pointing me in the right direction!

[dirk]

@nrc: If I've read things correctly, it looks like that Resolver::report_unresolved_imports function won't have the path that caused the import error in question. It seems like where paths get determined to be incorrect is happening in ImportResolver::resolve_imports.

Both of those paths, however, converge on resolve_struct_error, so I'm guessing perhaps the match branch for ResolutionError::UnresolvedImport would be the correct place to see if there's a path determined and then, if there is, create the dummy definition(s) for any names on the tail of the Path. How does that sound?

[nrc]

Every error ends up converging in resolve_struct_error, so I am wary about putting anything there except for formatting error messages, etc. I would add some code to resolve_imports, you might want to factor that into a function if it is complex or repeated.

[dirk]

@nrc: Understood, thanks. I'll give that a shot. 😄

[dirk]

@nrc: Can this be closed now that #31338 is merged?

[nrc]

Closed by #31338