We're currently possibly introducing an unneeded temporary, make use of
InsertValue which is said to kick us off of FastISel and we generate
loads/stores of first class aggregates, which is bad as well. Let's not
do all these things.
Part of #24407.
This PR doesn't have code example since I didn't find how to raise it. If someone finds a code which does, please say it !
cc @pnkfelix
cc @eddyb
r? @Manishearth
We're currently possibly introducing an unneeded temporary, make use of
InsertValue which is said to kick us off of FastISel and we generate
loads/stores of first class aggregates, which is bad as well. Let's not
do all these things.
It came up twice in quick succession on IRC that rustdoc doesn't run tests in bin crates, and doesn't give any explanation/warning either as to why. I thought it couldn't hurt to emphasize that in the Book.
The chapter on concurrency has two examples that both start with:
let something = thread::spawn(…
but the returned values have different types, because the second example has `.join()` at the end of the expression.
I haven't noticed that join at first, and was wondering how is that possible that the result can have `.is_err()` and `.join()` methods.
I've changed the second example to have the same structure as the first, so they're easy to compare.
* Rename `utf16_items` to `decode_utf16`. "Items" is meaningless.
* Move it to `rustc_unicode::char`, exposed in `std::char`.
* Generalize it to any `u16` iterable, not just `&[u16]`.
* Make it yield `Result` instead of a custom `Utf16Item` enum that was isomorphic to `Result`. This enable using the `FromIterator for Result` impl.
* Add a `REPLACEMENT_CHARACTER` constant.
* Document how `result.unwrap_or(REPLACEMENT_CHARACTER)` replaces `Utf16Item::to_char_lossy`.
Fix (and extend) src/test/run-pass/foreign-call-no-runtime.rs
While going over various problems signaled by valgrind when running `make check` on a build configured with `--enable-valgrind`, I discovered a bug in this test case.
Namely, the test case was previously creating an `i32` (originally an `int` aka `isize` but then we changed the name and the fallback rules), and then reading from a `*const isize`. Valgrind rightly complains about this, since we are reading an 8 byte value on 64-bit systems, but in principle only 4 bytes have been initialized.
(I wish this was the only valgrind unclean test, but unfortunately there are a bunch more. This was just the easiest/first one that I dissected.)
The methods gave wrong results for TyIs and TyUs, whose suffix len
should be 5 nowadays. But since they were only used for parsing,
and unneeded for that since 606a309d, remove them rather than fixing.
I hope this is ok to do, since all of rustc is considered unstable...