Re: debian-i386 target (Was: ppc64le added to buildbot)

Hi Philip, On Wed, Jun 02, 2021 at 11:22:43AM +0100, Philip Herron wrote: > > Analyzing compilation unit > > /home/mark/gccrs/gcc/testsuite/rust.test/compile/methods1.rs: In function > > ‘Rectangle_sum_x’: > > /home/mark/gccrs/gcc/testsuite/rust.test/compile/methods1.rs:26:5: error: > > type misma

Re: Test results for gccrs on Debian unstable aarch64

On Thu, Jun 03, 2021 at 12:58:46PM +0100, Philip Herron wrote: > I just had a thought it would be nice if we could keep a matrix of > different platforms gccrs has been tested on, and they could have states of: > > 1. Build Failure > 2. Test Failures link to log > 3. Tests pass, no unexpected resu

[PATCH] Use PRIx64 to print 64bit hex values in legacy_hash

* gcc/rust/backend/rust-compile.cc (legacy_hash): lo and hi are uint64_t use PRIx64 to print them as hex values instead of %lx which is target specific. --- gcc/rust/backend/rust-compile.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/rust/backend/rust-

Re: Test results for gccrs on Debian unstable aarch64

Hi, On Thu, Jun 03, 2021 at 09:05:22PM +0200, Mark Wielaard wrote: > Currently I have only enabled the arches that I know are fully green > (x86_64, arm64 and ppc64le). I should add ppc64[be] because that > should also be fully green. fedora-ppc64 is enabled now t

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi, On Sat, Jun 12, 2021 at 11:38:01PM +, build...@builder.wildebeest.org wrote: > The Buildbot has detected a new failure on builder gccrust-debian-arm64 while > building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/58/builds/45 > > Build

Re: Buildbot failure in Wildebeest Builder on whole buildset

On Fri, 2021-06-18 at 11:06 +, build...@builder.wildebeest.org wrote: > The Buildbot has detected a new failure on builder gccrust-fedora- > ppc64 while building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/61/builds/40 > > Buildbot URL: htt

tuple indexes

Hi, I was looking into https://github.com/Rust-GCC/gccrs/issues/511 "rust has two kinds of integer literal" Which explains that integer literals used for a tuple index are not general integer literals. First I wanted to write some tests, and started with some constructs that should pass. But some

Re: tuple indexes

oof the parser now handles them. See attached. Cheers, Mark From a1d03b5182f7e2b16b5201459c98b33a12775888 Mon Sep 17 00:00:00 2001 From: Mark Wielaard Date: Wed, 23 Jun 2021 17:59:30 +0200 Subject: [PATCH] Handle empty/unit tuple structs in the parser. A tuple struct can be empty, in which case

Re: tuple indexes

On Wed, Jun 23, 2021 at 12:51:34AM +0200, Mark Wielaard wrote: > Finally, the The Rust Reference says "A tuple index is used to refer > to the fields of tuples, tuple structs, and tuple variants." I don't > understand how this would work for tuple variants. Does anybody hav

[PATCH] Reject non-pure decimal tuple indexes.

Tuple indexes should be pure decimal integer literals. But the parser just sees an integer literal. Fix this by introducing a new type hint CORETYPE_PURE_DECIMAL. This doesn't conflict with any existing type hints since a pure decimal doesn't have a type suffix. Introduce a new method is_pure_d

Re: [PATCH] Reject non-pure decimal tuple indexes.

Hi, Attached is a slightly updated version for some whitespace issues. There are spaces after the std::get and the is_pure_decimal function is now fully on one line. Cheers, Mark >From 60cb8cc43b91ff8a00be45be1106f95f161e9c8d Mon Sep 17 00:00:00 2001 From: Mark Wielaard Date: Fri, 25 Jun 2

[PATCH] Fix inner attribute parsing

parse_inner_attribute tried to skip the right square token twice. This caused odd error messages in case there were multiple inner attributes. This bug masked another bug in parse_attr_input where when the (optional) attr input was an assignment to a literal the parser failed to skip the literal

[PATCH] Suppress warning in rust-ast-lower-type.h ASTLowerGenericParam.visit.

Translating the AST LifetimeType to the HIR LifetimeType causes a warning: warning: ‘ltt’ may be used uninitialized Add a default clause to the switch statement calling gcc_unreachable. This will suppress the warning and make sure that if the AST lifetime type is invalid or a new unknown type we i

Re: [PATCH] Suppress warning in rust-ast-lower-type.h ASTLowerGenericParam.visit.

On Tue, Jun 29, 2021 at 12:06:56AM +0200, Marc wrote: > Hi, > > > Translating the AST LifetimeType to the HIR LifetimeType causes a warning: > > warning: ‘ltt’ may be used uninitialized > > Was wondering why this is needed as the switch case covers all enum > variants, how can ltt be uninitialize

Re: [PATCH] Suppress warning in rust-ast-lower-type.h ASTLowerGenericParam.visit.

On Tue, Jun 29, 2021 at 12:47:07AM +0200, Mark Wielaard wrote: > On Tue, Jun 29, 2021 at 12:06:56AM +0200, Marc wrote: > > Hi, > > > > > Translating the AST LifetimeType to the HIR LifetimeType causes a warning: > > > warning: ‘ltt’ may be used uninitialized &

Re: [PATCH] Suppress warning in rust-ast-lower-type.h ASTLowerGenericParam.visit.

Hi Marc, On Tue, Jun 29, 2021 at 08:28:51AM +0200, Marc wrote: > Mark Wielaard writes: > > I just tried to make LifetimeType an enum class and that doesn't help. > > So I was wrong. I don't know why the compiler doesn't see this? It > > should know since

[PATCH 2/2] Remove unused have_more_segments from TypeCheckExpr::resolve_root_path

It isn't necessary to know whether there are more segments while iteration through the expression segements. --- gcc/rust/typecheck/rust-hir-type-check-expr.h | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/rust/typecheck/rust-hir-type-check-expr.h b/gcc/rust/typecheck/rust-hir-type-check-

[PATCH 1/2] Remove unused default_ty_param from TypeResolveGenericParam::visit

The default_ty_param was set, but not used. We do need to call TypeCheckType::Resolve on the default param, but don't need the result. --- gcc/rust/typecheck/rust-hir-type-check-type.h | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/gcc/rust/typecheck/rust-hir-type-check

shebang handling

Hi, Shebang handling, the first line starting with #! was not done fully correct and it isn't necessary to keep track of the shebang line in the AST or HIR Crate classes. Because an inner attribute also starts with #! the first line isn't regarded as a shebang line if the #! is followed by (optio

[PATCH 1/2] Handle shebang line, plus any whitespace and comment skipping in lexer

The lexer tried to handle the shebang line but used loc directly, instead of the current_column. And it assumed a '/' should immediately follow the "#!". But if the "#!" is followed by whitespace and/or comments and a '[' character, then the first line isn't see as a shebang line (even if the kerne

[PATCH 2/2] Remove has_shebang flag from AST and HIR Crate classes

The lexer deals with the shebang and the parser cannot detect whether there is or isn't a shebang line. The flag isn't relevant or useful in the AST and HIR Crate classes. --- gcc/rust/ast/rust-ast-full-test.cc | 5 + gcc/rust/ast/rust-ast.h | 13 + gcc/rust/h

UTF-8 BOM handling

Hi, A rust source file can start with a UTF-8 BOM sequence (EF BB BF). This simply indicates that the file is encoded as UTF-8 (all rust input is interpreted as asequence of Unicode code points encoded in UTF-8) so can be skipped before starting real lexing. It isn't necessary to keep track of th

[PATCH 1/2] Handle UTF-8 BOM in lexer

The very first thing in a rust source file might be the optional UTF-8 BOM. This is the 3 bytes 0xEF 0xBB 0xBF. They can simply be skipped, they just mark the file as UTF-8. Add some testcases to show we now handle such files. --- gcc/rust/lex/rust-lex.cc| 13

[PATCH 2/2] Remove has_utf8bom flag from AST and HIR Crate classes

The lexer deals with the UTF-8 BOM and the parser cannot detect whether there is or isn't a BOM at the start of a file. The flag isn't relevant or useful in the AST and HIR Crate classes. --- gcc/rust/ast/rust-ast-full-test.cc | 3 --- gcc/rust/ast/rust-ast.h | 11 +++

[PATCH] Handle doc comment strings in lexer and parser

Remove (unused) comment related tokens and replace them with INNER_DOC_COMMENT and OUTER_DOC_COMMENT tokens, which keep the comment text as a string. These can be constructed with the new make_inner_doc_comment and make_outer_doc_comment methods. Make sure to not confuse doc strings with normal co

[PATCH] Remove HIR MacroItem and other hir macro forward declarations

Almost all HIR Macro related trees were already removed by https://github.com/Rust-GCC/gccrs/pull/492 But there was still one MacroItem class left in rust-hir.h and several (unused) forward declarations in various other hir .h files. Remove them all. Resolves: https://github.com/Rust-GCC/gccrs/is

Re: [PATCH] Handle doc comment strings in lexer and parser

6ff97de60de0: Merge #551 (2021-07-10 21:02:06 +) are available in the Git repository at: https://code.wildebeest.org/git/user/mjw/gccrs doc-comments for you to fetch changes up to e1e14958a90397a1ed6ab7236dc5a6f1c2f22505: Handle doc comment strings in lexer and parser (2021-07-11 21:09:21 +0200) ---

New contributor tasks

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 i

Re: Fwd: New contributor tasks

Hi Joel, On Sat, Jul 17, 2021 at 10:25:48PM +0800, The Other wrote: > > - 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 coul

rust frontend and UTF-8/unicode processing/properties

Hi, For the gcc rust frontend I was thinking of importing a couple of gnulib modules to help with UTF-8 processing, conversion to/from unicode codepoints and determining various properties of those codepoints. But it seems gcc doesn't yet have any gnulib modules imported, and maybe other frontends

Re: Fwd: New contributor tasks

), + std::unique_ptr (type_to_cast_to), expr.get_locus ()); + } + /* Compound assignment expression is compiled away. */ void visit (AST::CompoundAssignmentExpr &expr) override { It does get us a little bit further into the type checker: as2.rs:7:12: error: failed to type resolve e

Using unsafe blocks in let expressions

et the correct location. Cheers, Mark>From 3e9c4eff383cd1a23a148f5a7d556345b7972e26 Mon Sep 17 00:00:00 2001 From: Mark Wielaard Date: Wed, 21 Jul 2021 22:41:04 +0200 Subject: [PATCH] unsafe blocks can be used in expressions To use an unsafe block expression handle it in null_deno

Re: Using unsafe blocks in let expressions

On Wed, Jul 21, 2021 at 11:09:38PM +0200, Mark Wielaard wrote: > + Location locus; > + if (!pratt_parse) > +{ > + Location locus = lexer.peek_token ()->get_locus (); Oops, shadowed locus. Fixed patch attached, and also at https://code.wildebeest.org/git/user/mjw/gccr

union support

Hi, I have been playing with union support which was mostly missing. union is slightly odd because it is a weak keyword, so it can be used as a "normal" identifier and is only special when defining a union type. Which means you can have programs like: union union { union: u32, funion: f32 } pub f

[PATCH 1/2] Better union support in the parser

union is a weak keyword which means it isn't reserved and can be used as a generic identifier. When we see an identifier where a union could be declared we check whether the identifier is "union", but only when the next token is also an identifier. In parse_union we shouldn't skip the first identif

[PATCH 2/2] WIP union hir-lowering and type support

Treat a union as a Struct variant like a tuple struct. Add an iterator and get_identifier functions to the AST Union class. Same for the HIR Union class, plus a get_generics_params method. Add a get_is_union method tot the ADTType. --- gcc/rust/ast/rust-item.h | 11 gcc

[PATCH] Support byte and byte string literals

A byte literal is an u8 created as a ascii char or hex escape e.g. b'X'. A byte string literal is a string created from ascii or hex chars. bytes are represented as u8 and byte strings as str (with just ascii < 256 chars), but it should really be &'static [u8; n]. --- gcc/rust/backend/rust-compil

[PATCH] Support RangeFrom ([x..]) and RangeFromTo ([x..y]) in the parser

Parsing the .. (DOT_DOT) operator to get a range had two issues. Trying to compile: let block = [1,2,3,4,5]; let _rf = &block[1..]; let _rt = &block[..3]; let _rft = &block[2..4]; range.rs:4:23: error: found unexpected token ‘]’ in null denotation 4 | let _rf = &block[1..]; |

[PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

The pratt parser skips the first token of an expression before invoking the actual expression parsing function. This makes getting the correct starting location of a pratt parsed expression hard. The "correction" of the location by subtracting an integer is often wrong (since there may be arbitrary

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

Hi Joel, On Thu, 2021-07-29 at 09:25 +0800, The Other via Gcc-rust wrote: > I think the core idea of this patch (fixing locations) is very > important and useful. > > But isn’t it overkill to pass the token in instead of just the > location? You can avoid a fairly expensive shared_ptr copy by doi

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

Hi, On Thu, Jul 29, 2021 at 05:18:50PM +0200, Thomas Schwinge wrote: > On 2021-07-29T12:55:38+0200, Mark Wielaard wrote: > > On Thu, 2021-07-29 at 09:25 +0800, The Other via Gcc-rust wrote: > >> But isn’t it overkill to pass the token in instead of just the > >> locat

Re: [PATCH 2/2] WIP union hir-lowering and type support

Hi Philip, On Fri, Jul 23, 2021 at 12:19:18PM +0100, Philip Herron wrote: > On 23/07/2021 00:19, Mark Wielaard wrote: > > Treat a union as a Struct variant like a tuple struct. Add an > > iterator and get_identifier functions to the AST Union class. Same > > for the HI

Re: [PATCH 2/2] WIP union hir-lowering and type support

On Sun, Aug 01, 2021 at 01:29:16PM +0200, Mark Wielaard wrote: > I added two simple testcases to show the basic support for unions > works now. But there are a couple of things that don't work correctly > for unions yet. In particular when enabling warnings for the new > union.r

[PATCH] Remove split-stack from backend

The backend was derived from the go backend which enables split stack support by default. This inserts a __morestack call at the start of each function. This is not needed for the rust backend. Remove the split stack support code from the rust backend and spec. --- gcc/rust/rust-backend.h | 12 +++

[PATCH] Always check the result of expect_token while parsing

When expect_token fails it produces an error and return a nullptr. Make sure to always check the result of expect_token so we don't use a nullptr token and crash. Resolves: https://github.com/Rust-GCC/gccrs/issues/603 --- gcc/rust/parse/rust-parse-impl.h | 27 +++ 1 file c

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi, On Wed, Aug 04, 2021 at 03:15:00PM +, build...@builder.wildebeest.org wrote: > The Buildbot has detected a new failure on builder gccrust-debian-arm64 while > building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/58/builds/270 > > Buil

Re: [PATCH 2/2] WIP union hir-lowering and type support

Hi, On Sun, Aug 01, 2021 at 01:29:16PM +0200, Mark Wielaard wrote: > And you cannot use unions as function arguments or return values. > This example (sorry for the funny naming, union isn't a keyword, so > you can call basically anything a union, including a union, a union >

Modifying self

Hi, I am trying to get this program working: extern "C" { fn abort (); } pub struct H { l: u32, } impl H { fn p (&mut self) -> u32 { self.l -= 1; self.l } } fn main () { let mut h = H { l: 11 }; let eleven = h.l; let ten = h.p (); if ten + 1 != eleven { unsafe { abor

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

Hi, On Fri, Jul 30, 2021 at 03:03:13AM +0200, Mark Wielaard wrote: > That variant is attached and can also be found here: > https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=pass-pratt-parse-loc > The original is also here: > https://code.wildebeest.org/git/user/mjw/gccrs/co

[PATCH] More rustspec.cc cleanups

rustspec.cc was based on the Go frontend gospec.cc. Remove special handling of math and pthread libraries and profiling option. Handle .rs files instead of .go files. Keep support for linking with (static) librust which is currently commented out. Add generic static-librust option to common.opt. --

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi Philip, On Fri, Aug 06, 2021 at 03:31:07PM +0100, Philip Herron wrote: > > Is it possible to make bors check all commits in a series? Or can we > > somehow connect the buildbot workers to the bors checks? > > I think the build-bot checks for every commit is a really nice feature > here. I thin

Re: [PATCH] More rustspec.cc cleanups

Hi Philip, On Fri, Aug 06, 2021 at 03:58:24PM +0100, Philip Herron wrote: > Great patch, this file has been neglected. This is now being merged > https://github.com/Rust-GCC/gccrs/pull/610 > > Its not 100% clear but is the compiler driver here automatically adding > in -lc or is it simply checkin

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi Arthur, On Fri, Aug 06, 2021 at 05:55:09PM +0200, cohenarthur.dev via Gcc-rust wrote: > I'm really sorry about not having all the commits build. I tried to keep > them as atomic as possible and clearly didn't check all of them > separately. This could have been a single commit and would have av

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

On Fri, Aug 06, 2021 at 04:23:27PM +0100, Philip Herron wrote: > On 05/08/2021 20:37, Mark Wielaard wrote: > > Hi, > > > > On Fri, Jul 30, 2021 at 03:03:13AM +0200, Mark Wielaard wrote: > >> That variant is attached and can also be found here: > >> https:/

[PATCH] lex: accept zero codepoints in strings

Zero characters (codepoints) are acceptable in strings. The current Lexer::parse_string skipped such zero codepoints by accidents. The zero codepoint was also used as error/skip indicator, but that is only true if the third argument of utf8_escape_pair is true (yes, it is called pair, but is a trip

Re: Test results for gccrs on Debian unstable s390x

Hi! On Sun, Aug 08, 2021 at 09:03:44AM +0200, John Paul Adrian Glaubitz wrote: > On 6/2/21 9:48 PM, John Paul Adrian Glaubitz wrote: > > Just built gccrs revision 59b417323b25072aff2662f1f54f417f7b7ded61 on > > Debian unstable s390x. > > > > The testsuite fails with the following failures. Attac

Re: Buildbot failure in Wildebeest Builder on whole buildset

On Sun, Aug 08, 2021 at 12:51:47PM +0100, Philip Herron wrote: > I would be interested in seeing 32bit build bots since this patch has > been merged: https://github.com/Rust-GCC/gccrs/pull/614 > > Which thanks to Adrian who has been testing it out. > > Do you have access to 32bit machines? I have

Re: [PATCH] lex: accept zero codepoints in strings

debeest.org/git/user/mjw/gccrs/commit/?h=str-zero Cheers, Mark >From 007e6ecefb0b43d0b9e7bf85f75ec050b5c520e5 Mon Sep 17 00:00:00 2001 From: Mark Wielaard Date: Sat, 7 Aug 2021 17:32:41 +0200 Subject: [PATCH] lex: accept zero codepoints in strings Zero characters (codepoints) are accepta

Re: [PATCH] Pass pratt parsed token to expr parser functions to fix expr locus

Hi, On Sat, Aug 07, 2021 at 03:01:39AM +0200, Mark Wielaard wrote: > > Sorry for lack of reply on this. After looking into this and also > > getting Arthur Cohen to review, I think: > > > > * Token passing: If we end up using the token for more than the > >

[PATCH] parse if expression with unary minus or not expression

An if conditional expression doesn't need brackets, but that means that it doesn't accept struct expressions. Those are not easy to distinquish from the block that follows. What isn't immediately clear from the grammar is that unary conditions like minus '-' or not '!' also shouldn't accept struct

[PATCH] Use builtin bool instead of creating new bool types for ComparisonExpr

The TypeCheckExpr creates a new TyTy::BoolType for a ComparisonExpr. This new BoolType is unknown to TyTyResolveCompile which causes a crash when trying to compile the inferred new BoolType. The new "bools_eq.rs" testcase uses several bools which show this issue. Resolve this by looking up the buil

[PATCH] Suppress uninitialized candidate_type warning in process_traits_for_candidates

Without handling the default case in the switch statement gcc 10.2.1 will warn: rust-hir-path-probe.h:75:40: warning: ‘candidate_type’ may be used uninitialized in this function [-Wmaybe-uninitialized] --- gcc/rust/typecheck/rust-hir-path-probe.h | 1 + 1 file changed, 1 insertion(+) diff --gi

[PATCH] Add support for const bool and const float

Handle BOOL and FLOAT in ConstFoldExpr::visit (HIR::LiteralExpr) to make it possible to create const bool, f32 and f64 constants. Add a new testcase "primconsts.rs". Not yet handled are const char and &str types. --- gcc/rust/typecheck/rust-hir-const-fold.h | 30 .../rust/compile/tor

[PATCH] Use default type_for_size langhook

The gcc constant folding code uses the type_for_size langhook. Use the default implementation instead of crashing when the langhook is called. Add a new testcase "prims_struct_eq.rs" that creates trees that triggers the constant folding. Also remove the write_globals langhook which was removed whe

Re: [PATCH] Add support for const bool and const float

Hi Marc, On Mon, 2021-08-16 at 07:48 +, d...@kataplop.net wrote: > Looks like tests are not OK, at least in the github action. Are you talking about this patch (which I cannot find on github) or "Use builtin bool instead of creating new bool types for ComparisonExpr"? On github I can only see

[PATCH] Allow bool and char to be cast as any integer type

bools and chars can be cast to any integer type, but not to floats or each other. Adjust the BoolCastRule and CharCastRule to allow these casts. Add a postive test "as_bool_char.rs" and negative test "bad_as_bool_char.rs" to check the correct casts are accepted and the illegal casts produce errors.

Re: [PATCH] Add support for const bool and const float

Hi, On Mon, Aug 16, 2021 at 10:52:07AM +0200, Mark Wielaard wrote: > On Mon, 2021-08-16 at 07:48 +, d...@kataplop.net wrote: > > Looks like tests are not OK, at least in the github action. > > Are you talking about this patch (which I cannot find on github) or > "Use

Re: [PATCH] Add support for const bool and const float

Hi, On Mon, Aug 16, 2021 at 11:03:19PM +0200, Mark Wielaard wrote: > Now having replicated it locally the rust.log shows: > > /srv/gccrs/gccrs/gcc/testsuite/rust/compile/torture/ifunaryexpr.rs: In > function 'main': > /srv/gccrs/gccrs/gcc/testsuite/rust/compile/t

[PATCH] Reject duplicate field names in structs and unions.

Odd things happen if structs or unions have duplicate field names. Emit an error when lowering an struct/union item or declaration statement and a duplicate field name is detected. A new testcase 'dup_fields.rs' checks an error is actually produced. --- https://code.wildebeest.org/git/user/mjw/gc

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi, On Sun, Aug 22, 2021 at 03:55:47PM +, build...@builder.wildebeest.org wrote: > The Buildbot has detected a new failure on builder gccrust-debian-arm64 while > building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/58/builds/355 This see

[PATCH] Get rid of get_locus_slow

In various places there was the following hack: /* HACK: slow way of getting location from base expression through virtual methods. */ virtual Location get_locus_slow () const { return Location (); } The problem with get_locus_slow () is that if a subclass didn't override it then there w

Re: [PATCH] Get rid of get_locus_slow

On Thu, Aug 26, 2021 at 10:31:06AM +0800, The Other wrote: > The original point of the distinction between get_locus_slow() and > get_locus() was to avoid the overhead of virtual function calls > whenever possible, but still have a way to access locations from > abstract base classes like Expr. I

[PATCHv2] Get rid of get_locus_slow

In various places there was the following hack: /* HACK: slow way of getting location from base expression through virtual methods. */ virtual Location get_locus_slow () const { return Location (); } The problem with get_locus_slow () is that if a subclass didn't override it then there w

[PATCH 1/3] Use location when lowering TupleField

--- gcc/rust/hir/rust-ast-lower-stmt.h | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/gcc/rust/hir/rust-ast-lower-stmt.h b/gcc/rust/hir/rust-ast-lower-stmt.h index 1e72c8a2023..fdd5041d602 100644 --- a/gcc/rust/hir/rust-ast-lower-stmt.h +++ b/gcc/rust/hir/rust-ast-lower

[PATCH 2/3] Replace HIRItem::get_impl_locus with HirItem::get_locus

HIRItem::get_impl_locus wasn't used and all subclasses already implement get_locus. --- gcc/rust/hir/tree/rust-hir-item.h | 6 -- gcc/rust/hir/tree/rust-hir.h | 2 +- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/gcc/rust/hir/tree/rust-hir-item.h b/gcc/rust/hir/tree/rust-

A few more location patches

Hi, Here are a couple of little patches to improve or simplify locations a bit: [PATCH 1/3] Use location when lowering TupleField [PATCH 2/3] Replace HIRItem::get_impl_locus with HirItem::get_locus [PATCH 3/3] Remove GetLocusFromImplItem visitor Also on https://code.wildebeest.org/git/user/mj

[PATCH 3/3] Remove GetLocusFromImplItem visitor

Simply use get_locus () on the ImplItem. Both the generics7.rs and generics8.rs testcase still pass. --- .../rust-hir-inherent-impl-overlap.h | 45 +-- 1 file changed, 2 insertions(+), 43 deletions(-) diff --git a/gcc/rust/typecheck/rust-hir-inherent-impl-overlap.h b/gcc

Cleanup some StructExpr related classes

Hi, There are various Structure Expressions that don't actually "exist" because they are syntactically equivalent to other constructs. So we never really construct or use these classes. But they are still listed in various visitors, which is somewhat confusing. Removing the AST and HIR variants of

[PATCH 1/3] StructExprTuple doesn't really exist

A StructExprTuple is parsed as a CallExpr. Both (can) start with a PathInExpression followed by zero or more Expressions between brackets. Only, after type checking, when actually generating gcc generic trees is a distinction made between a function call or tuple constructor. Remove the AST and H

[PATCH 2/3] StructExprUnit doesn't really exist

A StructExprUnit is parsed as an IdentifierExpr. An IdentifierExpr, which is what we call a single segment PathInExpression. After type checking, when generating gcc generic trees, if the IdentifierExpr is a type reference (which must be a unit struct), then a unit expression is generated. Remove

[PATCH 3/3] Remove Enumaration Expression, EnumExpr, classes

An Enumaration Expression is just like a Struct Expression. Old versions of the Rust Reference described them separately. But since they are syntactically exactly like a Struct Expression they are never actually parsed. A Struct Expression can also be used to initialize enums (and unions). Remove

Re: Cleanup some StructExpr related classes

Hi, On Wed, Sep 01, 2021 at 11:11:46AM +0100, Philip Herron wrote: > This is fantastic work Mar. This brings us closer to the AST structures of > rustc and does simplify a lot of the analysis within the compiler. > https://doc.rust-lang.org/nightly/reference/expressions/struct-expr.html The refer

Re: Cleanup some StructExpr related classes

Hi Philip, On Thu, Sep 02, 2021 at 02:23:33PM +0100, Philip Herron wrote: > I've been reviewing your branch a bit and noticed this commit > https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=enums&id=84d27b926e09ef44dd94be20c97d72bd4b865c40 > which I really like. I wasn't sure what was the b

[PATCH 1/3] Parse optional visibility for enum item

Syntactically enum items can have a visibility. The visibility has to be removed (through a cfg attribute or macro) before they get lowered. The semantic checking will be done when we implement lowering enum items. Make the AST EnumItem class a VisItem. This simplifies things a little for cloning

[PATCH 2/3] Resolve Enums and EnumItems

Generate paths for Enum and EnumItem AST NodeIds and resolve the types of tuple and struct enum items. EnumItems always have the Enum as prefix. To make this work for ResolveStms (declaration statements are not given a canonical path) we add an enum_prefix to be used when resolving EnumItems. For

[PATCH 3/3] Add EnumItem HIR lowering

Make HIT EnumItem class an Item, not VisItem like in the AST. At the HIR level EnumItems shouldn't have visibility anymore. Move struct_field_name_exists to rust-ast-lower.cc with the declaration in rust-ast-lower.h to make it reusable in the different visitors. Add a new ASTLoweringEnumItem that

[PATCH] Remove warnings from v0_mangle functions in rust-mangle.cc

There were two warnings in rust-mangle.cc rust-mangle.cc: In function ‘std::string Rust::Compile::v0_mangle_item (const Rust::TyTy::BaseType*, const Rust::Resolver::CanonicalPath&, const string&)’: rust-mangle.cc:198:1: warning: no return statement in function returning non-void rust-mangle.cc:

Re: [PATCH] Remove warnings from v0_mangle functions in rust-mangle.cc

Hi Arthur, On Tue, 2021-09-21 at 13:58 +0200, cohenarthur.dev via Gcc-rust wrote: > I forgot to do a clean build before creating the pull request and the > file was already compiled... Sorry about that! > > I'll keep on working on v0 mangling in order to get all the parts > linked correctly, but

[PATCH] Fix byte char and byte string lexing code

There were two warnings in lexer parse_byte_char and parse_byte_string code for arches with signed chars: rust-lex.cc: In member function ‘Rust::TokenPtr Rust::Lexer::parse_byte_char(Location)’: rust-lex.cc:1564:21: warning: comparison is always false due to limited

Re: [PATCH] Fix byte char and byte string lexing code

Hi Thomas, On Wed, Sep 22, 2021 at 11:48:56AM +0200, Thomas Schwinge wrote: > That's . > [...] > That's . Ah, sorry, I don't really track the github issues and had missed those. But good to see the analysis m

byte/char string representation (Was: [PATCH] Fix byte char and byte string lexing code)

On Thu, Sep 23, 2021 at 04:10:59PM +0200, Arthur Cohen wrote: > > Something I was thinking about outside of the scope of that patch was > about the utf8 how do they get represented? Is it some kind of wchar_t? > > Do you mean in C++ or in rustc? In rustc, they are represented as Unicode > Scalar V

Re: Merge from GCC upstream into GCC/Rust

Hi Thomas, On Fri, Sep 24, 2021 at 10:30:15AM +0200, Thomas Schwinge wrote: > I'm preparing a merge from GCC upstream into GCC/Rust. This is normally > pretty unexciting ;-) -- the exception being, as once mentioned in > : Than

Re: byte/char string representation (Was: [PATCH] Fix byte char and byte string lexing code)

Hi Philip, On Fri, Sep 24, 2021 at 12:01:42PM +0100, Philip Herron wrote: > This is really useful information, will this mean that the lexer token will > need to represent strings differently as well? Or is the std::string in the > lexer still ok? I think the respresentation as std::string is fin

Re: Buildbot failure in Wildebeest Builder on whole buildset

On Sat, Sep 25, 2021 at 12:04:01PM +, build...@builder.wildebeest.org wrote: > The Buildbot has detected a new failure on builder gccrust-debian-arm64 while > building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/58/builds/469 O fun. I hadn

[PATCH] Remove raw string and raw byte string references from ast and hir

Raw strings and raw byte strings are simply different ways to create string and byte string literals. Only the lexer cares how those literals are constructed and which escapes are used to construct them. The parser and hir simply see strings or byte strings. --- https://code.wildebeest.org/git/use

[no subject]

>From e6e1cc117e1f08dfde86f5a3b1988e4b7206a7da Mon Sep 17 00:00:00 2001 From: Mark Wielaard Date: Wed, 29 Sep 2021 22:03:34 +0200 Subject: [PATCH] Fix raw byte string parsing of zero and out of range bytes Allow \0 escape in raw byte string and reject non-ascii byte values. Cha

[PATCH] Fix raw byte string parsing of zero and out of range bytes

Allow \0 escape in raw byte string and reject non-ascii byte values. Change parse_partial_hex_escapes to not skip bad characters to provide better error messages. Add rawbytestring.rs testcase to check string, raw string, byte string and raw byte string parsing. --- https://code.wildebeest.org/gi

[PATCH] Fix lexer to not produce bad unicode escape values

There were a couple of issues in the lexer unicode escape code. Unicode escape sequences must always start with an opening curly bracket (and end with a closing one). Underscores are not allowed as starting character. And the produced values must be unicode scalar values, which excludes surrogate v

Re: byte/char string representation (Was: [PATCH] Fix byte char and byte string lexing code)

Hi Philip, On Thu, Sep 30, 2021 at 11:46:30AM +0100, Philip Herron wrote: > Your patch was 99% of the way there to fix the type > resolution so I finished it off for you: > > https://github.com/Rust-GCC/gccrs/pull/698/files And you added the actual backend code needed! So I'll probably say I was

Re: Buildbot failure in Wildebeest Builder on whole buildset

Hi, On Fri, 2021-11-05 at 13:49 +, build...@builder.wildebeest.org wrote: > The Buildbot has detected a new failure on builder gccrust-fedora- > s390x while building gccrust. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/63/builds/1072 > > Buildbot U

  1   2   >