/rustc-demangle/blob/2811a1ad6f7c8bead2ef3671e4fdc10de1553e96/src/v0.rs#L1442-L1444
Thanks,
- Eddy B.
On Tue, Dec 7, 2021, at 21:16, Mark Wielaard wrote:
> Hi Eddy,
>
> On Fri, 2021-12-03 at 01:14 +0200, Eduard-Mihai Burtescu wrote:
>> On Fri, Dec 3, 2021, at 00:07, Mark Wielaard wro
On Fri, Dec 3, 2021, at 00:07, Mark Wielaard wrote:
> Hi Eddy,
>
> On Thu, Dec 02, 2021 at 07:35:17PM +0200, Eduard-Mihai Burtescu wrote:
>> On Thu, Dec 2, 2021, at 19:17, Mark Wielaard wrote:
>> > Rust v0 symbols can have a .suffix because if compiler transformations.
>
On Thu, Dec 2, 2021, at 19:17, Mark Wielaard wrote:
> Rust v0 symbols can have a .suffix because if compiler transformations.
For some context, the suffix comes from LLVM (I believe as part of its LTO).
If this were a semantic part of a Rust symbol, it would have an encoding within
v0 (as we alre
Hi everyone,
Apologies again for the delay on my end, the past few weeks have been hectic
and exhausting.
The changes look good and pass the testing I was doing for my version of the
patch.
Feel free to commit Nikhil's latest patch for us.
Thanks,
- Eddy B.
On Fri, Nov 13, 2020, at 08:42, Nik
the next release?), feel
free to land the v0 changes (snprintf + const values) without the legacy ones.
Thanks,
- Eddy B.
On Sun, Nov 1, 2020, at 11:18, Nikhil Benesch wrote:
>
>
> On 10/29/20 12:16 AM, Nikhil Benesch wrote:
> > On Wed, Oct 28, 2020 at 7:53 PM Eduard-Mihai Burtescu
easier to review.
>
> Yeah, it's not a good idea for me to be a blocker for changes to Rust code.
>
> I took a quick look at the original patch. The calls to sprintf
> should use snprintf instead.
>
> Other than that it seems fine though I have no idea whether it
FWIW, the patch has become slightly outdated compared to the Rust upstream, so
if someone wants to review it I should prepare a new version.
The changes would be for the MVP version of "const generics" (Rust's equivalent
to C++ templates with value parameters, enabling e.g. types like
`CustomAr
Ping 4: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
Thanks,
- Eddy B.
On Mon, Apr 13, 2020, at 05:52, Eduard-Mihai Burtescu wrote:
> Ping 3: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
>
> Thanks,
> - Eddy B.
>
> On Tue, Apr 7, 2020
Ping 3: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
Thanks,
- Eddy B.
On Tue, Apr 7, 2020, at 00:52, Eduard-Mihai Burtescu wrote:
> Ping 2: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
>
> Thanks,
> - Eddy B.
>
> On Fri, Mar 13,
Ping 2: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
Thanks,
- Eddy B.
On Fri, Mar 13, 2020, at 10:28 PM, Eduard-Mihai Burtescu wrote:
> This is the libiberty (mainly for binutils/gdb) counterpart of
> https://github.com/alexcrichton/rustc-demangle/pull/23.
>
&
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
Thanks,
- Eddy B.
On Fri, Mar 13, 2020, at 10:28 PM, Eduard-Mihai Burtescu wrote:
> This is the libiberty (mainly for binutils/gdb) counterpart of
> https://github.com/alexcrichton/rustc-demangle/pull/23.
>
> Re
tached instead of inline, as it's over 1000 lines long.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Also, I have no commit access, so I'd be thankful if
someone would commit this for me if/once approved.From 689442d88b87453a697d2121e45a55071cb9056f Mon Sep 17 00:00:00 2001
From:
> This is OK.
>
> Thanks.
>
> Ian
>
Ping for someone to commit this (as mentioned before, I have no commit access).
I've tried pinging some people on IRC, but saw no response.
Approved version of the patch:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00647.html
Original email, containing th
On Fri, Nov 8, 2019, at 7:43 PM, Ian Lance Taylor wrote:
> On Fri, Nov 8, 2019 at 9:02 AM Eduard-Mihai Burtescu wrote:
> >
> > Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01830.html
> > Original patch (without the early exit optimization):
> > https:/
Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01830.html
Original patch (without the early exit optimization):
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01591.html
Thanks,
- Eddy B.
On Wed, Oct 30, 2019, at 6:46 PM, Eduard-Mihai Burtescu wrote:
> Ping: https://gcc.gnu.org/ml/
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01830.html
Original patch (without the early exit optimization):
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01591.html
Thanks,
- Eddy B.
On Fri, Oct 25, 2019, at 3:44 PM, Eduard-Mihai Burtescu wrote:
> > This can be further optimi
> This can be further optimized by using memcmp in place of strncmp, since from
> the length check you know that you won't see the null terminator among the
> three
> chars you're checking.
Fair enough, here's the combined changelog/diff, with memcmp:
2019-10-22 Edua
On Tue, Oct 22, 2019, at 9:39 PM, Ian Lance Taylor wrote:
> I have to assume that C++ demangling is still quite a bit more common
> than Rust demangling, so it's troubling that it looks like we're going
> to do extra work for each symbol that starts with _ZN, which is not a
> particularly uncommon
ested on x86_64-unknown-linux-gnu.
Also, I have no commit access, so I'd be thankful if
someone would commit this for me if/once approved.
2019-10-22 Eduard-Mihai Burtescu
include/ChangeLog:
* demangle.h (rust_demangle_callback): Add.
libiberty/ChangeLog:
* cplus-dem.
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01469.html
On Wed, Sep 25, 2019, at 8:25 PM, Eduard-Mihai Burtescu wrote:
> The main change here is in the treatment of $...$ escapes.
> I've relaxed the treatment of unknown escapes, during
> unescaping, to continue processing th
The main change here is in the treatment of $...$ escapes.
I've relaxed the treatment of unknown escapes, during
unescaping, to continue processing the input string,
leaving the remainder of current path segment as-is.
Relatedly, rust_is_mangled function doesn't check escapes
at all anymore (as unk
Could you, or someone else, commit this for me (as I have no commit access)?
Thanks.
On Mon, Aug 26, 2019, at 11:04 PM, Ian Lance Taylor wrote:
> On Wed, Aug 14, 2019 at 10:24 AM Eduard-Mihai Burtescu wrote:
> >
> > Previously, rust-demangle.c was special-casing a fixed numb
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01007.html
On Wed, Aug 14, 2019, at 8:22 PM, Eduard-Mihai Burtescu wrote:
> Previously, rust-demangle.c was special-casing a fixed number
> of '$uXY$' escapes, but 'XY' can technically be any hex value,
> repres
s from accidentally outputting a control code.
Additionally, the switch statements, which had one case for each
alphanumeric character, were replaced with if-else chains.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
2019-08-14 Eduard-Mihai Burtescu
libiberty/ChangeLog:
* rust
2019, at 11:54 AM, Eduard-Mihai Burtescu wrote:
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> (Apologies for the delay, while I was able to run libiberty tests back when I
> submitted the patch, I wanted to make sure I can run the whole GCC testsuite,
> especially
the time to troubleshoot the NixOS support for GCC's make check)
Thanks,
- Eddy B.
On Mon, Jun 3, 2019, at 7:23 AM, Ian Lance Taylor wrote:
> On Sat, Jun 1, 2019 at 7:15 AM Eduard-Mihai Burtescu wrote:
> >
> > 2019-06-01 Eduard-Mihai Burtescu
> > include/C
t, at this email or on IRC (eddyb on
Freenode and OFTC), if you want to further discuss the details of upstreaming
the new demangler to Valgrind.
- Eddy B.
On Tue, Jun 4, 2019, at 11:29 AM, Mark Wielaard wrote:
> On Sat, 2019-06-01 at 17:14 +0300, Eduard-Mihai Burtescu wrote:
> >
7;m hoping that libiberty doesn't have strict backwards-compat
requirements, so that we can hide these two functions.
Also, as far as I'm aware, nobody is using them in the wild.
2019-06-01 Eduard-Mihai Burtescu
include/ChangeLog:
* demangle.h (rust_is_mangled): Move to
28 matches
Mail list logo
