Move Bound to libcore.

[clarfonthey]

Half of a redone version of #41460. This creates a new module, core::collections, which currently only contains this type.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

Looks like travis failed:

[00:01:36] error: This node does not have a stability attribute
[00:01:36] --> /checkout/src/libcore/collections.rs:48:14
[00:01:36] |
[00:01:36] 48 | Included(T),
[00:01:36] | ^^
[00:01:36] [00:01:36] error: This node does not have a stability attribute
[00:01:36] --> /checkout/src/libcore/collections.rs:51:14
[00:01:36] |
[00:01:36] 51 | Excluded(T),
[00:01:36] | ^^
[00:01:36] [00:01:37] error: aborting due to 2 previous errors

[clarfonthey]

Indeed it did. I'm not quite sure why, though, because those nodes do have stability attributes.

[alexcrichton]

I'm looking around and trying to find the rationale for this (I've forgotten at this point), can you remind me the reason for this move?

[clarfonthey]

@alexcrichton this is basically a prerequisite for moving RangeArgument to core

[alexcrichton]

Hm sorry but forgive my ignorance, why do we want to do that?

[clarfonthey]

@alexcrichton considering how the Range types are all in core, it makes sense to move these to libcore as well. I mentioned it in the tracking issue and people seemed to agree.

[alexcrichton]

Hm so we don't tend to move types around "just because", can you elaborate on the rationale for moving these types into core? Will this enable more use cases?

[clarfonthey]

I mean, it gives you the ability to operate on RangeArgument instead of discrete range types for any no_std crate. So, I'd consider that a big plus.

no_std collections that work on the stack would be a big use case.

[clarfonthey]

Also I added stability markers to the T and it compiles now?? I'm not sure why it needs this but I'll take it.

[Mark-Simulacrum]

Link checker found a few problems.

[00:53:08] Linkcheck (x86_64-unknown-linux-gnu)
[00:53:13] core/collections/index.html:54: broken link - core/std/collections/index.html
[00:53:13] core/collections/enum.Bound.html:71: broken link - core/collections/btree_map/struct.BTreeMap.html
[00:53:14] thread 'main' panicked at 'found some broken links', /checkout/src/tools/linkchecker/main.rs:49

[alexcrichton]

Can you remove these // ??? annotations? This is just how the stability check works.

[alexcrichton]

I personally feel like we're not quite ready to do this yet. This seems to put us into a sort of "half baked" state where we have a stable collections module in libcore with no items other than Bound. It's ripe for expansion but we tend to prefer halfway states when committing to the master branch. Can this be delayed until there's more types/traits to move into the module?

[clarfonthey]

Sounds good to me!

Also the reason why I added the ???s was because they weren't required on the enum before I moved it. I've never seen the linter require stability attributes for the inside of tuple variants/structs before.

[clarfonthey]

Closing and moving the discussion to #30877.