bors [Sun, 23 Feb 2020 09:40:18 +0000 (09:40 +0000)]
Auto merge of #69336 - Mark-Simulacrum:no-infra-toolstate, r=Dylan-DPC
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?
Dylan DPC [Sun, 23 Feb 2020 08:57:38 +0000 (09:57 +0100)]
Rollup merge of #69336 - Mark-Simulacrum:no-infra-toolstate, r=Dylan-DPC
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?
Tomasz Miąsko [Sun, 23 Feb 2020 00:00:00 +0000 (00:00 +0000)]
Mark attributes consumed by `check_mod_attrs` as normal
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.
ridiculousfish [Sat, 22 Feb 2020 21:28:53 +0000 (13:28 -0800)]
Relax str::get_unchecked precondition to permit empty slicing
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.
John Ericson [Sat, 22 Feb 2020 19:38:38 +0000 (14:38 -0500)]
Allow getting `no_std` from the config file
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`.
bors [Sat, 22 Feb 2020 18:07:03 +0000 (18:07 +0000)]
Auto merge of #69358 - ehuss:update-cargo, r=ehuss
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)
bors [Sat, 22 Feb 2020 14:36:14 +0000 (14:36 +0000)]
Auto merge of #69374 - Dylan-DPC:rollup-x7mjd5z, r=Dylan-DPC
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)
Dylan DPC [Sat, 22 Feb 2020 13:13:07 +0000 (18:43 +0530)]
Rollup merge of #69354 - MichaelMcDonnell:duration_overflow_test, r=Centril
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.
Dylan DPC [Sat, 22 Feb 2020 13:13:04 +0000 (18:43 +0530)]
Rollup merge of #69348 - LeSeulArtichaut:patch-1, r=Centril
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.
bors [Sat, 22 Feb 2020 11:11:47 +0000 (11:11 +0000)]
Auto merge of #69333 - ecstatic-morse:revert-simd-shuffle, r=petrochenkov
Revert #69280
Resolves #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`.
bors [Sat, 22 Feb 2020 07:26:58 +0000 (07:26 +0000)]
Auto merge of #69332 - nnethercote:revert-u8to64_le-changes, r=michaelwoerister
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`.
bors [Sat, 22 Feb 2020 03:54:50 +0000 (03:54 +0000)]
Auto merge of #67330 - golddranks:split_inclusive, r=kodraus
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`?
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.
```
Fix ICE in `missing_errors_doc`
Update License
Migrate Clippy to GitHub Actions
redundant_clone: Migrate to new dataflow framework
Move unneeded_field_pattern to pedantic group
Rustup to rust-lang/rust#69325
Rustup to rust-lang/rust#69072
```
bors [Fri, 21 Feb 2020 06:43:40 +0000 (06:43 +0000)]
Auto merge of #69290 - wesleywiser:speed_up_ctfe_stress_4, r=RalfJung
Check `RUSTC_CTFE_BACKTRACE` much less by generating fewer errors
Before this change, `get_size_and_align()` calls `get_fn_alloc()` *a
lot* in CTFE heavy code. This previously returned an `Error` which would
check if `RUSTC_CTFE_BACKTRACE` was set on construction. Doing this
turned out to be a performance hotspot as @nnethercote discovered in
#68792.
This is an alternate take on that PR which resolves the performance
issue by generating *many* fewer errors. Previously, `ctfe-stress-4`
would generate over 5,000,000 errors each of which would check for the
presence of the environment variable. With these changes, that number is
reduced to 30.
Mark Rousskov [Fri, 21 Feb 2020 00:46:09 +0000 (19:46 -0500)]
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.
`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`.
bors [Thu, 20 Feb 2020 22:44:01 +0000 (22:44 +0000)]
Auto merge of #69072 - ecstatic-morse:associated-items, r=petrochenkov
O(log n) lookup of associated items by name
Resolves #68957, in which compile time is quadratic in the number of associated items. This PR makes name lookup use binary search instead of a linear scan to improve its asymptotic performance. As a result, the pathological case from that issue now runs in 8 seconds on my local machine, as opposed to many minutes on the current stable.
Currently, method resolution must do a linear scan through all associated items of a type to find one with a certain name. This PR changes the result of the `associated_items` query to a data structure that preserves the definition order of associated items (which is used, e.g., for the layout of trait object vtables) while adding an index of those items sorted by (unhygienic) name. When doing name lookup, we first find all items with the same `Symbol` using binary search, then run hygienic comparison to find the one we are looking for. Ideally, this would be implemented using an insertion-order preserving, hash-based multi-map, but one is not readily available.
Someone who is more familiar with identifier hygiene could probably make this better by auditing the uses of the `AssociatedItems` interface. My goal was to preserve the current behavior exactly, even if it seemed strange (I left at least one FIXME to this effect). For example, some places use comparison with `ident.modern()` and some places use `tcx.hygienic_eq` which requires the `DefId` of the containing `impl`. I don't know whether those approaches are equivalent or which one should be preferred.