Moving bits of rustc into crates

[MajorBreakfast]

rustc-hash ?

A bit more creativity please “chalk” and “polonius” are good names. I’m sure you can come up with something interesting: “flashhash”, “ultrahash” or something else that does or does not contain the word “hash” ^^’

[gbutler]

or something else that does os does not contain the word “hash”

TripleRMap (Rust Ricky Resin)?

[est31]

I think factoring out generic bits and pieces of the code and moving it into separate crates is a great idea.

The great drawback was already mentioned which is atomic changes across the entire codebase. I think that components can be refactored though to not rely on a multitude of rustc’s internals and be generic.

[HadrienG]

Looks like I’ve reserved Hashish as a software project name early enough

[michaelwoerister]

I think I’ve seen already existing crates.io dependencies for smallvec and arrayvec when compiling rustc. At the same time we have versions of both in rustc_data_structures. Those seem like good candidates to look into.

[mark-i-m]

A bit more creativity please “chalk” and “polonius” are good names. I’m sure you can come up with something interesting: “flashhash”, “ultrahash” or something else that does os does not contain the word “hash” ^^’

ferrishash

I think that components can be refactored though to not rely on a multitude of rustc’s internals and be generic.

My understanding was that the first pass would be over more generic data structures, so there wouldn’t need to be as much disentangling…

[leodasvacas]

The rustc-hash crate now exists and rustc will now use it.

[nikomatsakis]

As an aside: I definitely agree with creative crate names, but I couldn’t come up with one that felt right in the allotted time. =) Also, on the scale of crates, this crate … doesn’t seem like one that has to have a cool name. =)

[MajorBreakfast]

@nikomatsakis I think that “rustc-hash” isn’t a good name choice because the crate isn’t inherently linked to the compiler. This makes the “rustc-” part is a bit misleading. Consider naming it “ferrishash” like @mark-i-m suggested. The name is available and it sounds great!

[gbutler]

rustc-hash sounds better. It is the hash implementation used by the rustc compiler. That doesn’t mean it is only used by the compiler or can only used by the compiler.

[MajorBreakfast]

I don’t agree. A shared prefix means to me that the two crates have a strong relation. For example “actix” and “actix-web”. Besides, “creative names” are encouraged in the crates.io package policies (see the section about why crates.io has no namespacing).

[gbutler]

A shared prefix means to me that the two crates have a strong relation

Yes, I would agree, and I would think that the crate being created in rust-lang specifically for the purpose of the Rust compiler no longer needing to have that create internally, suggests just such a strong relationship. Of course, just an opinion.

[MajorBreakfast]

It’s a fast non-cryptographic hash map and suitable for any project. Hence no strong relationship to rustc except that rustc uses it.

Very similar: The “url” crate from servo is also general purpose. It’s not called “servo-url” for that reason.

[gbutler]

Yeah, that argument makes sense. That being said, I think for fundamental stuff, like this, having a name that functionally describes as opposed to being “memorable” (or cute) is valuable. If I’m looking for a blessed “HashMap” implementation, it would be very easy to get too “Cute” with the name. But, I definitely see where you are coming from.

For example of what I mean by “Too Cute”:

• HashBrown
• Hashish
• TripleRMap (see above for the joke)
• HashTag
• PoundIt

What would be “good” names (IMHO) would be something like:

• rlang-hash
• rl-hash
• rl-std-hash

etc.

[MajorBreakfast]

“quick-hash” is also still available (“quick_hash”, “quickhash” as well)

BTW in in the JavaScript community package names like “node-…” and “…-js” are a bit frowned upon. “rlang-hash” isn’t a good name. It just indicates that it’s written in Rust - just like every other crate.

[michaelwoerister]

Hm, one problem with a lot of the data structures seems to be that they must support serialization via rustc’s own libserialize. That makes it hard to move them out-of-tree. Does anybody have a good solution for this?

[cuviper]

Could libserialize act as a serde backend?

[gbutler]

One of the problems with something like “serde” is that due to coherency rules, only the crate that creates a new trait may impl that trait for an arbitrary crate and only a crate that declares a struct may impl an arbitrary trait for that struct. 3rd party crates may not impl traits they did not define themselves for structs they did not themselves define.

I wonder if there could ever be a notion of “Friend” or “Blessed” impl crate to work around this restriction in a way that maintains soundness? What if a crate could declare “friend” crates and those “friend” crates would be permitted to provide impls for arbitrary 3rd party traits?

[cuviper]

I’m suggesting that those data structures can implement serde for their own types, and libserialize can implement its data format for serde. There’s no coherency problem with that.

[michaelwoerister]

I don’t think we can use serde in the compiler yet because of bootstrapping restrictions (right, @eddyb?).