From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) by sourceware.org (Postfix) with ESMTPS id 421E63857C53 for ; Sat, 17 Jul 2021 14:26:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 421E63857C53 Received: by mail-oo1-xc2b.google.com with SMTP id o3-20020a4a84c30000b0290251d599f19bso3191492oog.8 for ; Sat, 17 Jul 2021 07:26:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TlUBldCHK49EAb8XTD4taOVvU1iDgzMnIjDdNvLQV0o=; b=OfcRKCHnje5rlg5dwxlDlfN61duPaq2vlrfGIyNKcvvyD+TN9TcNcqbO6l5jccDlZP tE5ulWQNuGiYiWUPkWJR9/PDVrmzQv5am76J/Dl9iSfQ1W+guLQTz6IrfzrCu4z9KH85 C1XapA+FMhcAVNtJyfgi76u6Eg7xF+ElO9GF5NT6g3bnsR+qlmgtTscfBWljgQI9CODD Q8tSZWW88JKNU2zP+IkyEd8URi/Qej5t0vXhtpdAvJY9pwwoxbkSxXixase6xUJOBt1D hxQgUy/ha7i7kG96ZNFFbaT/zT77Ch2+Iez1KK80ry2nzEa17O1NXDG/+Z/3fcfb9R+n 5lBg== X-Gm-Message-State: AOAM530rdj5Ked0SZHrdELPEN6Q7eNAsAVht7M5FlYrew3rZP5PFY/1X XPC9ff9UoagbWlPnJyJxBYPOJGjA5WeJtJWEIB8= X-Google-Smtp-Source: ABdhPJzx3e/0+JvlLVya39EdW5GsiULI1vafsMER+EFGDFzXHsitCIW8tJp1TFTHvEhvlwoM3jxk0jLnifRVDnxT1Cg= X-Received: by 2002:a4a:6f0e:: with SMTP id h14mr11398437ooc.9.1626531959058; Sat, 17 Jul 2021 07:25:59 -0700 (PDT) MIME-Version: 1.0 References: <20210711201018.389798-1-mark@klomp.org> <991da98e-d432-9e5c-feb1-66cf7e8bf6a0@embecosm.com> In-Reply-To: From: The Other Date: Sat, 17 Jul 2021 22:25:48 +0800 Message-ID: Subject: Fwd: New contributor tasks To: mark@klomp.org Cc: gcc-rust@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000a2b45905c7527b45" X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_LINEPADDING, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-rust@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: gcc-rust mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2021 14:26:03 -0000 --000000000000a2b45905c7527b45 Content-Type: text/plain; charset="UTF-8" Sorry, pressed the wrong button. I meant to "reply all". ---------- Forwarded message --------- From: The Other Date: Sat, Jul 17, 2021 at 10:20 PM Subject: Re: New contributor tasks To: Philip Herron > The AST dump (--rust-dump-parse) was actually useful for checking the > comment doc strings, but it could certainly be improved. Ideally it > would be structured in a way that can easily be used in tests. Yes, I agree. It has its mismatched style because I originally intended it to be basically "to_string" in the most literal sense possible, but then realised this would be infeasible for some of the more complicated parts. Theoretically, I would personally like it to be in a format similar to clang's AST dump. > - Full unicode/utf8 support in the lexer. Currently the lexer only > explicitly interprets the input as UTF8 for string parseing. It > should really treat all input as UTF-8. gnulib has some handy > modules we could use to read/convert from/to utf8 (unistr/u8-to-u32, > unistr/u32-to-u8) and test various unicode properties > (unictype/property-white-space, unictype/property-xid-continue, > unictype/property-xid-start). I don't know if we can import those or > if gcc already has these kind of UTF-8/unicode support functions for > other languages? At the time of writing the lexer, I was under the impression that Rust only supported UTF-8 in strings. The Rust Reference seems to have changed now to show that it supports UTF-8 in identifiers as well. I believe that the C++ frontend, at least, has its own specific hardcoded UTF-8 handling for identifiers and strings (rather than using a library). There could be issues with lookahead of several bytes (which the lexer uses liberally) if using UTF-8 in strings, depending on the exact implementation of whatever library you use (or function you write). >> - Error handling using rich locations in the lexer and parser. It >> seems some support is already there, but it isn't totally clear to >> me what is already in place and what could/should be added. e.g. how >> to add notes to an Error. > I've made a wrapper over RichLocation i had some crashes when i added > methods for annotations. Overall my understanding is that a Location > that we have at the moment is a single character location in the source > code but Rustc uses Spans which might be an abstraction we could think > about implementing instead of the Location wrapper we are reusing for > GCCGO. The Error class may need to be redesigned. It was a quick fix I made to allow parse errors to be ignored (since macro expansion would cause parse errors with non-matching macro matchers). Instead of having the "emit_error" and "emit_fatal_error" methods, it may be better to instead store a "kind" of error upon construction, and then just have an "emit" method that will emit the type of error as specified. Similarly, Error may have to be rewritten to use RichLocation instead of Location or something. >> - I noticed some expressions didn't parse because of what looks to me >> operator precedence issues. e.g the following: >> >> const S: usize = 64; >> >> pub fn main () >> { >> let a:u8 = 1; >> let b:u8 = 2; >> let _c = S * a as usize + b as usize; >> } >> >> $ gcc/gccrs -Bgcc as.rs >> >> as.rs:7:27: error: type param bounds (in TraitObjectType) are not allowed as TypeNoBounds >> 7 | let _c = S * a as usize + b as usize; >> | ^ >> >> How does one fix such operator precedence issues in the parser? > Off the top of my head it looks as though the parse_type_cast_expr has a > FIXME for the precedence issue for it. The Pratt parser uses the notion > of binding powers to handle this and i think it needs to follow in a > similar style to the ::parse_expr piece. Yes, this is probably a precedence issue. The actual issue is that while expressions have precedence, types (such as "usize", which is what is being parsed) do not, and greedily parse tokens like "+". Additionally, the interactions of types and expressions and precedence between them is something that I have no idea how to approach. I believe that this specific issue could be fixed by modifying the parse_type_no_bounds method - if instead of erroring when finding a plus, it simply returned (treating it like an expression would treat a semicolon, basically), then this would have the desired functionality. I don't believe that parse_type_no_bounds (TypeNoBounds do not have '+' in them) would ever be called in an instance where a Type (that allows bounds) is allowable, so this change should hopefully not cause any correct programs to parse incorrectly. >> - rust-macro-expand tries to handle both macros and attributes, is >> this by design? Should we handle different passes for different >> (inert or not) attributes that run before or after macro expansion? > As for macro and cfg expansion Joel some stuff already in place but i do > think they need to be separated into distinct passes which would be a > good first start with the expand folder. That is a good question. Technically, rust-macro-expand only handles cfg expansion at the moment. You can read and discuss more about that here: https://github.com/Rust-GCC/gccrs/issues/563 Thanks, Joel On Tue, Jul 13, 2021 at 9:16 PM Philip Herron wrote: > On 12/07/2021 23:44, Mark Wielaard wrote: > > On Mon, Jul 12, 2021 at 11:06:01AM +0100, Philip Herron wrote: > >> Great work once again. I am aiming to spend some time towards the end of > >> the week to add more tickets and info for new contributors to get > >> involved, which I will post the interesting ones onto the mailing list > >> as well. I think it should be interesting to contributors of all levels. > >> The main one that sticks out in my mind is the AST, HIR dumps which are > >> a bit of a mess at the moment. > > The AST dump (--rust-dump-parse) was actually useful for checking the > > comment doc strings, but it could certainly be improved. Ideally it > > would be structured in a way that can easily be used in tests. > I think a really good project would be to update our HIR dump, it should > really be an S-expression format so we can emit the > Analysis::NodeMapping information in a way that looks good at the moment > its a mess. > > Some (random) notes I made on issues that might be nice to explain > > and/or work on. > > > > - Full unicode/utf8 support in the lexer. Currently the lexer only > > explicitly interprets the input as UTF8 for string parseing. It > > should really treat all input as UTF-8. gnulib has some handy > > modules we could use to read/convert from/to utf8 (unistr/u8-to-u32, > > unistr/u32-to-u8) and test various unicode properties > > (unictype/property-white-space, unictype/property-xid-continue, > > unictype/property-xid-start). I don't know if we can import those or > > if gcc already has these kind of UTF-8/unicode support functions for > > other languages? > GCCGO supports utf-8 formats for identifiers but I think it has its own > implementation to do this. I think pulling in gnulib sounds like a good > idea, i assume we should ask about this on the GCC mailing list but I > would prefer to reuse a library for utf8 support. The piece about > creating the strings in GENERIC will need updated as part of that work. > > - Error handling using rich locations in the lexer and parser. It > > seems some support is already there, but it isn't totally clear to > > me what is already in place and what could/should be added. e.g. how > > to add notes to an Error. > I've made a wrapper over RichLocation i had some crashes when i added > methods for annotations. Overall my understanding is that a Location > that we have at the moment is a single character location in the source > code but Rustc uses Spans which might be an abstraction we could think > about implementing instead of the Location wrapper we are reusing for > GCCGO. > > - I noticed some expressions didn't parse because of what looks to me > > operator precedence issues. e.g the following: > > > > const S: usize = 64; > > > > pub fn main () > > { > > let a:u8 = 1; > > let b:u8 = 2; > > let _c = S * a as usize + b as usize; > > } > > > > $ gcc/gccrs -Bgcc as.rs > > > > as.rs:7:27: error: type param bounds (in TraitObjectType) are not > allowed as TypeNoBounds > > 7 | let _c = S * a as usize + b as usize; > > | ^ > > > > How does one fix such operator precedence issues in the parser? > > Off the top of my head it looks as though the parse_type_cast_expr has a > FIXME for the precedence issue for it. The Pratt parser uses the notion > of binding powers to handle this and i think it needs to follow in a > similar style to the ::parse_expr piece. > > > - Related, TypeCastExpr as the above aren't lowered from AST to HIR. > > I believe I know how to do it, but a small description of the visitor > > pattern used and in which files one does such lowering would be > helpful. > The AST->HIR lowering does need some documentation, since it must go > through name-resolution first but there is no documentation on how any > of this works yet. I will put this on my todo list its come up a few > times the naming of some of the classes like ResolveItemToplevel vs > ResolveItem are confusing things. Some of this will get cleaned up as > part of traits, such as the forward declared items within a block bug: > > Basically the idea is that we always perform a toplevel scan for all > items and create long canonical names in the top most scope, such that > we can resolve their names at any point without requiring prototypes or > look ahead. This means we have a pass to look for the names then we have > a pass to then resolve each structures fields, functions parameters, > returns types and blocks of code. So if a block calls to a function > declared ahead we can still resolve it to its NodeId. It is when we > ResolveItem we push new contexts onto the stack to have lexical scoping > for names. Its worth noting that Rust also supports shadowing of > variables within a block so these do not cause a duplicate name error > and simply add a new declaration to that context or what rustc calls > Ribs such that further resolution will reference this new declaration > and the previous one is shadowed correctly. > > > - And of course, how to lower HIR to GENERIC? For TypeCastExpr you > > said on irc we need traits first, but the semantics for primitive > > types is actually spelled out in The Reference. Can we already > > handle them for primitive types (like in the above example having an > > u8 as usize)? > Lowering HIR to GENERIC documentation is on my todo list as well, though > there are a bunch of cleanups I have in progress which should also help > here. > > - rust-macro-expand tries to handle both macros and attributes, is > > this by design? Should we handle different passes for different > > (inert or not) attributes that run before or after macro expansion? > As for macro and cfg expansion Joel some stuff already in place but i do > think they need to be separated into distinct passes which would be a > good first start with the expand folder. > > > > Cheers, > > > > Mark > > > Great summary mail i think this sums up a lot of the common issues. Note > I added in Joel who wrote the parser he might be to provide more insight. > > I added some comments inline to each point. I think i can take away from > this that we are missing some useful pieces of architecture > documentation which is becoming important. I think it will be easier for > me to get this done in a few weeks as there are changes in the areas > referenced which will affect the documentation. > > Overall I do really like the visitor pattern for this work since it is > isolating the code for each AST or HIR node but it is more difficult to > follow the flow of the pipeline. > > Sorry this does not contain all of the answers yet but I will work on > them. Thanks > > --Phil > > > > > > > > > > > > > --000000000000a2b45905c7527b45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, pressed the wrong button. I meant to "reply al= l".

---------- Forwarded message ---------
From: The Other <simplytheother@gmail.com>Date: Sat, Jul 17, 2021 at 10:20 PM
Subject: Re: New contributor tasks<= br>To: Philip Herron <phil= ip.herron@embecosm.com>


> The AST dump (--rust-dump-parse) was actually useful for checking the<= br> > comment doc strings, but it could certainly be improved. Ideally it > would be structured in a way that can easily be used in tests.

Yes, I agree. It has its mismatched style because I = originally intended it to be basically "to_string" in the most li= teral sense possible, but then realised this would be infeasible for some o= f the more complicated parts. Theoretically, I would personally like it to = be in a format similar to clang's AST dump.

&g= t; - Full unicode/utf8 support in the lexer. Currently the lexer only
>=C2=A0 =C2=A0explicitly interprets the input as UTF8 for string parsein= g. It
>=C2=A0 =C2=A0should really treat all input as UTF-8. gnulib has some ha= ndy
>=C2=A0 =C2=A0modules we could use to read/convert from/to utf8 (unistr/= u8-to-u32,
>=C2=A0 =C2=A0unistr/u32-to-u8) and test various unicode properties
>=C2=A0 =C2=A0(unictype/property-white-space, unictype/property-xid-cont= inue,
>=C2=A0 =C2=A0unictype/property-xid-start). I don't know if we can i= mport those or
>=C2=A0 =C2=A0if gcc already has these kind of UTF-8/unicode support fun= ctions for
>=C2=A0 =C2=A0other languages?

At the time= of writing the lexer, I was under the impression that Rust only supported = UTF-8 in strings. The Rust Reference seems to have changed now to show that= it supports UTF-8 in identifiers as well. I believe that the C++ frontend,= at least, has its own specific hardcoded UTF-8 handling for identifiers an= d strings (rather than using a library).

There cou= ld be issues with lookahead of several bytes (which the lexer uses liberall= y) if using UTF-8 in strings, depending on the exact implementation of what= ever library you use (or function you write).

>> - Error handling using rich locations in the lexer and parser.=C2= =A0 It
>>=C2=A0=C2=A0 seems some support is already there, but it isn't = totally clear to
>> =C2=A0 me what is already in place and what could/should be added.= e.g. how
>>=C2=A0=C2=A0 to add notes to an Error.
> I've made a wrapper over RichLocation i had some crashes when i ad= ded
> methods for annotations. Overall my understanding is that a Loc= ation
> that we have at the moment is a single character location in the sourc= e
> code but Rustc uses Spans which might be an abstraction we could think=
> about implementing instead of the Location wrapper we are reusing for<= br>> GCCGO.

The Error class may need to be redesigned. It was= a quick fix I made to allow parse errors to be ignored (since macro expans= ion would cause parse errors with non-matching macro matchers). Instead of = having the "emit_error" and "emit_fatal_error" methods,= it may be better to instead store a "kind" of error upon constru= ction, and then just have an "emit" method that will emit the typ= e of error as specified.
Similarly, Error may have to be rewritte= n to use RichLocation instead of Location or something.

>> - I noticed some expressions didn't parse because of what look= s to me
>>=C2=A0 =C2=A0operator precedence issues. e.g the following:
>>
>>=C2=A0 =C2=A0const S: usize =3D 64;
>>
>>=C2=A0 =C2=A0pub fn main ()
>>=C2=A0 =C2=A0{
>>=C2=A0 =C2=A0 =C2=A0let a:u8 =3D 1;
>>=C2=A0 =C2=A0 =C2=A0let b:u8 =3D 2;
>>=C2=A0 =C2=A0 =C2=A0let _c =3D S * a as usize + b as usize;
>>=C2=A0 =C2=A0}
>>
>>=C2=A0 =C2=A0$ gcc/gccrs -Bgcc as.rs
>>
>>=C2=A0 =C2=A0as.rs:7:27: error: type param bounds (in TraitObjectTy= pe) are not allowed as TypeNoBounds
>>=C2=A0 =C2=A0 =C2=A07 |=C2=A0 =C2=A0let _c =3D S * a as usize + b a= s usize;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
>>
>>=C2=A0 =C2=A0How does one fix such operator precedence issues in th= e parser?

> Off the top of my head it looks as though the parse_type_cast_expr has= a
> FIXME for the precedence issue for it. The Pratt parser uses the notio= n
> of binding powers to handle this and i think it needs to follow in a > similar style to the ::parse_expr piece.

Yes, this is probably a precedence issue. The actual issue is that while e= xpressions have precedence, types (such as "usize", which is what= is being parsed) do not, and greedily parse tokens like "+". Add= itionally, the interactions of types and expressions and precedence between= them is something that I have no idea how to approach.
I be= lieve that this specific issue could be fixed by modifying the parse_type_n= o_bounds method - if instead of erroring when finding a plus, it simply ret= urned (treating it like an expression would treat a semicolon, basically), = then this would have the desired functionality. I don't believe that pa= rse_type_no_bounds (TypeNoBounds do not have '+' in them) would eve= r be called in an instance where a Type (that allows bounds) is allowable, = so this change should hopefully not cause any correct programs to parse inc= orrectly.

>> - rust-macro-expand tries to handle both macros and attributes, is=
>>=C2=A0 this by design?=C2=A0 Should we handle different passes for = different
>>=C2=A0 (inert or not) attributes that run before or after macro exp= ansion?
> As for macro and cfg expansion Joel some stuff already in place but i = do
> think they need to be separated into distinct passes which would be a<= br> > good first start with the expand folder.

That is a good question. Technically, rust-macro-expand only handles cfg e= xpansion at the moment. You can read and discuss more about that here: http= s://github.com/Rust-GCC/gccrs/issues/563

Thank= s,
Joel


On Tue, Jul 13, 2021 at 9:16 PM P= hilip Herron <philip.herron@embecosm.com> wrote:
On 12/07/2021 23:44, Mark Wielaard wrote:<= br> > On Mon, Jul 12, 2021 at 11:06:01AM +0100, Philip Herron wrote:
>> Great work once again. I am aiming to spend some time towards the = end of
>> the week to add more tickets and info for new contributors to get<= br> >> involved, which I will post the interesting ones onto the mailing = list
>> as well. I think it should be interesting to contributors of all l= evels.
>> The main one that sticks out in my mind is the AST, HIR dumps whic= h are
>> a bit of a mess at the moment.
> The AST dump (--rust-dump-parse) was actually useful for checking the<= br> > comment doc strings, but it could certainly be improved. Ideally it > would be structured in a way that can easily be used in tests.
I think a really good project would be to update our HIR dump, it should really be an S-expression format so we can emit the
Analysis::NodeMapping information in a way that looks good at the moment its a mess.
> Some (random) notes I made on issues that might be nice to explain
> and/or work on.
>
> - Full unicode/utf8 support in the lexer. Currently the lexer only
>=C2=A0 =C2=A0explicitly interprets the input as UTF8 for string parsein= g. It
>=C2=A0 =C2=A0should really treat all input as UTF-8. gnulib has some ha= ndy
>=C2=A0 =C2=A0modules we could use to read/convert from/to utf8 (unistr/= u8-to-u32,
>=C2=A0 =C2=A0unistr/u32-to-u8) and test various unicode properties
>=C2=A0 =C2=A0(unictype/property-white-space, unictype/property-xid-cont= inue,
>=C2=A0 =C2=A0unictype/property-xid-start). I don't know if we can i= mport those or
>=C2=A0 =C2=A0if gcc already has these kind of UTF-8/unicode support fun= ctions for
>=C2=A0 =C2=A0other languages?
GCCGO supports utf-8 formats for identifiers but I think it has its own
implementation to do this. I think pulling in gnulib sounds like a good
idea, i assume we should ask about this on the GCC mailing list but I
would prefer to reuse a library for utf8 support. The piece about
creating the strings in GENERIC will need updated as part of that work.
> - Error handling using rich locations in the lexer and parser.=C2=A0 I= t
>=C2=A0 =C2=A0seems some support is already there, but it isn't tota= lly clear to
>=C2=A0 =C2=A0me what is already in place and what could/should be added= . e.g. how
>=C2=A0 =C2=A0to add notes to an Error.
I've made a wrapper over RichLocation i had some crashes when i added methods for annotations. Overall my understanding is that a Location
that we have at the moment is a single character location in the source
code but Rustc uses Spans which might be an abstraction we could think
about implementing instead of the Location wrapper we are reusing for
GCCGO.
> - I noticed some expressions didn't parse because of what looks to= me
>=C2=A0 =C2=A0operator precedence issues. e.g the following:
>
>=C2=A0 =C2=A0const S: usize =3D 64;
>
>=C2=A0 =C2=A0pub fn main ()
>=C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0let a:u8 =3D 1;
>=C2=A0 =C2=A0 =C2=A0let b:u8 =3D 2;
>=C2=A0 =C2=A0 =C2=A0let _c =3D S * a as usize + b as usize;
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0$ gcc/gccrs -Bgcc as.rs
>
>=C2=A0 =C2=A0as.rs:7:27: error: type param bounds (in TraitObjectType) = are not allowed as TypeNoBounds
>=C2=A0 =C2=A0 =C2=A07 |=C2=A0 =C2=A0let _c =3D S * a as usize + b as us= ize;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
>
>=C2=A0 =C2=A0How does one fix such operator precedence issues in the pa= rser?

Off the top of my head it looks as though the parse_type_cast_expr has a FIXME for the precedence issue for it. The Pratt parser uses the notion
of binding powers to handle this and i think it needs to follow in a
similar style to the ::parse_expr piece.

> - Related, TypeCastExpr as the above aren't lowered from AST to HI= R.
>=C2=A0 =C2=A0I believe I know how to do it, but a small description of = the visitor
>=C2=A0 =C2=A0pattern used and in which files one does such lowering wou= ld be helpful.
The AST->HIR lowering does need some documentation, since it must go
through name-resolution first but there is no documentation on how any
of this works yet. I will put this on my todo list its come up a few
times the naming of some of the classes like ResolveItemToplevel vs
ResolveItem are confusing things. Some of this will get cleaned up as
part of traits, such as the forward declared items within a block bug:

Basically the idea is that we always perform a toplevel scan for all
items and create long canonical names in the top most scope, such that
we can resolve their names at any point without requiring prototypes or
look ahead. This means we have a pass to look for the names then we have a pass to then resolve each structures fields, functions parameters,
returns types and blocks of code. So if a block calls to a function
declared ahead we can still resolve it to its NodeId. It is when we
ResolveItem we push new contexts onto the stack to have lexical scoping
for names. Its worth noting that Rust also supports shadowing of
variables within a block so these do not cause a duplicate name error
and simply add a new declaration to that context or what rustc calls
Ribs such that further resolution will reference this new declaration
and the previous one is shadowed correctly.

> - And of course, how to lower HIR to GENERIC?=C2=A0 For TypeCastExpr y= ou
>=C2=A0 =C2=A0said on irc we need traits first, but the semantics for pr= imitive
>=C2=A0 =C2=A0types is actually spelled out in The Reference. Can we alr= eady
>=C2=A0 =C2=A0handle them for primitive types (like in the above example= having an
>=C2=A0 =C2=A0u8 as usize)?
Lowering HIR to GENERIC documentation is on my todo list as well, though there are a bunch of cleanups I have in progress which should also help
here.
> - rust-macro-expand tries to handle both macros and attributes, is
>=C2=A0 =C2=A0this by design?=C2=A0 Should we handle different passes fo= r different
>=C2=A0 =C2=A0(inert or not) attributes that run before or after macro e= xpansion?
As for macro and cfg expansion Joel some stuff already in place but i do think they need to be separated into distinct passes which would be a
good first start with the expand folder.
>
> Cheers,
>
> Mark
>
Great summary mail i think this sums up a lot of the common issues. Note I added in Joel who wrote the parser he might be to provide more insight.
I added some comments inline to each point. I think i can take away from this that we are missing some useful pieces of architecture
documentation which is becoming important. I think it will be easier for me to get this done in a few weeks as there are changes in the areas
referenced which will affect the documentation.

Overall I do really like the visitor pattern for this work since it is
isolating the code for each AST or HIR node but it is more difficult to
follow the flow of the pipeline.

Sorry this does not contain all of the answers yet but I will work on
them. Thanks

--Phil












--000000000000a2b45905c7527b45--