[MSP430] Build std components for msp430.

[pftbest]

cc @japaric
r? @alexcrichton

[alexcrichton]

@pftbest to confirm, do you have a good sense for how often this target breaks? If it's pretty rarely this seems fine by me to land, but if it's pretty common I think we may want to perhaps hold off on it for now

[pftbest]

The last major break was in November 2017 when codegen units where enabled by default (#45836). It was fixed in January (#47453).

Since then there where two minor breaks, one in April (#49618) where #[cfg(target_pointer_width)] was missing, and one in May (#50369) where cast from char to usize was giving a warning.

In both cases the problem was the fact that msp430 is a 16bit bit target, and it is easy to forget that usize can be 16bit wide. For example in this pull request i have yet another fix for a similar problem. As you can see the fix was trivial in all this cases.

There is also one more thing you should know about, due to LLVM bug the build will fail when DEPLOY=1 flag is missing. It is set in CI so it will not fail the travis build, but it may be surprising if somebody tries to build dist-various-1 image locally. If you are not comfortable with this, I can try to fix LLVM assertion but I'm not sure how long it will take.

[Mark-Simulacrum]

We discussed this today in the infra meeting, and decided that we'd like to hold off for now on landing this until the LLVM assertion is fixed. DEPLOY doesn't actually fix the assertion, rather it just disables LLVM assertions, so we'd prefer to not land a target that is potentially/likely generating incorrect code. Does that sound reasonable to you?

[pftbest]

DEPLOY doesn't actually fix the assertion, rather it just disables LLVM assertions

In this particular case the problem is caused by integer overflow checks that gets enabled when DEPLOY=0. Without this range checks libcore compiles fine even with LLVM assertions enabled.

But I understand your concern, so I'll see what I can do about it.

[emilyalbini]

Ping from triage @pftbest! It's been a while since we heard from you, will you have time to work on this again?

[pftbest]

Hello, I have no progress on this yet, sorry.

[bors]

☔ The latest upstream changes (presumably #51569) made this pull request unmergeable. Please resolve the merge conflicts.

[TimNN]

Ping form triage! I'm marking this as blocked (on the LLVM bug).

[TimNN]

Ping from triage! Thanks for your PR, @pftbest. It looks like the blocking bug is not going to be resolved anytime soon, so we're closing this PR for now. Feel free to reopen in the future!

[cr1901]

@pftbest I think this might be worth trying to get merged again now:

1. The LLVM bug you linked seems to be fixed.
2. The last time I can recall the msp430 backend not emitting code period was 10 months ago.
3. I'm unaware of any outstanding LLVM bugs (including ones that don't outright break code generation) since 2 months ago.
4. If @pftbest, @awygle, or someone on @asl's (msp430 LLVM backend maintainer) team can get bug fixes and features upstream in LLVM, I'm on standby to quickly merge them into Rust's LLVM fork.
5. Merging quickly into Rust LLVM's fork should be fine for now because we are stuck on nightly until at leastTracking issue for the msp430-interrupt calling convention/ABI #38487 is resolved.