@@ -362,46 +362,68 @@ type capture_item = @{
362
362
#[ auto_serialize]
363
363
type capture_clause = @~[ capture_item ] ;
364
364
365
+ //
366
+ // When the main rust parser encounters a syntax-extension invocation, it
367
+ // parses the arguments to the invocation as a token-tree. This is a very
368
+ // loose structure, such that all sorts of different AST-fragments can
369
+ // be passed to syntax extensions using a uniform type.
370
+ //
371
+ // If the syntax extension is an MBE macro, it will attempt to match its
372
+ // LHS "matchers" against the provided token tree, and if it finds a
373
+ // match, will transcribe the RHS token tree, splicing in any captured
374
+ // early_parser::matched_nonterminals into the tt_nonterminals it finds.
375
+ //
376
+ // The RHS of an MBE macro is the only place a tt_nonterminal or tt_seq
377
+ // makes any real sense. You could write them elsewhere but nothing
378
+ // else knows what to do with them, so you'll probably get a syntax
379
+ // error.
380
+ //
365
381
#[ auto_serialize]
366
382
#[ doc="For macro invocations; parsing is delegated to the macro" ]
367
383
enum token_tree {
384
+ tt_tok( span , token:: token ) ,
368
385
tt_delim( ~[ token_tree ] ) ,
369
- tt_flat( span , token:: token ) ,
370
- /* These only make sense for right-hand-sides of MBE macros*/
371
- tt_dotdotdot( span , ~[ token_tree ] , option < token:: token > , bool ) ,
372
- tt_interpolate( span , ident )
386
+ // These only make sense for right-hand-sides of MBE macros
387
+ tt_seq( span , ~[ token_tree ] , option < token:: token > , bool ) ,
388
+ tt_nonterminal( span , ident )
373
389
}
374
390
375
- #[ auto_serialize]
376
- type matcher = spanned < matcher_ > ;
377
-
378
- #[ auto_serialize]
379
391
//
380
392
// Matchers are nodes defined-by and recognized-by the main rust parser and
381
- // language, but they're only ever found inside syntax-extension invocations.
382
- // They represent a small sub-language for pattern-matching token-trees, and
383
- // are thus primarily used by the macro-defining extension itself.
393
+ // language, but they're only ever found inside syntax-extension invocations;
394
+ // indeed, the only thing that ever _activates_ the rules in the rust parser
395
+ // for parsing a matcher is a matcher looking for the 'mtcs' nonterminal
396
+ // itself. Matchers represent a small sub-language for pattern-matching
397
+ // token-trees, and are thus primarily used by the macro-defining extension
398
+ // itself.
384
399
//
385
- // mtc_tok ===> A matcher that matches a single token,
386
- // denoted by the token itself. So long as
387
- // there's no $ involved.
400
+ // match_tok
401
+ // ---------
388
402
//
403
+ // A matcher that matches a single token, denoted by the token itself. So
404
+ // long as there's no $ involved.
389
405
//
390
- // mtc_rep ===> A matcher that matches a sequence of
391
- // sub-matchers, denoted various ways:
406
+ //
407
+ // match_seq
408
+ // ---------
409
+ //
410
+ // A matcher that matches a sequence of sub-matchers, denoted various
411
+ // possible ways:
392
412
//
393
413
// $(M)* zero or more Ms
394
414
// $(M)+ one or more Ms
395
415
// $(M),+ one or more comma-separated Ms
396
416
// $(A B C);* zero or more semi-separated 'A B C' seqs
397
417
//
398
418
//
399
- // mtc_bb ===> A matcher that matches one of a few interesting named rust
400
- // nonterminals, such as types, expressions, items, or raw
401
- // token-trees. A black-box matcher on expr, for example, binds an
402
- // expr to a given ident, and that ident can re-occur as an
403
- // interpolation in the RHS of a macro-by-example rule. For
404
- // example:
419
+ // match_nonterminal
420
+ // -----------------
421
+ //
422
+ // A matcher that matches one of a few interesting named rust
423
+ // nonterminals, such as types, expressions, items, or raw token-trees. A
424
+ // black-box matcher on expr, for example, binds an expr to a given ident,
425
+ // and that ident can re-occur as an interpolation in the RHS of a
426
+ // macro-by-example rule. For example:
405
427
//
406
428
// $foo:expr => 1 + $foo // interpolate an expr
407
429
// $foo:tt => $foo // interpolate a token-tree
@@ -411,21 +433,25 @@ type matcher = spanned<matcher_>;
411
433
//
412
434
// As a final, horrifying aside, note that macro-by-example's input is
413
435
// also matched by one of these matchers. Holy self-referential! It is matched
414
- // by an mtc_rep , specifically this one:
436
+ // by an match_seq , specifically this one:
415
437
//
416
438
// $( $lhs:mtcs => $rhs:tt );+
417
439
//
418
440
// If you understand that, you have closed to loop and understand the whole
419
441
// macro system. Congratulations.
420
442
//
443
+ #[ auto_serialize]
444
+ type matcher = spanned < matcher_ > ;
445
+
446
+ #[ auto_serialize]
421
447
enum matcher_ {
422
- /* match one token */
423
- mtc_tok ( token:: token ) ,
424
- /* match repetitions of a sequence: body, separator, zero ok?,
425
- lo, hi position-in-match-array used: */
426
- mtc_rep ( ~[ matcher ] , option < token:: token > , bool , uint , uint ) ,
427
- /* parse a Rust NT: name to bind, name of NT, position in match array : */
428
- mtc_bb ( ident , ident , uint )
448
+ // match one token
449
+ match_tok ( token:: token ) ,
450
+ // match repetitions of a sequence: body, separator, zero ok?,
451
+ // lo, hi position-in-match-array used:
452
+ match_seq ( ~[ matcher ] , option < token:: token > , bool , uint , uint ) ,
453
+ // parse a Rust NT: name to bind, name of NT, position in match array:
454
+ match_nonterminal ( ident , ident , uint )
429
455
}
430
456
431
457
#[ auto_serialize]
0 commit comments