🐛 fix(resolver): accept guarded code the interpreter rejects

[gaborbernat]

A TYPE_CHECKING block only has to satisfy a type checker, so it can hold expressions the interpreter refuses. xarray writes T_XarrayOther = TypeVar("T_XarrayOther", bound="DataArray" | Dataset), which raises TypeError: unsupported operand type(s) for |: 'str' and 'type' the moment it runs. Executing the guard to recover its names hit that error and warned Failed guarded type import. The annotation then reached a name nobody had bound, so a second warning followed: Cannot resolve forward reference ... name 'T_Other' is not defined. The rendered page was right the whole time. The warnings alone fail a build run with -W, which is what #751 reports.

An import that raises keeps its warning, since a dependency missing from the docs environment is worth reporting, as #741 asked for. Other statements now leave their names behind as forward references, read off the assignment targets, or off the class or function name. That matches what a type checker sees, and format_annotation prints such a reference as its own name, so the rendered output holds still while both warnings go away. ✨

The stand-ins go into the module namespace the guarded code writes to, through setdefault, so a name that already resolves keeps whatever it points at.

[djhoese]

Wow, awesome, thanks for the fixes. One question:

An import that raises keeps its warning, since a dependency missing from the docs environment is worth reporting

Does this mean that if a type checking guard has a try/except ImportError that it will still warn on the missing import since I think this code is still executing one line at a time? Installing these missing dependencies is an easy enough workaround, but I wanted to check.