Stream: project-error-handling

Topic: std/alloc/core


view this post on Zulip Josh Triplett (Sep 30 2020 at 21:12):

@Jane Lusby and others: I just spoke with the rest of the Cargo team, and we're definitely willing to help out with questions about build-std and feature flags, if folks here are up for working towards the merge.

view this post on Zulip Josh Triplett (Sep 30 2020 at 21:12):

@Eric Huss and @Alex Crichton in particular mentioned that they'd be happy to get questions.

view this post on Zulip Josh Triplett (Sep 30 2020 at 21:12):

This is something we've wanted for a long time, and help is deeply welcome.

view this post on Zulip simulacrum (Sep 30 2020 at 21:13):

on the bootstrap side I am also happy to answer questions about feasibility/distribution etc

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:14):

I think we're definitely moving towards pushing for a merge @Josh Triplett

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:14):

the steps I forsee are

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:16):

  1. get a proof of concept for backtrace in core that doesnt' depend on alloc in its current state
  2. stabilize fn backtrace and Backtrace in std (assuming we can later change this to a re-export of core's backtrace type)
  3. merge core/std so that we can resolve the coherence issues around some of the existing trait impls related to the Error trait and make it so that the Error trait is available without alloc in this newly merged std/core/alloc

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:16):

im assuming that 2 is fine because no matter what when we merge things together that would presumably resolve any issues, assuming there are even any issues about moving things around

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:16):

which I doubt there are given that I think we've done that before

view this post on Zulip simulacrum (Sep 30 2020 at 21:19):

that all sounds relatively reasonable

view this post on Zulip simulacrum (Sep 30 2020 at 21:20):

I think the major hurdle is going to be chasing down upstream projects that are currently "real" dependencies of std and converting those to #[path = ... ] deps of std, or trying to push on a compiler change that would permit more ergonomic "copy/paste this code in" that doesn't require changes in the upstream logic

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:30):

a couple of my friends have pointed out that they think package local orphan rule violators might be the better approach in the long run

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:30):

where you could group alloc/std/core into one package but as different crates ( i think im not mixing those up) and the orphan rules would be applied to the group rather than each individual crate

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:31):

I'd also be happy to go down this path, I don't really have a strong preference

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:31):

tho the latter approach seems like it might have large benefits downstream as well

view this post on Zulip simulacrum (Sep 30 2020 at 21:31):

I also remain unconvinced that literally combining the crates is the way to go here vs. adding a std-only-for-now switch. I think boats had concerns about this approach? I may be misremembering

view this post on Zulip Jane Lusby (Sep 30 2020 at 21:32):

no idea

view this post on Zulip simulacrum (Sep 30 2020 at 21:32):

I do think it's going to be quite hard to get the unification to work out nicely, though probably a one-time cost mostly

view this post on Zulip Manish Goregaokar (Sep 30 2020 at 21:32):

Jumping in from an out of band conversation with @Jane Lusby . I have some reservations about merging the stdlibs, and in particular I think motivating it by the orphan rule is a mistake because the problems with the orphan rule here are quite general.

This has been discussed in the past, but, a lot of projects are conceptually "multiple crates, one package", where the "package" is intended to be versioned as a single thing, but is split into many crates to aid in conditional compilation, features, etc. Notably, there are _many_ cases where rust forces you into splitting crates especially when you want to use features, and it ends up being easier to do this. I know that Rain is looking into this kind of thing.

There's a case to be made for local orphan violations within the same package. I've been in situations where i've needed this quite often, and it's one of the main reasons the orphan rules gets annoying -- when it gets in the way where there is _actually no danger_ but it's entirely due to how you chose to slice your code.

view this post on Zulip Josh Triplett (Sep 30 2020 at 22:17):

FWIW, there are multiple other reasons to want to merge the crates; this isn't just about the orphan rule. More generally, there's a desire to be able to compile one crate with feature flags that may be finer-grained than the existing std or alloc.

view this post on Zulip Josh Triplett (Sep 30 2020 at 22:19):

I wouldn't want to see the error-handling project commit everything to making that work as the solution. More that if we agree we want this change anyway, and it's just a matter of implementation effort, then having people who are willing to do the work would help.

view this post on Zulip Alex Crichton (Sep 30 2020 at 22:20):

another example is it'd be great to use simd in libcore, but we it's difficult today because cpu feature detection is in libstd

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 30 2020 at 22:34):

Orphan rule?

view this post on Zulip Josh Triplett (Sep 30 2020 at 22:36):

@Charles Ellis O'Riley Jr. If you want to impl SomeTrait for SomeType, you must either be the crate that provides SomeTrait or the crate that provides SomeType, to a first approximation.

view this post on Zulip Josh Triplett (Sep 30 2020 at 22:36):

(It gets a little more complicated with types that have generic parameters, but that's the key concept.)

view this post on Zulip Josh Triplett (Sep 30 2020 at 22:37):

An impl of a trait for a type where you don't own either the trait or the type is called an orphan impl.

view this post on Zulip Charles Ellis O'Riley Jr. (Sep 30 2020 at 22:42):

Josh, first, thank you for the explanation. Second, I have much to learn.l:grinning:.

view this post on Zulip Jane Lusby (Sep 30 2020 at 22:45):

I'm not going to focus on this that much just yet but once we've mostly worked thru the backtrace stabilization issue I think I'll try to go back and create a summary of the problems we're trying to solve and the solutions that are available so we can figure out how we want to move forward to get error into core

view this post on Zulip Jane Lusby (Oct 02 2020 at 21:09):

related discussion https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Why.20is.20HashMap.20in.20std.20and.20not.20alloc.3F

view this post on Zulip boats (Oct 11 2020 at 17:45):

We have tons of APIs that want this in std and not all of them are coherence related, some are inherent methods, for example

view this post on Zulip boats (Oct 11 2020 at 17:46):

changing the coherence boundary to be larger than the crate would make rust coherence depend on the build system, I'm really not compelled by any proposal to make the language potentially incoherent without cargo


Last updated: Jan 29 2022 at 11:01 UTC