fix some uses of pointer intrinsics with invalid pointers
[Found by miri](https://github.com/solson/miri/pull/446):
* `Vec::into_iter` calls `ptr::read` (and the underlying `copy_nonoverlapping`) with an unaligned pointer to a ZST. [According to LLVM devs](https://bugs.llvm.org/show_bug.cgi?id=38583), this is UB because it contradicts the metadata we are attaching to that pointer.
* `HashMap` creation calls `ptr:.write_bytes` on a NULL pointer with a count of 0. This is likely not currently UB *currently*, but it violates the rules we are setting in https://github.com/rust-lang/rust/pull/53783, and we might want to exploit those rules later (e.g. with more `nonnull` attributes for LLVM).
Probably what `HashMap` really should do is use `NonNull::dangling()` instead of 0 for the empty case, but that would require a more careful analysis of the code.
It seems like ideally, we should do a review of usage of such intrinsics all over libstd to ensure that they use valid pointers even when the size is 0. Is it worth opening an issue for that?
Add a small search box to seach Rust's standary library
This change partially addresses #14572. No CSS doesn't look fancy
but at least it is functional.
De-overlap the lifetimes of `flow_inits` and `flow_{un,ever_}inits`.
This reduces `max-rss` for an `nll-check` build by 27% for `keccak`, and
by 8% for `inflate`.
r? @nikomatsakis
use structured suggestion for "missing mut" label
Fixes#54133 for both NLL and non-NLL.
r? @estebank
I'm not super happy with the existing wording here, since it's now a suggestion. I wonder if the message would work better as something like "help: make binding mutable: `mut foo`"?
Also, are the `HELP` and `SUGGESTION` comments necessary?
stabilize slice_align_to
This is very hard to implement correctly, and leads to [serious bugs](https://github.com/llogiq/bytecount/pull/42) when done incorrectly. Moreover, this is needed to be able to run code that opportunistically exploits alignment on miri. So code using `align_to`/`align_to_mut` gets the benefit of a well-tested implementation *and* of being able to run in miri to test for (some kinds of) UB.
This PR also clarifies the guarantee wrt. the middle part being as long as possible. Should the docs say under which circumstances the middle part could be shorter? Currently, that can only happen when running in miri.
proc macro crates are essentially implemented as dynamic libraries using
a dlopen-based ABI. They are also Rust crates, so they have 2 worlds -
the "host" world in which they are defined, and the "target" world in
which they are used.
For all the "target" world knows, the proc macro crate might not even
be implemented in Rust, so leaks of details from the host to the target
must be avoided for correctness.
Because the "host" DefId space is different from the "target" DefId
space, any leak involving a DefId will have a nonsensical or
out-of-bounds DefKey, and will cause all sorts of crashes.
This PR fixes all leaks I have found in `decoder`. In particular, #54059
was caused by host native libraries leaking into the target, which feels
like it might even be a correctness issue if it doesn't cause an ICE.
Fixes#54059
rustc_resolve: allow only core, std, meta and --extern in Rust 2018 paths.
As per https://github.com/rust-lang/rust/issues/53166#issuecomment-419265401:
* Rust 2018 imports can no longer refer to crates not in "extern prelude"
* `::foo` won't load a crate named `foo` unless `foo` is in the "extern prelude"
* `extern crate foo;`, however, remains unchanged (can load arbitrary crates)
* `--extern crate_name` is added (note the lack of `=path`) as an unstable option
* adds `crate_name` to the "extern prelude" (see above)
* crate is searched in sysroot & library paths, just like `extern crate crate_name`.
* `Cargo` support will be added later
* `core`, `std` and ~~`proc_macro`~~ `meta` are *always* available in the extern prelude
* warning for interaction with `no_std` / `no_core` will be added later
* **EDIT**: `proc_macro` was replaced by `meta`, see https://github.com/rust-lang/rust/issues/53166#issuecomment-421137230
* note that there is no crate named `meta` being added, so `use meta::...;` will fail, we're only whitelisting it so we can start producing `uniform_paths` compatibility errors
Fixes#54006 (as the example now requires `--extern alloc`, which is unstable).
Fixes#54253 (hit during fixing RLS).
r? @petrochenkov cc @aturon @alexcrichton @Centril @joshtriplett
Historically LLD has emitted warnings for various reasons but all the bugs have
since been fixed (yay!) and by enabling fatal warnings we should be able to head
off bugs like #53390 sooner.
The names `Math_*` were given to help undefined symbol messages indicate how to
implement them, but these are all implemented in compiler-rt now so there's no
need to rename them! This change should make it so wasm binaries by default, no
matter the math symbols used, will not have unresolved symbols.
If the test fails, output the offending addresses and a helpful error message.
Also slightly improve legibility of the preceding line that puts the addresses
into a HashMap.
Add option to run all tests
This adds the "--include-ignored" flag to libtest, which allows running ignored and unignored tests in one go.
Closes#50363
(Includes a couple variations on the theme. I confirmed that the ones
in `in_expression_position` and `what_if_we_use_panic_directly_in_expr`
both failed back on "rustc 1.30.0-nightly (0f063aef6 2018-09-03)".)
A few cleanups for hir
- prefer `if let` to `match` when only 1 branch matters
- `chain` iterable items that are looped over in sequence
- `sort_by_key` instead of `sort_by` when possible
- change cloning `map`s to `cloned()`
- use `unwrap_or_else` and `ok` when applicable
- a few other minor readability improvements
- whitespace fixes
