| Age | Commit message (Collapse) | Author | Lines |
|
Emit dropped unemitted errors to aid in ICE debugging
|
|
|
|
|
|
|
|
Therefore we also remove `#[unsafe_destructor_blind_to_params]`
attribute completly.
|
|
|
|
|
|
|
|
Continue refactoring macro expansion and resolution
This PR continues the work started in https://github.com/rust-lang/rust/pull/62042.
It contains a set of more or less related refactorings with the general goal of making things simpler and more orthogonal.
Along the way most of the issues uncovered in https://github.com/rust-lang/rust/pull/62086 are fixed.
The PR is better read in per-commit fashion with whitespace changes ignored.
I tried to leave some more detailed commit messages describing the motivation behind the individual changes.
Fixes https://github.com/rust-lang/rust/issues/44692
Fixes https://github.com/rust-lang/rust/issues/52363
Unblocks https://github.com/rust-lang/rust/pull/62086
r? @matthewjasper
|
|
`InvocationKind::Attr { attr: None, .. }` meaning something entirely different from a regular attribute was confusing as hell.
|
|
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.
|
|
Create a fresh expansion for them instead - this is the usual way to allow unstable features for generated/desugared code.
Fixes https://github.com/rust-lang/rust/issues/52363
|
|
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.
|
|
Orthogonality and reuse are good.
|
|
ExpnInfo/MacroBacktrace/DiagnosticSpanMacroExpansion
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.
|
|
More consistent with other naming:
ExpnFormat -> ExpnKind
ExpnKind::name -> ExpnKind::descr
DesugaringKind::name -> DesugaringKind::descr
Shorter, no tautology:
CompilerDesugaring -> Desugaring
CompilerDesugaringKind -> DesugaringKind
|
|
So it can be eventually used in `ExpnInfo`
|
|
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.
|
|
|
|
|
|
|
|
We're always indenting by INDENT_UNIT anyway
|
|
|
|
Also moves it to pp::Printer from PrintState.
|
|
|
|
It was always set to the string's length
|
|
This is also easier to understand because the scan and print "tasks" are
separate, but previously were both called "print" or "pretty print."
|
|
These are somewhat ambiguous (beginning/end of what?) so it's better to
inline their one use into the code.
|
|
Presumably the code was from an older age of Rust and can now be written
much simpler.
|
|
|
|
|
|
|
|
|
|
This enforces that eof() must be called to get the String out, and
generally is better from an API perspective. No users of pretty printing
pre-allocate the buffer.
|
|
This function took too many arguments and are simple on the inside;
inlining them makes complexity go down.
hir::print's copy is unfortunately used from librustc_driver so inlining
it is not as straightforward.
|
|
|
|
|
|
This also permits sharing the underlying code between pprust and
hir::print.
|
|
There was only one callsite for each and this removes the
unwrap_or_default's on the comments argument
|
|
We always check against the length before indexing anyway.
|
|
|
|
|
|
|
|
|