Re: [PATCH Rust front-end v2 09/37] gccrs: Add Lexer for Rust front-end

[Jakub Jelinek via Gcc-rust]

On Wed, Sep 14, 2022 at 03:30:39PM +0200, Richard Biener via Gcc-patches wrote:
> > +// GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> > +// WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > +// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> > +// for more details.
> > +
> > +// You should have received a copy of the GNU General Public License
> > +// along with GCC; see the file COPYING3.  If not see
> > +// .
> > +
> > +#include "rust-lex.h"
> > +
> > +#include "rust-system.h"  // for rust_assert and rust_unreachable
> > +#include "rust-diagnostics.h" // for rust_error_at
> > +#include "rust-linemap.h"
> > +#include "rust-session-manager.h"
> > +#include "safe-ctype.h"
> 
> just diving into a random patch here - I'm assuming I can take rust-lex.cc as
> a boiler-plate example for the #include structure.
> 
> In GCC all files should start with #including "config.h" followed by
> "system.h" where _all_ system, including C++ standard library headers
> should be pulled via system.h to allow working around OS and system
> compiler issues.
> 
> It might be that rust-system.h plays the role of config.h + system.h
> but then the rust-lex.h include is before it.
> 
> rust-codepoint.h including  is also problematic btw.

E.g. the Go FE has two parts, one very GCC specific that uses the explicit
config.h + system.h etc. includes, the other is generic and there it
includes go-system.h in every file first, where that starts with
#include 

various C++ standard includes

#include 
etc.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v2 07/37] gccrs: Add gcc-check-target check-rust

[Jakub Jelinek via Gcc-rust]

On Wed, Sep 14, 2022 at 03:41:48PM +0200, Richard Biener via Gcc-patches wrote:
> On Wed, Aug 24, 2022 at 2:08 PM  wrote:
> >
> > From: Philip Herron 
> >
> > This allows us to invoke the rust testsuite.
> 
> OK.
> 
> >
> > ChangeLog:
> > * Makefile.def: Add autogen target
> > * Makefile.in: regenerate via autogen

The changelog doesn't match what the patch does (Add rust language.
and Regenerate.), plus missing . at the end and in one case capital
letter after :

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust front-end

[Jakub Jelinek via Gcc-rust]

On Tue, Oct 04, 2022 at 08:42:58AM -0400, David Malcolm via Gcc wrote:
> On Tue, 2022-10-04 at 13:29 +0100, Philip Herron wrote:
> > Hi everyone,
> > 
> > As the cut-off for merging is coming up in November, quite a few of
> > our patches have not been reviewed yet.
> > 
> > There are a few main issues that have been raised so far, and we are
> > fixing those at the moment in preparation for version 3 of the
> > patches. Is there anything else we can do to make reviewing the rest
> > of the patches easier?
> 
> Do you have a list of which patches need reviewing?
> e.g. perhaps a page showing:
> - which patches are waiting for a reviewer, as opposed to
> - which patches are already approved
> - which patches have issues identified in review
>   - ...where no-one is yet working on addressing them
>   - ...where someone is working on addressing them
> etc
> 
> to make it clearer what the next action is for each patch, and who is
> meant to be taking it.
> 
> (within Red Hat, we used to call this "who has the ball?")

Yeah, our policy in https://gcc.gnu.org/contribute.html states that
"Pinging patches, Getting patches applied

If you do not receive a response to a patch that you have submitted within
two weeks or so, it may be a good idea to chase it by sending a follow-up
e-mail to the same list(s).  Patches can occasionally fall through the
cracks.  Please be sure to include a brief summary of the patch and the URL
of the entry in the mailing list archive of the original submission."

If some patches have been already reviewed, others partly, others in the
works and others need review, sending a mail with those details
so that it is easy to find out what is still pending is appreciated even
more.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char' type

[Jakub Jelinek via Gcc-rust]

On Wed, Oct 26, 2022 at 10:17:26AM +0200, arthur.co...@embecosm.com wrote:
> @@ -25201,6 +25215,13 @@ gen_compile_unit_die (const char *filename)
>  }
>else if (strcmp (language_string, "GNU F77") == 0)
>  language = DW_LANG_Fortran77;
> +  else if (strcmp (language_string, "GNU Rust") == 0)
> +{
> +  if (dwarf_version >= 5 || !dwarf_strict)
> + language = DW_LANG_Rust;
> +  else
> + language = DW_LANG_Rust_old;
> +}

I must say I don't understand nor like this DW_LANG_Rust_old stuff at all.
Other languages don't do similar dances.
Look for D, or Go.  Neither of them has any non-standard lang code as
fallback, they use the DWARF assigned DW_LANG_* code, and DW_LANG_C as
fallback.  On most arches, DWARF 5 is the default anyway, or non-strict
DWARF at least.  Where neither is enabled because of prehistoric or buggy
DWARF consumers, it is unlikely they'd handle Rust sanely anyway.
Just follow what Go does in the same function.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char' type

[Jakub Jelinek via Gcc-rust]

On Sun, Oct 30, 2022 at 04:22:34PM +0100, Mark Wielaard wrote:
> Hi,
> 
> On Wed, Oct 26, 2022 at 10:39:09AM +0200, Jakub Jelinek wrote:
> > I must say I don't understand nor like this DW_LANG_Rust_old stuff at all.
> > Other languages don't do similar dances.
> > Look for D, or Go.  Neither of them has any non-standard lang code as
> > fallback, they use the DWARF assigned DW_LANG_* code, and DW_LANG_C as
> > fallback.  On most arches, DWARF 5 is the default anyway, or non-strict
> > DWARF at least.  Where neither is enabled because of prehistoric or buggy
> > DWARF consumers, it is unlikely they'd handle Rust sanely anyway.
> > Just follow what Go does in the same function.
> 
> DW_LANG_Rust_old was used by old rustc compilers <= 2016 before DWARF5
> assigned an official number. It might be recognized by some
> debuggers. But I agree that these days it doesn't really make sense to
> emit it. When producing strict DWARF it is also slightly odd to emit a
> non-standard language code. So I agree that it makes sense to do what
> Go does, always emit DW_LANG_Rust unless we emit strict DWARF for
> versions before 5 (and then just fall back to DW_LANG_C).
> 
> The attached patch (against "upstream gccrs") does that. I kept the
> oldlang.rs testcase just to see that the -gstrict-dwarf -gdwarf-3 case
> does something sane.
> 
> The only "issue" is that is_rust () depends on the comp_unit_die
> DW_AT_language being DW_LANG_Rust. But the only usage of is_rust
> already depends on strict DWARF.
> 
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=no-Rust-old
> if someone wants to push that, to merge for a v4.

LGTM, thanks.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[PATCH] rust: Fix up aarch64-linux bootstrap [PR106072]

[Jakub Jelinek via Gcc-rust]

Hi!

Bootstrap fails on aarch64-linux and some other arches with:
.../gcc/rust/parse/rust-parse-impl.h: In member function 
‘Rust::AST::ClosureParam 
Rust::Parser::parse_closure_param() [with 
ManagedTokenSource = Rust::Lexer]’:
.../gcc/rust/parse/rust-parse-impl.h:8916:49: error: ‘this’ pointer is null 
[-Werror=nonnull]
The problem is that while say on x86_64-linux the side-effects in the
arguments are evaluated from last argument to first, on aarch64-linux
it is the other way around, from first to last.  The C++ I believe even
in C++17 makes the evaluation of those side-effects unordered
(indeterminately sequenced with no interleaving), so that is fine.
But, when the call in return statement is evaluated from first to
last, std::move (pattern) happens before pattern->get_locus () and
the former will make pattern (std::unique_ptr) a wrapper object around
nullptr, so dereferencing it later to call get_locus () on it is invalid.

The following patch fixes that, ok for trunk?

2022-12-14  Jakub Jelinek  

PR rust/106072
* parse/rust-parse-impl.h (parse_closure_param): Store
pattern->get_locus () in a temporary before std::move (pattern) is
invoked.

--- gcc/rust/parse/rust-parse-impl.h.jj 2022-12-13 16:50:12.708093521 +0100
+++ gcc/rust/parse/rust-parse-impl.h2022-12-14 09:50:31.73932 +0100
@@ -8912,8 +8912,9 @@ Parser::parse_closur
}
 }
 
-  return AST::ClosureParam (std::move (pattern), pattern->get_locus (),
-   std::move (type), std::move (outer_attrs));
+  Location loc = pattern->get_locus ();
+  return AST::ClosureParam (std::move (pattern), loc, std::move (type),
+   std::move (outer_attrs));
 }
 
 // Parses a grouped or tuple expression (disambiguates).

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)

[Jakub Jelinek via Gcc-rust]

On Thu, Dec 15, 2022 at 11:14:10AM +0100, Thomas Schwinge wrote:
> Hi!
> 
> On 2022-12-15T08:53:13+0100, Richard Biener  
> wrote:
> > On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
> >  wrote:
> >> On 2022-12-13T14:40:36+0100, Arthur Cohen  
> >> wrote:
> >> > We've also added one more commit, which only affects files inside the
> >> > Rust front-end folder. This commit adds an experimental flag, which
> >> > blocks the compilation of Rust code when not used.
> >>
> >> (That's commit r13-4675-gb07ef39ffbf4e77a586605019c64e2e070915ac3
> >> "gccrs: Add fatal_error when experimental flag is not present".)
> >>
> >> I noticed that GCC/Rust recently lost all LTO variants in torture
> >> testing -- due to this commit.  :-O
> >>
> >> OK to push the attached
> >> "Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' 
> >> option",
> >> or should this be done differently?
> >
> > Just add 'LTO' to the option in lang.opt, like
> >
> > frust-incomplete-and-experimental-compiler-do-not-use
> > Rust LTO Var(flag_rust_experimental)
> > Enable experimental compilation of Rust files at your own risk
> 
> That doesn't work; it's 'cc1' that is complaining here.

In that case it is a testsuite issue.
I really think making such Rust option a common option is very much
undesirable.

We seem to have a problem in other testsuites too:
grep ' valid for .*but not for' */*.log | sort -u
gcc/gcc.log:/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pragma-diag-6.c:2:30: 
warning: option '-Wnoexcept' is valid for C++/ObjC++ but not for C [-Wpragmas]
gdc/gdc.log:cc1plus: warning: command-line option '-fextern-std=c++11' is valid 
for D but not for C++
gdc/gdc.log:cc1plus: warning: command-line option '-fpreview=in' is valid for D 
but not for C++
gfortran/gfortran.log:cc1: warning: command-line option '-fcheck=all' is valid 
for Fortran but not for C
g++/g++.log:cc1: warning: command-line option '-nostdinc++' is valid for 
C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++11' is valid for 
C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++14' is valid for 
C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++17' is valid for 
C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++20' is valid for 
C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++23' is valid for 
C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++98' is valid for 
C++/ObjC++ but not for C
rust/rust.log:cc1plus: warning: command-line option 
'-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but 
not for C++
rust/rust.log:cc1: warning: command-line option 
'-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but 
not for C
(of course, some of them could be from tests that this valid for but not for
messages work right, that is clearly the case of pragma-diag-6.c).

In gcc/testsuite/lib/target-supports.exp (check_compile) we already
determine extension for the check_compile snippet based on magic comments
with default to .c (Rust nor Modula 2 don't have any, should that be
changed?), shouldn't we at that point based on the language filter out
known options that will not work?

So, given the above, at least when in gdc testsuite and language is
not D filter out -fextern-std=* and -fpreview=in, for gfortran testsuite
and language not Fortran filter out -fcheck=all, when in g++ testsuite and
language is not C++ filter out -nostdinc++, -std=gnu++* and when
in rust testsuite and language is not Rust filter out
-frust-incomplete-and-experimental-compiler-do-not-use ?

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)

[Jakub Jelinek via Gcc-rust]

On Thu, Dec 15, 2022 at 12:39:38PM +0100, Iain Buclaw wrote:
> For the gdc testsuite, those warnings arise because both language files
> are compiled in the same invocation (dg-additional-sources "cpp11.cpp"),
> so it ends up looking something like:
> 
> gdc -fextern-std=c++11 testcpp11.d cpp11.cpp -o testcpp11.exe
> 
> So ruling out some sort of filtering done by the gdc driver when
> delegating calls to the C/C++/D language compilers, is there a way to
> get dejagnu to compile dg-additional-sources one-at-a-time?

Through extra code in *.exp file certainly, invoke
  gdc -c cpp11.cpp -o cpp11.o
and
  gdc -fextern-std=c++11 testcpp11.d cpp11.o -o testcpp11.exe
afterwards, but for dg-additional-sources I don't think so.

Maybe it would be nice to be able to pass options only to a certain
gcc backend binary and not to others, similarly to how
-Wa,option passes options to assembler, -Wp,option to preprocessor and
-Wl,option to linker.
-Wc,language,option ?
Then one could
  gdc -Wc,d,-fextern-std=c++11 testcpp11.d cpp11.cpp -o testcpp11.exe
or
  gccrs -Wc,rust,-frust-incomplete-and-experimental-compiler-do-not-use 
whatever.rs something.c -o whatever
etc.
If we do, one would need to use it with care, because then e.g. for
gcc -Wc,c,-fsanitize=address
the driver wouldn't know it should link in -lasan etc.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[PATCH] testsuite: Add support for Rust and Modula-2 effective target tests

[Jakub Jelinek via Gcc-rust]

Hi!

This patch allows magic comments also for Rust and Modula-2
for effective target tests etc. and fixes up the Assembly entry
- it is a glob, so /* Assembly can match /whatever Assembly and
not just /* Assembly.

Tested on x86_64-linux with
make check-g++ RUNTESTFLAGS=i386.exp=pr35513*
and verifying it still uses *.S extension for the property_1_needed
effective target test.

Ok for trunk?

2022-12-15  Jakub Jelinek  

* lib/target-supports.exp (check_compile): Add support for
Rust and Modula-2.  Use \* rather than * for /* comment for
Assembly.

--- gcc/testsuite/lib/target-supports.exp.jj2022-11-30 10:29:42.217698938 
+0100
+++ gcc/testsuite/lib/target-supports.exp   2022-12-15 13:08:47.941221943 
+0100
@@ -36,7 +36,9 @@
 # "! Fortran" for Fortran code,
 # "/* ObjC", for ObjC
 # "// ObjC++" for ObjC++
-# and "// Go" for Go
+# "// Go" for Go
+# "// Rust" for Rust
+# and "(* Modula-2" for Modula-2
 # If the tool is ObjC/ObjC++ then we overide the extension to .m/.mm to 
 # allow for ObjC/ObjC++ specific flags.
 
@@ -58,13 +60,15 @@ proc check_compile {basename type conten
set options ""
 }
 switch -glob -- $contents {
-   "*/* Assembly*" { set src ${basename}[pid].S }
+   "*/\* Assembly*" { set src ${basename}[pid].S }
"*! Fortran*" { set src ${basename}[pid].f90 }
"*// C++*" { set src ${basename}[pid].cc }
"*// D*" { set src ${basename}[pid].d }
"*// ObjC++*" { set src ${basename}[pid].mm }
"*/* ObjC*" { set src ${basename}[pid].m }
"*// Go*" { set src ${basename}[pid].go }
+   "*// Rust*" { set src ${basename}[pid].rs }
+   "*(\* Modula-2*" { set src ${basename}[pid].mod }
default {
switch -- $tool {
"objc" { set src ${basename}[pid].m }

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] testsuite: Add support for Rust and Modula-2 effective target tests

[Jakub Jelinek via Gcc-rust]

On Thu, Dec 15, 2022 at 02:03:36PM +0100, Andreas Schwab wrote:
> On Dez 15 2022, Jakub Jelinek via Gcc-rust wrote:
> 
> > @@ -58,13 +60,15 @@ proc check_compile {basename type conten
> > set options ""
> >  }
> >  switch -glob -- $contents {
> > -   "*/* Assembly*" { set src ${basename}[pid].S }
> > +   "*/\* Assembly*" { set src ${basename}[pid].S }
> > "*! Fortran*" { set src ${basename}[pid].f90 }
> > "*// C++*" { set src ${basename}[pid].cc }
> > "*// D*" { set src ${basename}[pid].d }
> > "*// ObjC++*" { set src ${basename}[pid].mm }
> > "*/* ObjC*" { set src ${basename}[pid].m }
> 
> You probably want to quote the * here too.

You're right on both, I've committed this follow-up
after verifying that Assembly test still works (it works even with \\\*
but doesn't with *) and verifying that changing 
check_effective_target_property_1_needed
to have // Assembly instead of /* Assembly incorrectly works with
"*/* Assembly*", "*/\* Assembly*" but correctly doesn't work with
"*/\\* Assembly*" or "*/\\\* Assembly*".

Committed to trunk.  Sorry.

2022-12-15  Jakub Jelinek  

* lib/target-supports.exp (check_compile): Further quoting
fixes for /* Assembly, /* ObjC and (* Modula-2 *) checks.

--- gcc/testsuite/lib/target-supports.exp.jj2022-12-15 13:57:40.0 
+0100
+++ gcc/testsuite/lib/target-supports.exp   2022-12-15 14:14:02.987854385 
+0100
@@ -60,15 +60,15 @@ proc check_compile {basename type conten
set options ""
 }
 switch -glob -- $contents {
-   "*/\* Assembly*" { set src ${basename}[pid].S }
+   "*/\\* Assembly*" { set src ${basename}[pid].S }
"*! Fortran*" { set src ${basename}[pid].f90 }
"*// C++*" { set src ${basename}[pid].cc }
"*// D*" { set src ${basename}[pid].d }
"*// ObjC++*" { set src ${basename}[pid].mm }
-   "*/* ObjC*" { set src ${basename}[pid].m }
+   "*/\\* ObjC*" { set src ${basename}[pid].m }
"*// Go*" { set src ${basename}[pid].go }
"*// Rust*" { set src ${basename}[pid].rs }
-   "*(\* Modula-2*" { set src ${basename}[pid].mod }
+   "*(\\* Modula-2*" { set src ${basename}[pid].mod }
default {
switch -- $tool {
"objc" { set src ${basename}[pid].m }


Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)

[Jakub Jelinek via Gcc-rust]

On Thu, Dec 15, 2022 at 04:01:33PM +0100, Thomas Schwinge wrote:
> Or, options are applicable to just one front end, and can just be a no-op
> for others, for shared-language compilation.  For example, '-nostdinc++',
> or '-frust-incomplete-and-experimental-compiler-do-not-use' need not
> necessarily emit a diagnostic, but can just just be ignored by 'cc1',
> 'f951', 'lto1'.

One simple change could be to add a new warning option and use it for
complain_wrong_lang warnings:
  else if (ok_langs[0] != '\0')
/* Eventually this should become a hard error IMO.  */
warning (0, "command-line option %qs is valid for %s but not for %s",
 text, ok_langs, bad_lang);
  else
/* Happens for -Werror=warning_name.  */
warning (0, "%<-Werror=%> argument %qs is not valid for %s",
 text, bad_lang);
We could keep the existing behavior, but give users (and our testsuite)
a way to silence that warning if they are ok with it applying only to a
subset of languages.
Then one could use
-frust-incomplete-and-experimental-compiler-do-not-use -Wno-whatever
or add that -Wno-whatever in check_compile if the snippet is different
language from main language of the testsuite (or always) etc.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PING] Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

[Jakub Jelinek via Gcc-rust]

Hi!

On Wed, Jan 11, 2023 at 12:41:06PM +0100, Thomas Schwinge wrote:

I think this should be reviewed by Joseph as option handling maintainer.

> @@ -8896,6 +8897,13 @@ programs.
>  Warn for variables that might be changed by @code{longjmp} or
>  @code{vfork}.  This warning is also enabled by @option{-Wextra}.
>  
> +@item -Wno-complain-wrong-lang
> +@opindex Wcomplain-wrong-lang
> +@opindex Wno-complain-wrong-lang
> +By default, we complain about command-line options that are not valid
> +for this front end.
> +This may be disabled with @code{-Wno-complain-wrong-lang}.

I think this description is too short and confusing, it isn't clear what
"this" front end is, perhaps say "that are not valid for a front end
which compiles a particular source file"?
And certainly give an example and more explanation that the option is
mostly useful when a single compiler driver invocation is compiling
multiple sources written in different languages.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [GSoC] gccrs Unicode support

[Jakub Jelinek via Gcc-rust]

On Wed, Mar 15, 2023 at 11:00:19AM +, Philip Herron via Gcc wrote:
> Excellent work on getting up to speed on the rust front-end. From my
> perspective I am interested to see what the wider GCC community thinks
> about using https://www.gnu.org/software/libunistring/ library within GCC
> instead of rolling our own, this means it will be another dependency on GCC.
> 
> The other option is there is already code in the other front-ends to do
> this so in the worst case it should be possible to extract something out of
> them and possibly make this a shared piece of functionality which we can
> mentor you through.

I don't know what exactly Rust FE needs in this area, but e.g. libcpp
already handles whatever C/C++ need from Unicode support POV and can handle
it without any extra libraries.
So, if we could avoid the extra dependency, it would be certainly better,
unless you really need massive amounts of code from those libraries.
libcpp already e.g. provides mapping of unicode character names to code
points, determining which unicode characters can appear at the start or
in the middle of identifiers, etc.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [GSoC] gccrs Unicode support

[Jakub Jelinek via Gcc-rust]

On Thu, Mar 16, 2023 at 01:58:57PM +0100, Mark Wielaard wrote:
> On Thu, 2023-03-16 at 10:28 +0100, Thomas Schwinge wrote:
> > I'm now also putting Mark Wielaard in CC; he once also started discussing
> > this topic, "thinking of importing a couple of gnulib modules to help
> > with UTF-8 processing [unless] other gcc frontends handle [these things]
> > already in a way that might be reusable".  See the thread starting at
> > 
> > "rust frontend and UTF-8/unicode processing/properties".
> 
> Thanks. BTW. I am not currently working on this.
> Note the responses in the above thread by Ian and Jason who pointed out
> that some of the requirements of the gccrs frontend might be covered in
> the go frontend and libcpp, but not really in a reusable way.

libcpp can be certainly linked into the gccrs FE and specific functions
called from it even if libcpp isn't used as a preprocessor for the language.
Small changes to libcpp are obviously possible as well to make it work.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] libcpp: add function to check XID properties

[Jakub Jelinek via Gcc-rust]

On Fri, Sep 08, 2023 at 02:58:40PM +0200, Arthur Cohen wrote:
> From: Raiki Tamura 
> 
> libcpp/ChangeLog:
> 
>   * charset.cc (check_xid_property):new function to check XID_Start and 
> XID_Continue
>   * include/cpplib.h (check_xid_property):add enum representing XID 
> properties

Just random comments, not a proper review.
1) functions exported from libcpp should IMNSHO use the cpp_ prefix
2) similarly the enumerators should be prefixed with CPP_
3) formatting of the ChangeLog entry is incorrect.  There should be a space
after ): followed by uppercase rather than lowercase letter, descriptions
should end with . and there should be line wrapping so that it fits into 80
columns.  For a new function, one can just say New. or New function.,
doesn't need to describe what it is good for.  And the include/cpplib.h
changes don't describe what actually changed.  A new anonymous enum (why not
a named one?) was added, and check_xid_property declared.

> --- a/libcpp/include/cpplib.h
> +++ b/libcpp/include/cpplib.h
> @@ -1606,4 +1606,11 @@ bool cpp_valid_utf8_p (const char *data, size_t 
> num_bytes);
>  bool cpp_is_combining_char (cppchar_t c);
>  bool cpp_is_printable_char (cppchar_t c);
>  
> +enum {
> +   XID_START = 1,
> +   XID_CONTINUE = 2

Formatting.  There should be indentation just by 2 columns rather than 3.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH 3/3] build: Regenerate build files

[Jakub Jelinek via Gcc-rust]

On Thu, Sep 21, 2023 at 10:44:30AM +0200, Arthur Cohen wrote:
> From: Pierre-Emmanuel Patry 
> 
> Resending this patch without most of the diff so it fits on the ML.
> 
> -
> 
> Regenerate all build files.
> 
> ChangeLog:
> 
>   * Makefile.in:

Missing Regenerate. above?

>   * configure: Regenerate.
>   * libgrust/Makefile.in: New file.
>   * libgrust/aclocal.m4: New file.
>   * libgrust/configure: New file.
>   * libgrust/libproc_macro/Makefile.in: New file.
> 
> libgm2/ChangeLog:
> 
>   * Makefile.in: Regenerate.
>   * aclocal.m4: Regenerate.
>   * libm2cor/Makefile.in: Regenerate.
>   * libm2iso/Makefile.in: Regenerate.
>   * libm2log/Makefile.in: Regenerate.
>   * libm2min/Makefile.in: Regenerate.
>   * libm2pim/Makefile.in: Regenerate.

Jakub

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust