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 CL tries to improve the text around the order in which macro are expanded in various related way.
Its first occurrence is
It seems that we'll have an example of a smooth user experience. It is not the case, we have an example of macro expansion. Removing this occurrence of "smooth" help understand this won't be considered in the following example.
As the same "smooth" explanation is given below, nothing is lost.
This example comes, modified, from
https://doc.rust-lang.org/std/macro.compile_error.html . It uses cfg to cause a compile error if something is not as expected.
As far as my understanding of rust goes, this could not be done with call-by-name evaluation.
At the same time, this example shows the steps of
rewritting. (Approximatively. I still use code represented as strings instead of a list of token/an AST, for the sake of the readability)
According to the way step 1 of the algorithm is currently written, it seems that, in
foo!(bar!(baz));
, bothfoo!(bar!(baz))
andbar!(baz)
should be in the queue. This is false, asbar!
should not be evaluated untilfoo!
is.So the rewritting state that the traversal does not enter unevaluated macros. It also add a note about the exception of non-eager macros.
Technically, it should state that, for non-eager macro, the macro itself should not be evaluated until all of its argument containing macros are evaluated. But I guess it's already fit in the case "macro expansion is not resolved".