add `-Z dont-buffer-diagnostics`
Add `-Z dont-buffer-diagnostics`, a way to force NLL to immediately its diagnostics.
This is mainly intended for developers who want to see the error in its original context in the control flow. Two uses cases for that are:
1. `-Z treat-err-as-bug` (which then allows extraction of a stack-trace to the origin of the error)
2. RUST_LOG=... rustc, in which case it is often useful to see the logging statements that occurred immediately prior to the point where the diagnostic was signalled.
Regression test for rust-lang/rust#53675.
(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)".)
Fix#53675
Add doc for impl From for Addr
As part of issue #51430 (cc @skade).
The impl is very simple, let me know if we need to go into any details.
Additionally, I added `#[inline]` for the conversion method, let me know if it is un-necessary or might break something.
Merge `bitvec.rs` and `indexed_set.rs`
Because it's not good to have two separate implementations. Also, I will combine the best parts of each to improve NLL memory usage on some benchmarks significantly.
Clean up dependency tracking in Rustbuild [2/2]
Make `clear_if_dirty` calls in `Builder::cargo` with stamp dependencies for the given Mode.
Continuation of #50904
Ref issue #50509
r? @Mark-Simulacrum
- Rename `BitSet::data` and `BitMatrix::vector` as `words`, because that's
what they are.
- Remove `BitSet::words_mut()`, which is no longer necessary.
- Better distinguish multiple meanins of "word", i.e. "word index" vs
"word ref" vs "word" (i.e. the value itself).
`BitwiseOperator` is an unnecessarily low-level thing. This commit
replaces it with `BitSetOperator`, which works on `BitSet`s instead of
words. Within `bit_set.rs`, the commit eliminates `Intersect`, `Union`,
and `Subtract` by instead passing a function to `bitwise()`.
Currently we have two files implementing bitsets (and 2D bit matrices).
This commit combines them into one, taking the best features from each.
This involves renaming a lot of things. The high level changes are as
follows.
- bitvec.rs --> bit_set.rs
- indexed_set.rs --> (removed)
- BitArray + IdxSet --> BitSet (merged, see below)
- BitVector --> GrowableBitSet
- {,Sparse,Hybrid}IdxSet --> {,Sparse,Hybrid}BitSet
- BitMatrix --> BitMatrix
- SparseBitMatrix --> SparseBitMatrix
The changes within the bitset types themselves are as follows.
```
OLD OLD NEW
BitArray<C> IdxSet<T> BitSet<T>
-------- ------ ------
grow - grow
new - (remove)
new_empty new_empty new_empty
new_filled new_filled new_filled
- to_hybrid to_hybrid
clear clear clear
set_up_to set_up_to set_up_to
clear_above - clear_above
count - count
contains(T) contains(&T) contains(T)
contains_all - superset
is_empty - is_empty
insert(T) add(&T) insert(T)
insert_all - insert_all()
remove(T) remove(&T) remove(T)
words words words
words_mut words_mut words_mut
- overwrite overwrite
merge union union
- subtract subtract
- intersect intersect
iter iter iter
```
In general, when choosing names I went with:
- names that are more obvious (e.g. `BitSet` over `IdxSet`).
- names that are more like the Rust libraries (e.g. `T` over `C`,
`insert` over `add`);
- names that are more set-like (e.g. `union` over `merge`, `superset`
over `contains_all`, `domain_size` over `num_bits`).
Also, using `T` for index arguments seems more sensible than `&T` --
even though the latter is standard in Rust collection types -- because
indices are always copyable. It also results in fewer `&` and `*`
sigils in practice.
Temporarily prohibit proc macro attributes placed after derives
... and also proc macro attributes used together with `#[test]`/`#[bench]`.
Addresses item 6 from https://github.com/rust-lang/rust/pull/50911#issuecomment-411605393.
The end goal is straightforward predictable left-to-right expansion order for attributes.
Right now derives are expanded last regardless of their relative ordering with macro attributes and right now it's simpler to temporarily prohibit macro attributes placed after derives than changing the expansion order.
I'm not sure whether the new beta is already released or not, but if it's released, then this patch needs to be backported, so the solution needs to be minimal.
How to fix broken code (derives):
- Move macro attributes above derives. This won't change expansion order, they are expanded before derives anyway.
Using attribute macros on same items with `#[test]` and `#[bench]` is prohibited for similar expansion order reasons, but this one is going to be reverted much sooner than restrictions on derives.
How to fix broken code (test/bench):
- Enable `#![feature(plugin)]` (don't ask why).
r? @ghost
This is mainly intended for `rustc` developers who want to see a
diagnostic in its original context in the control flow. Two uses
cases for that are:
* `-Z treat-err-as-bug` which then allows extraction of a stack-trace to the origin of the error
(a case that is so important that we make that flag imply this one, effectively).
* `RUST_LOG=... rustc`, in which case it is often useful to see the logging statements that
occurred immediately prior to the point where the diagnostic was signalled.
Drive-by: Added some documentation pointing future devs at
HandlerFlags, and documented the fields of `HandlerFlags` itself.
Make rustc::middle::region::Scope's fields public
This PR makes the following changes to `rustc::middle::region::Scope`:
- [x] Makes `region::Scope`'s fields public
- [x] Removes the `impl Scope` block with constructors (as per [this comment](https://github.com/rust-lang/rust/pull/54032#discussion_r216618208))
- [x] Updates call sites throughout the compiler
Closes#54122.
miri engine: keep around some information for dead allocations
We use it to test if a dangling ptr is aligned and non-NULL. This makes some code pass that should pass (writing a ZST to a properly aligned dangling pointer), and makes some code fail that should fail (writing a ZST to a pointer obtained via pointer arithmetic from a real location, but ouf-of-bounds -- that pointer could be NULL, so we cannot allow writing to it).
CTFE does not allow these operations; tests are added to miri with https://github.com/solson/miri/pull/453.
Improve output if no_lookup_host_duplicates test fails
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.
resolve: Do not error on access to proc macros imported with `#[macro_use]`
This error is artificial, but previously, when `#[macro_use] extern crate x;` was stable, but non-derive proc macros were not, it worked like kind of a feature gate. Now both features are stable, so the error is no longer necessary.
This PR simplifies how `#[macro_use] extern crate x;` works - it takes all items from macro namespace of `x`'s root and puts them into macro prelude from which they all can now be accessed.
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.
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
