New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Make libstd a facade #40

Merged
merged 2 commits into from Apr 29, 2014

Conversation

Projects
None yet
@alexcrichton
Member

alexcrichton commented Apr 8, 2014

No description provided.

# Unresolved questions
* Compile times. It's possible that having so many upstream crates for each rust

This comment has been minimized.

@thestinger

thestinger Apr 8, 2014

The duplicate compilation of inline and/or generic functions hurts a lot too.

This comment has been minimized.

@alexcrichton

alexcrichton Apr 10, 2014

Member

Good point, I'll add a comment to this section.

@brendanzab

This comment has been minimized.

Member

brendanzab commented Apr 8, 2014

I like this. What would happen to the other crates currently in the rust repo that you didn't mention? Could they be moved out into separate repositories once the cargo situation is nicer?

On a bikeshedding note, I would prefer libcore over libmini (or the previously floated libprim). core is an excellent, beautiful word that is extremely self-explanatory. You even use it in your description, "This library is meant to be the core component of all rust programs in existence." @brson has expressed concern about it being confused with thestinger/rust-core in the past, but I really think we should choose the best name for the job – one that will serve us well years into the future.

* librustrt: libmini liballoc liblibc
* libsync: libmini liballoc liblibc librustrt
* libstd: everything above

This comment has been minimized.

@brendanzab

brendanzab Apr 8, 2014

Member

Here's a diagram of the proposed dependency graph:

std-facade

### `libmini`
> **Note**: The name `libmini` warrants bikeshedding. Please consider it a
> placeholder for the name of this library.

This comment has been minimized.

@bstrie

bstrie Apr 8, 2014

Contributor

If we're bikeshedding, I propose libcore. Historical precedent, and you even use the word "core" in the next sentence.

This comment has been minimized.

@brendanzab

brendanzab Apr 8, 2014

Member

See my other comment.

being said, libmini would certainly create many literal strings (for error
messages and such). This may be adequately circumvented by having literal
strings create a value of type `&'static [u8]` if the string lang item is not
present. While difficult to work with, this may get us 90% of the way there.

This comment has been minimized.

@bstrie

bstrie Apr 8, 2014

Contributor

You say above that strings "will no longer be a language item", yet here "if the string lang item is not present".

This comment has been minimized.

@alexcrichton

alexcrichton Apr 10, 2014

Member

I've clarified the wording for the first mention to be a "language feature" rather than a "language item"

to no overhead required in terms of dependencies.
Neither `print!` nor `format!` macros to be a part of this library, but the
`write!` macro to be present.

This comment has been minimized.

@andrew-d

andrew-d Apr 9, 2014

This is worded really awkwardly - need to be a part, etc.?

@bstrie

This comment has been minimized.

Contributor

bstrie commented Apr 9, 2014

I'm concerned at the potential ramifications of leaving out strings from libmini. Perhaps traitsplosion would be acceptable in this case?

@Tobba

This comment has been minimized.

Tobba commented Apr 9, 2014

Since libmini would already require weak lang items, I feel we might want to expand that system in some way so we could make liballoc pluggable instead of everything directly linking to a specific allocator (unless pluggability is already a part of the plan for liballoc, the description is a bit vague right now). This would make it possible to use libcollections, and by extension libtext, inside of a kernel, which would certainly be nice.

@cmr

This comment has been minimized.

Member

cmr commented Apr 9, 2014

libmini doesn't require weak lang items. it just wouldn't have code that requires those lang items. if you don't use them, they aren't required.

@Tobba

This comment has been minimized.

Tobba commented Apr 9, 2014

I'm pretty sure the Failure section specifically mentions that libmini requires weak lang items for failure in .unwrap?

@cmr

This comment has been minimized.

Member

cmr commented Apr 9, 2014

I interpreted that paragraph as saying that the failure function itself will be the only "weak lang item", and that the full generalization of the feature would not be implemented.

@Tobba

This comment has been minimized.

Tobba commented Apr 9, 2014

Implementing weak lang items for only a single function instead of a generic solution sounds like a bad idea to me.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Apr 10, 2014

What would happen to the other crates currently in the rust repo that you didn't mention? Could they be moved out into separate repositories once the cargo situation is nicer?

I believe that for now nothing will change, and cargo is their path to moving out of the repo.

I'm concerned at the potential ramifications of leaving out strings from libmini. Perhaps traitsplosion would be acceptable in this case?

This is mostly a limitation of not knowing anything about allocation rather than a worry about traits. If we continue to keep the StrBuf and Str distinction, it may be possible for Str type to be defined in libmini because in theory none of the methods on it will allocate. This is because the definition of the type would look like:

#[lang = "str"]
pub struct Str([u8]);

This type doesn't necessarily imply any allocations, and perhaps all of the non-allocating methods could be defined in libmini and traits may be able to add some allocating-ness later on (depending on how many methods allocate).

If we don't go with the Str and StrBuf distinction, I think we'll have a hard time putting Str in libmini, but if we keep the distinction it may be plausible.

I feel we might want to expand that system in some way so we could make liballoc pluggable instead of everything directly linking to a specific allocator

I agree that this is a bit worrisome, and that was my general idea about how to do so. This is covered by the "libc is so core" unresolved question at the end, and I think that with libstd being a facade it will be possible to change this in the future without many backwards compatibility hazards (these crate structures will all be experimental, just not the reexported contents).

Implementing weak lang items for only a single function instead of a generic solution sounds like a bad idea to me.

I did not intend to generalize the idea of "weak lang items" all lang items, but rather just failure and possibly allocation. I'm not entirely sure what a generic solution would look like because many lang items are not functions (such as the traits), but this is definitely an open question about whether singling out failure/allocation is the correct way to go.

This would make it possible to use libcollections, and by extension libtext, inside of a kernel, which would certainly be nice.

I'm not entirely sure if this will ever be possible, because liballoc is built on the assumption that allocation never fails, which isn't quite true for kernel environments. User-space environments that aren't powered by libc, however, would benefit from this abstraction (switching out the default allocator).

@Tobba

This comment has been minimized.

Tobba commented Apr 10, 2014

There has been some talk about weak "global" statics, which would make possibly make the libnative/libgreen situation a bit nicer and would allow for a proper pluggable liballoc.
There isn't really any reason not to make all fn lang items weak in my opinion, they're quite different from trait lang items, to which this doesn't really apply.

My proposal for weak fn lang items would be that their symbols are given special names, and default to being an external symbol in libraries. Then the compiler can complain at compile time of the application in case any are missing. Something similar could probably be applied for those weak statics.

@blaenk

This comment has been minimized.

Contributor

blaenk commented Apr 11, 2014

libcore is indeed clear and self-explanatory. libmetal would be very neat, the metal upon which rust forms.

@bjadamson

This comment has been minimized.

bjadamson commented Apr 14, 2014

I'm not entirely sure if this will ever be possible, because liballoc is built on the assumption that allocation never fails, which isn't quite true for kernel environments. User-space environments that aren't powered by libc, however, would benefit from this abstraction (switching out the default allocator).

This would end up being really sad for the kernel developers!

@mcpherrinm

This comment has been minimized.

mcpherrinm commented Apr 15, 2014

I'm pretty concerned about the fact that collections will require libc. It seems essential to me that providing a substitute allocator that doesn't depend on libc will allow libcollections and text to be used in a libc-free land. Having a more minimal "Host OS" requirement for allocation and such seems more amenable to me, like newlib's "OS stubs" https://sourceware.org/newlib/libc.html#Stubs -- a significantly smaller API to implement than all of libc.

@bharrisau

This comment has been minimized.

bharrisau commented Apr 20, 2014

Is it the wrong direction to go in to use weak fns and a split up like this
to handle the more complicated requests like pluggable/fail-able
allocation, integer overflow, etc.

Similar to how libmini would have Option.unwrap fail unless something like
rust_unwrap_failure() existed. A default allocator could exist in
liballoc that is only used when the alternative symbol is missing (and the
default allocator fails on allocation failure if rust_alloc_failure() is
missing).

@liigo

This comment has been minimized.

Contributor

liigo commented Apr 23, 2014

blaenk: libcore is indeed clear and self-explanatory. libmetal would be very neat, the metal upon which rust forms.

libmini/libprim is a good name, libcore is a better name, libmetal is the best.

@bharrisau

This comment has been minimized.

bharrisau commented Apr 23, 2014

rust_stack_exhausted() is another thing that needs to live in libmetal and abort/fail, but have a bigger implementation in rustrt.

@ghost ghost referenced this pull request Apr 25, 2014

Closed

Add support for alternative C libraries #7283

@aturon aturon referenced this pull request Apr 29, 2014

Merged

Add a bitflags! macro #13072

@brson brson referenced this pull request Apr 29, 2014

Closed

Make std a facade #13851

9 of 9 tasks complete

@brson brson merged commit b7f346e into rust-lang:master Apr 29, 2014

@brson

This comment has been minimized.

Contributor

brson commented Apr 29, 2014

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Apr 29, 2014

I talked to @thestinger on IRC, and he was ok with naming the innermost library "libcore", so I will likely call it that.

@alexcrichton alexcrichton deleted the alexcrichton:component-libraries branch Jun 18, 2014

@aturon aturon referenced this pull request Sep 25, 2015

Closed

Tracking issue for libcore + no_std stabilization #27701

4 of 4 tasks complete

@chriskrycho chriskrycho referenced this pull request Dec 30, 2016

Closed

Document all features in the reference #38643

0 of 17 tasks complete

withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017

Merge pull request rust-lang#40 from SimonSapin/patch-3
Update doc-comment refering to poll() returning None

@chriskrycho chriskrycho referenced this pull request Mar 11, 2017

Closed

Document all features #9

18 of 48 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment