removed incomplete comment
as written, I don't believe this comment was helpful; I think it's better just to steer the reader toward a general understanding of hygiene.
This commit is contained in:
parent
351a5fd2b4
commit
268f6c56c2
|
@ -391,23 +391,6 @@ fn fold_arg_<T: Folder>(a: &Arg, fld: &mut T) -> Arg {
|
|||
|
||||
// build a new vector of tts by appling the Folder's fold_ident to
|
||||
// all of the identifiers in the token trees.
|
||||
//
|
||||
// This is part of hygiene magic. As far as hygiene is concerned, there
|
||||
// are three types of let pattern bindings or loop labels:
|
||||
// - those defined and used in non-macro part of the program
|
||||
// - those used as part of macro invocation arguments
|
||||
// - those defined and used inside macro definitions
|
||||
// Lexically, type 1 and 2 are in one group and type 3 the other. If they
|
||||
// clash, in order for let and loop label to work hygienically, one group
|
||||
// or the other needs to be renamed. The problem is that type 2 and 3 are
|
||||
// parsed together (inside the macro expand function). After being parsed and
|
||||
// AST being constructed, they can no longer be distinguished from each other.
|
||||
//
|
||||
// For that reason, type 2 let bindings and loop labels are actually renamed
|
||||
// in the form of tokens instead of AST nodes, here. There are wasted effort
|
||||
// since many token::IDENT are not necessary part of let bindings and most
|
||||
// token::LIFETIME are certainly not loop labels. But we can't tell in their
|
||||
// token form. So this is less ideal and hacky but it works.
|
||||
pub fn fold_tts<T: Folder>(tts: &[TokenTree], fld: &mut T) -> Vec<TokenTree> {
|
||||
tts.iter().map(|tt| {
|
||||
match *tt {
|
||||
|
|
Loading…
Reference in New Issue