IRC 2023 06 15

GCC/Rust IRC, 2023-06-15

[...]
<cohenarthur> is there any precedent to importing public libraries like
              https://github.com/TartanLlama/optional to GCC?
<cohenarthur> I'd love to make use of that optional type, as ours is really,
              really lacking and also broken
<cohenarthur> the author waived all possible copyright for this library
<dkm> Oh TartanLlama !
<dkm> Looks very nice indeed
<dkm> I don't see why that would not be possible
<cohenarthur> I think it'd be nice
<cohenarthur> we can get their tl::expected too
<cohenarthur> that'd be great :/ I'm really missing these two types in C++11
<tschwing_> Preferred, as I understand it, is if GCC (compiler) can just
            import (via copy'n'past, probably) something from GCC's libstdc++.
            But I don't know if that's feasible here?
<mjw> cohenarthur, yeah, what tschwing_ says. Maybe ping jwakely for advice.
<cohenarthur> I don't know if that's feasible because std::optional is only
              supported since C++14, and std::expected isn't even supported
              yet - so we might be in a situation where both types rely on
              behavior introduced in C++14/17/20? while tl::optional is
              explicitly compatible with GCC 4.8, which is our limit for gccrs
<cohenarthur> alright, will do! thank you both tschwing_ and mjw :)
<Arsen> cohenarthur: libstdc++ can support earlier versions as extensions
<Arsen> though that'd make bootstrapping uglier maybe
<Arsen> IMO optional and expected are simple enough to implement to not be
        worth dragging in extra upstreams for, I'm sure jwakely can help with
        repurposing libstdc++ bits
<Arsen> for reference, frigg has an optional type and a (slightly limited)
        expected type in what is probably 500 lines
<Arsen> I also wouldn't mind writing those if that helps
<cohenarthur> yes, we have an optional type as well that can do the work, but
              there are pitfalls like optional references that are easy to
              miss
<cohenarthur> and things like assign-through/binding optional references
<cohenarthur> which are annoying to write and annoying to test
<cohenarthur> and it's also annoying to carry around an
              std::optional<std::reference_wrapper<T>> 
<cohenarthur> when we could have an std::optional<T&> (or tl::optional<T&> for
              that matter)
<cohenarthur> there are also more methods on tl's optional type - map,
              and_then, map_or, map_or_else... etc
<cohenarthur> Arsen: that would help, sure :) we don't have an expected at the
              moment. but we have an optional and it's a pain and it already
              broke our build because of
              https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 so I'd like
              to just be done with that, copy paste two files from TL's repos
              and be on our way
<Arsen> okay, I can give that a shot later, where do you have optional
        references, though (and do they make more sense as pointers)?
<cohenarthur> Arsen: sure, that'd be nice if you want to - but what's so wrong
              about directly importing TL's work? :D not that I think your
              version is bad, it's just that I don't want to make you do a
              bunch of extra work
<mjw> maybe silly, but can't you just use whatever is already in libstdc++
      trunk? I mean, why do you need to build against g++ 4.8 (which is silly
      old).
<cohenarthur> also, having optional references still allows you to do method
              chaining, which you don't have with a raw pointer - it's also
              safer overall 
<Arsen> true
<Arsen> but yeah, mjw's pretty much on point, we already have a lot of this
        code that is very widely tested
<cohenarthur> welp I'm not against using libstdc++'s optional type, but you
              mentioned that it would make bootstrapping harder Arsen ?
<cohenarthur> and yeah GCC 4.8 is silly old haha, I can't remember why we
              restrict ourselves like this
<Arsen> I was thinking of expected mostly
<Arsen> since that requires c++23
<cohenarthur> yes
<Arsen> if FEs other than the C and C++ ones can use newer versions of c++,
        though, that drops in the water
<cohenarthur> and that does require concepts etc
<mjw> drops in the water?
<cohenarthur> sure well I wouldn't be against switching to a newer C++
              standard 
<Arsen> mjw: that restriction (to gcc 4.8) becomes irrelevant
<Arsen> I don't recall whether stage1 builds just c and c++
<Arsen> or all enabled langs
<tschwing_> Well, GCC itself is buildable with GCC 4.8, so I'd rather not make
            its Rust front end a special case.
<Arsen> ada and gdc need gcc 10 or so, no?
<tschwing_> Right -- and it's a pain.  ;-%
<Arsen> heh, fair :)
<Arsen> but in either case, this can probably be done even on gcc 4.8, with a
        few lines of code wrapping std::optional
<Arsen> unless I'm missing something
<tschwing_> ACK -- and now AFK.
<cohenarthur> :D
<mjw> tschwing_, why is it a pain? I would assume it is easier because you
      just depend on the g++ just build in stage1 and your frontend then
      builds with that in stage2?
<cohenarthur> Arsen: yes, but that does not work for `expected`
<mjw> o, he is gone
<cohenarthur> haha
<tschwing_> Still here for a second.
<Arsen> yeah, that will likely require some finangling with a variant, but
        depending on how simple the use-case you're shooting for is, it might
        be short
<mjw> then I demand an answer to my silly question! :)
* Arsen looks at how long std/expected is in libstdc++
<tschwing_> There'S also the problen then for '--disable-bootstrap' builds
            (opr cross builds), where you then have a higher-than-GCC-4.8
            dependency.
<cohenarthur> 1821 lines Arsen
<tschwing_> That's not as severe, though, i agree.
<cohenarthur> a lot of them being "@since C++23"
* mjw admits the buildbots (mostly) do a --disable-bootstrap build
<Arsen> heh, okay
<Arsen> I must've confused it with something else
<cohenarthur> while tl::expected is tested on GCC 4.8 
<Arsen> because my recollection was less than 1k
<tschwing_> Otherwise, I agree -- given that GCC/Rust is not in the bootstrap
            path for GCC itself, we could jsut build it with stage 2+ only.
<cohenarthur> oh I just sent the file's length, the actual implementation of
              the class is less than that obv
<Arsen> tschwing_: it would be nice if the build machinery could figure out to
        build a stage1 even for cross builds
<Arsen> people often encountered errors building libgcc when going from 11->12
        iirc
<tschwing_> Arsen: You mean a native stage 1, and then use that to
            cross-build?  I did wonder about that, too, in a different
            contaxt...
<Arsen> yup
<dkm> Arsen: ada builds with 4.8
<tschwing_> dkm: No, tno anymore, as of some time a year ago or so.
<dkm> sorry, 5.5
<dkm> I'm bootstrapping all our patches using gcc 5.5... It's true that 4.8
      was bumped recently, but we're not requiring 10
<tschwing_> ACK.
[...]