From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 5BFC8385503E for ; Mon, 12 Jul 2021 22:44:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5BFC8385503E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x18.wildebeest.org [172.31.17.154]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 7178E300064F; Tue, 13 Jul 2021 00:44:14 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 031632E80578; Tue, 13 Jul 2021 00:44:13 +0200 (CEST) Date: Tue, 13 Jul 2021 00:44:13 +0200 From: Mark Wielaard To: Philip Herron Cc: gcc-rust@gcc.gnu.org Subject: New contributor tasks Message-ID: References: <20210711201018.389798-1-mark@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, 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: Mon, 12 Jul 2021 22:44:19 -0000 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. 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? - 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 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? - 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. - 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)? - 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? Cheers, Mark