Questions about librustc_back

[Binero]

The crate librustc_back seems to be very broad. At the moment it handles some stuff related to target specification, and it has some utility functions.

The target specification seems to be implemented in a redundant way, the data-layout for different platforms and architectures is defined in too many places, as an example x64: [1][2][3][4][5][6].

There are some utility functions which are questionable. For example, fs seems to contain a single function, to resolve symbolic links. This function doesn't really seem neccesairy, why would you want to resolve out symbolic links? I understand there is probably a reason for this, but even function could be implemented in the standard library, where it'd probably make more sense.

The sha2 module also contains a few integer based functions which should probably be moved to the standard library: [1][2].

The name of the crate is very misleading as well. It implies it's a backend, while really it is just a crate of small, unrelated utility functions. I think the target specification stuff should be split out of that crate, into a seperate one, with an appropriate name (or at least be put into a seperate module) and the verious utility functions be iterated over to see if they are really needed, and if they are at the right place.

I know this issue is poorly named, but couldn't really think of something better. :)

[brson]

It's historical, extracted from the rustc back module which was itself always misnamed. It's always been a dumping ground.

I don't recall why we started resolving symlinks in parts of the compiler. Perhaps @alexcrichton does.

When those utility functions are dumped in rustc its usually because they weren't good enough quality for std, or because somebody failed to win that argument, or just didn't want to make the effort of pursuing it.

Refactoring in the compiler is always well received.

[Binero]

This issue is partially related to rust-lang/rfcs#548. (centralization of integer->byte features)

[alexcrichton]

Much of this has changed in the meantime as the crate has evolved, and there's not a whole lot actionable here beyond "it'd be nice to clean this up", so I'm going to close this (as it's a private implementation detail).