Fix expanding to short versions of constructs #8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes 2 issues:
if_chain
expandslet
andif let
to equivalent Rust expressions, but that's not the case on latest master --- both expand tomatch
expressions. This can be surprising when using macro expansion tools (e.g.cargo expand
) and the result doesn't look like what one would expect after reading docs.Special handling for some cases should make the result clearer for users and potentially reduce burden placed on the optimizer, even if by a very small margin.
{}
is matched with a block matcher, it can't be matched with literal{}
anymore. When that happens in a certain recursion step, for all next recursion steps the macro match arm with{}
becomes unreachable and the code gets expanded toif { ... } else { {} }
.The fix is to not use block matchers in presence of verbatim matching code. Generic
tt
matchers should be used in this case.Example that exhibits both problems:
Expansion before this PR:
Expansion after this PR:
I think
if_chain
should have macro expansion tests, but I don't know how to set up something like that (compiletest_rs
seems to not support that case).