Pietro Albini [Mon, 24 Feb 2020 10:15:36 +0000 (11:15 +0100)]
Rollup merge of #69405 - NieDzejkob:docs-readline-appends, r=joshtriplett
docs: Stdin::read_line: mention the appending
The fact that `stdin().read_line()` is an [unpleasant](https://twitter.com/Michcioperz/status/1231646797661167617?s=20) [footgun](https://rustbattle.net/battle/straight-finch-8-e4f4). Let's make it clearer in the documentation.
Pietro Albini [Mon, 24 Feb 2020 10:15:33 +0000 (11:15 +0100)]
Rollup merge of #69386 - danielhenrymantilla:maybe_uninit_docs_replace_chunk_with_windows, r=Dylan-DPC
Fix minor error in `MaybeUninit::get_mut()` doc example
In the `MaybeUninit::get_mut()` example I wanted to assert that the slice was sorted and mistakenly used `.chunks(2)` rather than `.windows(2)` to assert it, as @ametisf pointed out in https://github.com/rust-lang/rust/pull/65948#issuecomment-589988183 .
Pietro Albini [Mon, 24 Feb 2020 10:15:31 +0000 (11:15 +0100)]
Rollup merge of #69385 - ridiculousfish:relax_get_unchecked, r=nagisa
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.
Pietro Albini [Mon, 24 Feb 2020 10:15:30 +0000 (11:15 +0100)]
Rollup merge of #69372 - yawpitch:master, r=varkor
Updates links in various Compiler Error Index entries
Currently many of the links in the online https://doc.rust-lang.org/error-index.html are not clickable, and many of them don't resolve correctly as they point to older versions of rustbyexample and the reference.
This PR fully unifies item parsing into a single `fn parse_item_common` method which produces `Option<Item>`. The `Item` is then mapped into `ForeignItem` and `AssocItem` as necessary by transforming the `*Kind` and converting contextually bad variants into `None`, thereby filtering them away.
The PR does not yet unmerge the definition of `ForeignItemKind` from `AssocItemKind`. I've left that as future work as it didn't feel like this parser-focused PR would be the best one to deal with it. Changes to the AST data structures are instead kept to a reasonable minimum.
Based on https://github.com/rust-lang/rust/pull/69361.
Fixes https://github.com/rust-lang/rust/issues/48137.
RELNOTES: Now, `item` macro fragments can be interpolated into `impl`, `trait`, and `extern` contexts. See `src/test/ui/parser/issue-48137-macros-cannot-interpolate-impl-items.rs` for the relevant test.
bors [Sun, 23 Feb 2020 16:09:41 +0000 (16:09 +0000)]
Auto merge of #69084 - yaahc:delayed-doc-lint, r=petrochenkov
Split non macro portion of unused_doc_comment from macro part into two passes/lints
## Motivation
This change is motivated by the needs of the [spandoc library](https://github.com/yaahc/spandoc). The specific use case is that my macro is removing doc comments when an attribute is applied to a fn with doc comments, but I would like the lint to still appear when I forget to add the `#[spandoc]` attribute to a fn, so I don't want to have to silence the lint globally.
## Approach
This change splits the `unused _doc_comment` lint into two lints, `unused_macro_doc_comment` and `unused_doc_comment`. The non macro portion is moved into an `early_lint_pass` rather than a pre_expansion_pass. This allows proc macros to silence `unused_doc_comment` warnings by either adding an attribute to silence it or by removing the doc comment before the early_pass runs.
The `unused_macro_doc_comment` lint however will still be impossible for proc-macros to silence, but the only alternative that I can see is to remove this lint entirely, which I don't think is acceptable / is a decision I'm not comfortable making personally, so instead I opted to split the macro portion of the check into a separate lint so that it can be silenced globally with an attribute if necessary without needing to globally silence the `unused_doc_comment` lint as well, which is still desireable.
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)
jumbatm [Sat, 22 Feb 2020 15:43:47 +0000 (01:43 +1000)]
Fail on multiple declarations of `main`.
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.
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`?
projects / rust.git / log