Do not ping the infrastructure team on toolstate changes
To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying.
cc rust-lang/infra -- does anyone *want* these notifications?
parse: allow `type Foo: Ord` syntactically
This addresses:
> (Work still remains to fuse this with free type aliases, but this can be done later.)
in https://github.com/rust-lang/rust/pull/69194.
r? @petrochenkov
Do not ping the infrastructure team on toolstate changes
To my knowledge, there is essentially never any particular action that the infra team needs to take on these pings, and they are currently relatively annoying.
cc rust-lang/infra -- does anyone *want* these notifications?
Take advantage of the fact that `check_mod_attrs` marks attributes as
used and change their type to normal, so that any remaining uses will be
warned about by the unused attribute lint.
Prior to this commit, `str` documented that `get_unchecked` had
the precondition that "`begin` must come before `end`". This would appear
to prohibit empty slices (i.e. begin == end).
In practice, get_unchecked is called often with empty slices. Let's relax
the precondition so as to allow them.
Currently, it is only set correctly in the sanity checking implicit
default fallback code. Having a config file at all will for force
`no_std = false`.
Update cargo
11 commits in e02974078a692d7484f510eaec0e88d1b6cc0203..e57bd02999c9f40d52116e0beca7d1dccb0643de
2020-02-18 15:24:43 +0000 to 2020-02-21 20:20:10 +0000
- fix most remaining clippy findings (mostly redundant imports) (rust-lang/cargo#7912)
- Add -Zfeatures tracking issues. (rust-lang/cargo#7917)
- Use rust-lang/rust linkchecker on CI. (rust-lang/cargo#7913)
- Clean up code mostly based on clippy suggestions (rust-lang/cargo#7911)
- Add an option to include crate versions to the generated docs (rust-lang/cargo#7903)
- Better support for license-file. (rust-lang/cargo#7905)
- Add new feature resolver. (rust-lang/cargo#7820)
- Switch azure to macOS 10.15. (rust-lang/cargo#7906)
- Modified the help information of cargo-rustc (rust-lang/cargo#7892)
- Update for nightly rustfmt. (rust-lang/cargo#7904)
- Support `--config path_to_config.toml` cli syntax. (rust-lang/cargo#7901)
Previously, when inserting the entry function, we only checked for
duplicate _definitions_ of `main`. However, it's possible to cause
problems even only having a duplicate _declaration_. For example,
shadowing `main` using an extern block isn't caught by the current
check, and causes an assertion failure down the line in in LLVM code.
Rollup of 7 pull requests
Successful merges:
- #68984 (Make `u8::is_ascii` a stable `const fn`)
- #69339 (Add test for #69312)
- #69346 (Clean up E0323, E0324, E0325 and E0326 explanations)
- #69348 (Wrong error message for move_ref_pattern)
- #69349 (MIR is not an experiment anymore)
- #69354 (Test `Duration::new` panics on overflow)
- #69370 (move const_eval.rs into the module folder)
Failed merges:
r? @ghost
Test `Duration::new` panics on overflow
A `Duration` is created from a second and nanoseconds variable. The
documentation says: "This constructor will panic if the carry from the
nanoseconds overflows the seconds counter". This was, however, not tested
in the tests. I doubt the behavior will ever regress, but it is usually a
good idea to test all documented behavior.
Wrong error message for move_ref_pattern
The current error message states that move occurs *because of `Copy`*:
```Rust
"move occurs because `{}` has type `{}` which does implement the `Copy` trait."
```
I found this randomly when surfing through the sources. This means, I don't have any context and might be completely wrong.
r? @Centril
Make `u8::is_ascii` a stable `const fn`
`char::is_ascii` was already stabilized as `const fn` in #55278, so there is no reason for `u8::is_ascii` to go through an unstable period.
cc @rust-lang/libs
Revert #69280Resolves#69313 by reverting #69280.
After #69280, `#[rustc_args_required_const(2)]` is required on the declaration of `simd_shuffle` intrinsics. This is allowed breakage, since you can't define platform intrinsics on stable. However, the latest release of the widely used `packed_simd` crate defines these intrinsics without the requisite attribute. Since there's no urgency to merge #69280, let's revert it. We can reconsider when rust-lang/packed_simd#278 is included in a point release of `packed_simd`.
r? @petrochenkov
Revert `u8to64_le` changes from #68914.
`SipHasher128`'s `u8to64_le` function was simplified in #68914.
Unfortunately, the new version is slower, because it introduces `memcpy`
calls with non-statically-known lengths.
This commit reverts the change, and adds an explanatory comment (which
is also added to `libcore/hash/sip.rs`). This barely affects
`SipHasher128`'s speed because it doesn't use `u8to64_le` much, but it
does result in `SipHasher128` once again being consistent with
`libcore/hash/sip.rs`.
r? @michaelwoerister
Implement split_inclusive for slice and str
# Overview
* Implement `split_inclusive` for `slice` and `str` and `split_inclusive_mut` for `slice`
* `split_inclusive` is a substring/subslice splitting iterator that includes the matched part in the iterated substrings as a terminator.
* EDIT: The behaviour has now changed, as per @KodrAus 's input, to the same semantics with the `split_terminator` function. I updated the examples below.
* Two examples below:
```Rust
let data = "\nMäry häd ä little lämb\nLittle lämb\n";
let split: Vec<&str> = data.split_inclusive('\n').collect();
assert_eq!(split, ["\n", "Märy häd ä little lämb\n", "Little lämb\n"]);
```
```Rust
let uppercase_separated = "SheePSharKTurtlECaT";
let mut first_char = true;
let split: Vec<&str> = uppercase_separated.split_inclusive(|c: char| {
let split = !first_char && c.is_uppercase();
first_char = split;
split
}).collect();
assert_eq!(split, ["SheeP", "SharK", "TurtlE", "CaT"]);
```
# Justification for the API
* I was surprised to find that stdlib currently only has splitting iterators that leave out the matched part. In my experience, wanting to leave a substring terminator as a part of the substring is a pretty common usecase.
* This API is strictly more expressive than the standard `split` API: it's easy to get the behaviour of `split` by mapping a subslicing operation that drops the terminator. On the other hand it's impossible to derive this behaviour from `split` without using hacky and brittle `unsafe` code. The normal way to achieve this functionality would be implementing the iterator yourself.
* Especially when dealing with mutable slices, the only way currently is to use `split_at_mut`. This API provides an ergonomic alternative that plays to the strengths of the iterating capabilities of Rust. (Using `split_at_mut` iteratively used to be a real pain before NLL, fortunately the situation is a bit better now.)
# Discussion items
* <s>Does it make sense to mimic `split_terminator` in that the final empty slice would be left off in case of the string/slice ending with a terminator? It might do, as this use case is naturally geared towards considering the matching part as a terminator instead of a separator.</s>
* EDIT: The behaviour was changed to mimic `split_terminator`.
* Does it make sense to have `split_inclusive_mut` for `&mut str`?
