Rust: Work around 'error[E0658]: `let...else` statements are unstable'

[Arthur Cohen]

Hi Thomas!

On 12/4/24 13:35, Thomas Schwinge wrote:
> Hi Arthur!
> 
> On 2024-11-25T11:24:08+0100, Arthur Cohen <arthur.cohen@embecosm.com> wrote:
>> Thanks, this patch (and your other one on the matter) looks good
> 
> Oh, wow -- I passed the first non-trivial Rust programming I've done!
> :-D ;-)
> 
>> but I
>> have a slight issue with it. We had previously done something similar to
>> adapt to Rust 1.72 when we originally reused the format_args parser:
>>
>> https://github.com/Rust-GCC/gccrs/pull/2964
>>
>> This was later reverted because a GSoC student needed some nightly
>> features. I would rather re-apply this entire patch, lower our Rust
>> version requirement to 1.49, and upstream the fixes as part of our next
>> upstreaming period. What do you think about this?
>>
>> There are a couple more fixes to go from 1.72 to 1.49, and the
>> `String::leak` method is also slightly easier to use.
>>
>> Let me know and I'm happy to reapply the PR.
> 
> Hmm, in terms of incremental progress, to resolve one real issue in my
> (and others') testing of upstream GCC trunk, would it be OK if I push my
> two patches now, and then we later extend (or even revert) them as
> necessary for continued GCC/Rust upstreaming?  (..., while keeping the
> tree buildable with old 'rustc'/'cargo'.)

In that case, could you instead add the commit mentioned in the PR so we 
don't need to revert it or change it? But instead we'd just be 
upstreaming this commit slightly earlier. My thinking is we do the 
following:

1. Push commit 039624951f9 upstream, which lowers the required Rust 
version to 1.49
2. Send a PR to our github repo with that commit so we merge it in our 
dev repo as well
3. This way once we rebase our branch to send it upstream, this commit 
will just be skipped

I think the commit should apply on both our dev repo and our version of 
gccrs which is upstream.

Feel free to take ownership of it - the changes are extremely similar, 
the only difference is the use of a trait extension for String::leak() 
instead of a dedicated leak_string() function.

How do you feel about that? Would that be okay?

Best,

Arthur

> 
> 
> Grüße
>   Thomas
> 
> 
>> On 11/23/24 9:09 PM, Thomas Schwinge wrote:
>>> Hi!
>>>
>>> On 2024-08-01T16:56:01+0200, Arthur Cohen <arthur.cohen@embecosm.com> wrote:
>>>> Compile libformat_parser and link to it.
>>>
>>>> --- /dev/null
>>>> +++ b/libgrust/libformat_parser/generic_format_parser/src/lib.rs
>>>> @@ -0,0 +1,1102 @@
>>>> +[...]
>>>> +    let Some(unescaped) = unescape_string(snippet) else {
>>>> +        return InputStringKind::NotALiteral;
>>>> +    };
>>>> +[...]
>>>
>>> OK to push the attached
>>> "Rust: Work around 'error[E0658]: `let...else` statements are unstable'"?
>>> Builds and tests fine, but I don't know if this code path is actually
>>> exercised at this time, so please check carefully; as you know I'm not
>>> actually a Rust programmer (yet).  ;-)
>>>
>>>
>>> Grüße
>>>    Thomas