Address inconsistency in using "is" with "declared here"
"is" was generally used for NLL diagnostics, but not other diagnostics. Using "is" makes the diagnostics sound more natural and readable, so it seems sensible to commit to them throughout.
r? @Centril
Shrink `Nonterminal`
These commits shrink `Nonterminal` from 240 bytes to 40 bytes. When building `serde_derive` they reduce the number of `memcpy` calls from 9.6M to 7.4M, and it's a tiny win on a few other benchmarks.
r? @petrochenkov
clarify "incorrect issue" error
Changes the message to be more precise, shrinks the span and adds a label specifying why the `issue` field is incorrect.
Change opt-level from 2 back to 3
In Cargo.toml, the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However, rust no longer uses LLVM 7, so this is hopefully no longer needed?
I tried a little bit to replicate the original problem, and could not. I think running this through CI is the best way to smoke test this :) Even if things break dramatically, the comment should be updated to reflect that things are still broken with LLVM 9.
I'm just getting started playing with the compiler, so apologies if I've missed an obvious problem here.
fixes#52378
(possibly relevant is the [current update to LLVM 10](https://github.com/rust-lang/rust/pull/67759))
Previously the debug assertions in the implementation of catch_unwind
used to verify consistency of the panic count by checking that the count
is zero just before leaving the function. This incorrectly assumed that
no panic was in progress when entering `catch_unwind`.
This commit adds guidance for when a user means to type a path, but ends
up typing a single colon, such as `<<Impl as T>:Ty>`.
This change seemed pertinent as the current error message is
particularly misleading, emitting `error: unmatched angle bracket`,
despite the angle bracket being matched later on, leaving the user to
track down the typo'd colon.
Add `Iterator::map_while`
In `Iterator` trait there is `*_map` version of [`filter`] — [`filter_map`], however, there is no `*_map` version of [`take_while`], that can also be useful.
### Use cases
In my code, I've found that I need to iterate through iterator of `Option`s, stopping on the first `None`. So I've written code like this:
```rust
let arr = [Some(4), Some(10), None, Some(3)];
let mut iter = arr.iter()
.take_while(|x| x.is_some())
.map(|x| x.unwrap());
assert_eq!(iter.next(), Some(4));
assert_eq!(iter.next(), Some(10));
assert_eq!(iter.next(), None);
assert_eq!(iter.next(), None);
```
Thit code
1) isn't clean
2) In theory, can generate bad bytecode (I'm actually **not** sure, but I think that `unwrap` would generate additional branches with `panic!`)
The same code, but with `map_while` (in the original PR message it was named "take_while_map"):
```rust
let arr = [Some(4), Some(10), None, Some(3)];
let mut iter = arr.iter().map_while(std::convert::identity);
```
Also, `map_while` can be useful when converting something (as in [examples]).
[`filter`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.filter
[`filter_map`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.filter_map
[`take_while`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.take_while
[examples]: https://github.com/rust-lang/rust/compare/master...WaffleLapkin:iter_take_while_map?expand=1#diff-7e57917f962fe6ffdfba51e4955ad6acR1042
In Cargo.toml, the opt-level for `release` and `bench` was
overridden to be 2. This was to work around a problem with LLVM
7. However, rust no longer uses LLVM 7, so this is no longer
needed.
This creates a small compile time regression in MIR constant eval,
so I've added a #[inline(always)] on the `step` function used in
const eval
Also creates a binary size increase in wasm-stringify-ints-small,
so I've bumped the limit there.
Some code fails when doing a full build but does not fail when only
emitting metadata. This commit makes sure compile_fail tests for such
code behave as expected, that is, the test succeeds because the
compilation fails.
On the backend, rustdoc now emits `paths` entries to a crate's search
index for struct-like enum variants, and index items of type structfield
which belong to such variants point to their variant parents in the
`paths` table, rather than their enum grandparents. The path entry for
a variant is the fully qualified module path plus the enum name.
On the frontend, the search code recognizes structfields belonging to
structlike variants in the `paths` table and re-constructs the URL to
the field's anchor on the enum documentation page.
closes#16017
Move numeric consts to associated consts step1
A subset of #67913. Implements the first step of RFC https://github.com/rust-lang/rfcs/pull/2700
This PR adds the new constants as unstable constants and defines the old ones in terms of the new ones. Then fix a tiny bit of code that started having naming collisions because of the new assoc consts.
Removed a test that did not seem relevant any longer. Since doing just `u8::MIN` should now indeed be valid.
Document `From` implementation for NonZero nums
This is more of a nitpick than a real change in documentation. I did this for consistency with other documentation (namely Atomic integers).
Related to #51430
r? @steveklabnik
PS: I actually tested the code this time. My CPU died in the process, but I get to open a (hopefully 🤞) working PR
Document remaining undocumented `From` implementations for IPs
Some `From` implementations were missing documentation. I added examples, I tried to be as close to existing examples as possible.
Related to #51430 (cc @skade)
r? @steveklabnik
Use termize instead of term_size
`termize` is a fork of `term_size` which uses `winapi` 0.3 instead of 0.2. This is a step towards removing the `winapi` 0.2 dependency.
r? @Mark-Simulacrum
BTreeMap: tag and explain unsafe internal functions or assert preconditions
#68418 concluded that it's not desirable to tag all internal functions with preconditions as being unsafe. This PR does it to some functions, documents why, and elsewhere enforces the preconditions with asserts.
Implement clone_from for BTreeMap and BTreeSet
See #28481. This results in up to 90% speedups on simple data types when `self` and `other` are the same size, and is generally comparable or faster. Some concerns:
1. This implementation requires an `Ord` bound on the `Clone` implementation for `BTreeMap` and `BTreeSet`. Since these structs can only be created externally for keys with `Ord` implemented, this should be fine? If not, there's certainly a less safe way to do this.
2. Changing `next_unchecked` on `RangeMut` to return mutable key references allows for replacing the entire overlapping portion of both maps without changing the external interface in any way. However, if `clone_from` fails it can leave the `BTreeMap` in an invalid state, which might be unacceptable.
~This probably needs an FCP since it changes a trait bound, but (as far as I know?) that change cannot break any external code.~
This commit reduces the size of `Nonterminal` from a whopping 240 bytes
to 72 bytes (on x86-64), which gets it below the `memcpy` threshold.
It also removes some impedance mismatches with `Annotatable`, which
already uses `P` for these variants.
