Clarify eager macro explanation #1872
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Yuki Okushi <[email protected]>
Signed-off-by: Yuki Okushi <[email protected]>
Signed-off-by: Yuki Okushi <[email protected]>
Signed-off-by: Yuki Okushi <[email protected]>
This file was moved in rust-lang/rust#108618
…e stage1 compiler (rust-lang#1840)
Enabling the profiler runtime is an essential part of being able to properly work on the coverage instrumentation code. There's already a mention of it on this page, but it's made in passing and is easy to miss. This patch adds a much more prominent section containing recommended `config.toml` settings, including `profiler = true`.
The current link provides a link to two versions of the book, both redirecting to the "current version", which is the link this PR uses
Signed-off-by: onur-ozkan <[email protected]>
This flag was removed by <rust-lang/rust#119566>.
Co-authored-by: Yuki Okushi <[email protected]>
…#1849) * add some explain for rustbot commands * add more details about shortcuts * fix words on `r=someone` Co-authored-by: Yuki Okushi <[email protected]> --------- Co-authored-by: Yuki Okushi <[email protected]>
Co-authored-by: Yuki Okushi <[email protected]>
This CL tries to improve the text around the order in which macro are expanded in various related way. 1. Remove duplication of "smoother". Its first occurrence is > a smoother user experience. As an example 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. 2. Use an actual example of where eager expansion is needed 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) 3. Not all macros are in the queue According to the way step 1 of the algorithm is currently written, it seems that, in `foo!(bar!(baz));`, both `foo!(bar!(baz))` and `bar!(baz)` should be in the queue. This is false, as `bar!` should not be evaluated until `foo!` 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".
jieyouxu
added
the
S-waiting-on-review
jieyouxu
added
A-macros
|
Sorry, due to me messing up a git operation, we sadly had to force-push the whole commit history of rustc-dev-guide :( If you'd like to update this pull request, you will have to rebase it in a special way onto the new commit history (the new More context can be found here. |
|
@Kobzol to be frank, it's been opened for a year, without reivew. So, unless anyone tell me they expect to be reviewed and merged (with or without correction first), I don't intend to spend more time on it |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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".