Do not emit type errors after parse error in last statement of block
When recovering from a parse error inside a block, do not emit type
errors generating on that block's recovered return expression.
Fix#57383.
It's more convenient to have all this highly related stuff together on one screen (for future refactorings).
The `expand_invoc` function is compact enough now, after all the previous refactorings.
Remove a bunch of `Option`s that assumed that dummy fragment creation could fail.
The test output changed due to not performing the expansion in `fn expand_invoc` in case of the recursion limit hit.
The root expansion was missing one.
Expansions created for "derive containers" (see one of the next commits for the description) also didn't get expansion info.
Creating a fresh expansion and immediately generating a span from it is the most common scenario.
Also avoid allocating `allow_internal_unstable` lists for derive markers repeatedly.
And rename `ExpnInfo::with_unstable` to `ExpnInfo::allow_unstable`, seems to be a better fitting name.
This way we are processing all of them in a single point, rather than separately for each syntax extension kind.
Also, the standard expected/found wording is used.
It either returns the indeterminacy error, or valid (but perhaps dummy) `SyntaxExtension`.
With this change enum `Determinacy` is no longer used in libsyntax and can be moved to resolve.
The regressions in diagnosics are fixed in the next commits.
Create real working and registered (even if dummy) `SyntaxExtension`s for them.
This improves error recovery and allows to avoid all special cases for proc macro stubs (except for the error on use, of course).
The introduced dummy `SyntaxExtension`s can be used for any other inappropriately resolved macros as well.
We have to deal with dummy spans anyway
Remove def-site span from expander interfaces.
It's not used by the expansion infra, only by specific expanders, which can keep it themselves if they want it.
It was used to choose whether to apply derive markers like `#[rustc_copy_clone_marker]` or not,
but it was called before all the data required for resolution is available, so it could work incorrectly in some corner cases (like user-defined derives name `Copy` or `Eq`).
Delay the decision about markers until the proper resolution results are available instead.
It's internal to resolve and always results in `Res::Err` outside of resolve.
Instead put `DefKind::Fn`s themselves into the macro namespace, it's ok.
Proc macro stubs are items placed into macro namespase for functions that define proc macros.
https://github.com/rust-lang/rust/pull/52383
The rustdoc test is changed because the old test didn't actually reproduce the ICE it was supposed to reproduce.
Mark Rousskov