Reorganize `core::sys` and other runtime details

[brson]

core::sys entirely deals with types and introspection now: get_type_desc, size_of, align_of, refcount, log_str.

[nickdesaulniers]

What should core::sys be renamed to?

[brson]

That's a tough question, and I basically think that it needs to be entirely eliminated now. This module is a combination of introspection and intrinsics and runtime representations.

I think we could start by moving the entire thing to a submodule of core::private, which is turning into the module for private runtime details. Some of these things should not be used so can just languish there for awhile.

Here's a suggestion for each thing defined in sys:

• FreeGlue - leave in private. This is a very low level runtime detail that should not be exposed.
• TypeDesc - leave in private. This is obsoleted by the alternate definition in intrinsics.rs
• get_type_desc - leave in private.
• Closure - leave in private. Again a detail of representation that should not be a public API
• shape_* - delete. These look obsolete to me - I don't see how they are different than doing the comparison directly
• size and align functions. This is a hard call. I'm tempted to create core::size for them.
• refcount - leave in private. Nobody should use this.
• begin_unwind* - leave in private.

OK, that's everything. I guess my conclusion here is that most of this stuff just shouldn't be exposed, the size functions being the only exceptions.

I think we need others to weigh in. @graydon What do you think?

[graydon]

I find the idea of the private module a bit strange; we have visibility control in this language so we can easily just not-export stuff we don't want people seeing.

That said, I don't mind trying to merge some of the muddle here. There's clearly redundancy between private, rt and sys (and probably cleanup, stackwalk, maybe some others). Don't mind the general thrust of the bug here, in terms of cleaning them up. Won't complain if some of these move around or merge.

[brson]

@graydon I agree private is not quite the right place - it was originally for API's needed by standard.. I have a bunch of new runtime code on the way and plan to do some reorganization.

[brson]

I imagine we ultimately need 3 runtime modules: the first is the private runtime source, the second fills the current role of private - exporting undocumented APIs, the third is the public compiler interface to the runtime (which could also potentially be in private and which is now called rt.

[brson]

@graydon also suggested that the size and align functions belong in core::mem and I agree.

[brson]

OK, here's a new suggested plan of attack.

1. Move core::rt to core::private::rt
2. Move the size and align functions to core::mem
3. Create the private module core::rt
4. Move sys to core::rt
5. Move cleanup and stackwalk to core::rt

That gives these modules an organization that I like and hides the ugly details contained in sys.

[brson]

Updated title to reflect current plan.

[pcwalton]

Will the tests be able to access private? Many tests need to inspect ref counts.

[brson]

Yes.

[brson]

As I think more about it I don't think it necessarily makes sense to aggressively dump implementation details into core::rt. Leaving them at the crate level but private isn't a bad organizational technique, though I'm more accustomed to hierarchy. I will probably resist moving core::pipes to core::rt::pipes, and instead make it private. I do though still think it is appropriate to put all the publicly-visible interfaces that aren't part of a stable API in their own mod.

[graydon]

As of 2013-06-05, sys still exists and is still a grab bag of weird functions many of which have no meaning or use anymore. Assuming it will slowly be absorbed into the now-maturing rt module, but not done yet.

[emberian]

std::sys still exists, and seems to just be wrappers over intrinsics.