Regression test for #54478.
This is a regression test for #54478.
I confirmed that it fails on:
rustdoc 1.30.0-beta.12 (96a229824 2018-10-04)
and passes on:
rustdoc 1.31.0-nightly (f99911a4a 2018-10-23)
Fix#54478
Set RUST_BACKTRACE=0 for rustdoc-ui/failed-doctest-output.rs
This UI test is sensitive to backtrace output, so it should make sure
that backtraces are not enabled by the environment.
Do some copy editing on the release notes
I was reading through the release notes to find something and noticed
some small grammatical and consistency issues.
I'm happy to revert any of these changes if folks disagree with them!
only issue "variant of the expected type" suggestion for enums
This suggestion (introduced in pull-request #43178 / eac74104) was being issued for one-field-struct expected types (in which case it is misleading and outright wrong), even though it was only intended for one-field enum-variants (most notably, `Some`).
Add a conditional to adhere to the original intent. (It would be possible to generalize to structs, but not obviously net desirable.) This adds a level of indentation, so the diff here is going to be
easier to read in [ignore-whitespace mode](https://github.com/rust-lang/rust/commit/b0d3d3b9?w=1).
Resolves#55250.
r? @pnkfelix
Clarified code example in char primitive doc
The example was not as clear as it could be because it was making an assumption about the structure of the data in order to multiply the number of elements in the slice by the item size. This change demonstrates the idea more straightforwardly, without needing a calculation, by just comparing the size of the slices.
submodules: update clippy from 5afdf8b7 to b1d03437
Just a routine update.
Changes:
````
new_ret_no_self: add sample from #3313 to Known Problems section.
Support multiline comments and hopefully fix panic
Check for comments in collapsible ifs
Resolve ICE in needless range loop lint
RIIR update_lints: Update changelog links
Rename if_let_redundant_pattern_matching to redundant_pattern_matching
Add lint for redundant pattern matching for explicit return boolean
Fix issue #3322: reword help message for len_zero
Simplify manual_memcpy suggestion in some cases
Fix dogfood
Update known problems for unnecessary_fold
RIIR update_lints: Replace lint count in README.md
Rename `active_lints` to `usable_lints`
Add comment on WalkDir vs. fs::read_dir
sort_by -> sort_by_key
Some more documentation for clippy_dev
Use `WalkDir` to also gather from subdirectories
Avoid linting `boxed_local` on trait implementations.
Website: Make lint categories linkable
Restore clippy_dummy's placeholder name
Swap order of methods in `needless_range_loop` suggestion in some cases
Revert "Exclude pattern guards from unnecessary_fold lint"
Exclude pattern guards from unnecessary_fold lint
````
Documents `From` implementations for `Stdio`
This PR solves part of #51430 by adding a basic summary and an example to each `impl From` inside `process` module (`ChildStdin`, `ChildStdout`, `ChildStderr`, `File`).
It does not document if the conversions allocate memory and how expensive they are.
Suggest appropriate syntax on missing lifetime specifier in return type
Suggest using `'static` when a lifetime is missing in the return type
with a structured suggestion instead of a note.
Fix#55170.
in which unused-parens suggestions heed what the user actually wrote
Aaron Hill pointed out that unnecessary parens around a macro call (paradigmatically, `format!`) yielded a suggestion of hideous macro-expanded code. `span_to_snippet` is fallable as far as the type system is concerned, so the pretty-printing can live on in the oft-neglected `else` branch.
Resolves#55109.
Gradually expanding libstd's keyword documentation
I'm working on adding new keywords to the documentation and refreshing the incomplete older ones, and I'm hoping that I can eventually add all the standalone-usable keywords after a bunch of incremental work. It would be cool to see the keywords section of std's docs be a definitive reference as to what each keyword means when you see it, and that's what I'm aiming towards with this work.
I'm far from a Rust expert so there will inevitably be things to fix in this, also I'm not sure if this should be a bunch of quickly-merged PRs or one gradually-updated PR that gets merged once it's done.
Add `extern crate` items to extern prelude
With this patch each `extern crate orig_name as name` item adds name `name` into the extern prelude, as if it was passed with `--extern`.
What changes this causes in practice?
Almost none! After all, `--extern` passed from Cargo was supposed to replace `extern crate` items in source, so if some code has `extern crate` item (or had it on 2015 edition), then it most likely uses `--extern` as well...
... with exception of a few important cases.
- Crates using `proc_macro`. `proc_macro` is not passed with `--extern` right now and is therefore not in extern prelude.
Together with 2018 edition import behavior this causes problems like https://github.com/rust-lang/rust/issues/54418, e.g.
```rust
extern crate proc_macro;
use proc_macro::TokenStream;
```
doesn't work.
It starts working after this patch.
- `#[no_std]` crates using `std` conditionally, like @aturon described in https://github.com/rust-lang/rust/issues/53166#issuecomment-425219286, and still wanting to write `std` instead of `crate::std`. This PR covers that case as well.
This allows us to revert placing `std` into the extern prelude unconditionally, which was, I think, a [bad idea](https://github.com/rust-lang/rust/issues/53166#issuecomment-425117829).
- Later `extern crate` syntax can be extended to support adding an alias to some local path to extern prelude, as it may be required for resolving https://github.com/rust-lang/rust/issues/54647.
Notes:
- Only `extern crate` items from the root module added to the prelude, mostly because this behavior for items from inner modules would look very strange, rather than for technical reasons.
This means you can opt out from the prelude additions with something like
```rust
mod inner {
pub(crate) extern crate foo;
}
use inner::foo;
```
- I haven't updated logic for 2018 import canaries to work fully correctly with this. The cases where it matters are pretty exotic (the `extern crate` item must be "sufficiently macro expanded") and I'd rather spend the time on eliminating the canaries entirely.
enforce user annotations in closure signatures
Not *quite* ready yet but I'm opening anyway. Still have to finish running tests locally.
Fixes#54692Fixes#54124
r? @matthewjasper
This fixes `issue-28848.rs` -- it also handles another case that the
AST region checker gets wrong (`wf-self-type.rs`). I don't actually
think that this is the *right way* to be enforcing this constraint --
I think we should probably do it more generally, perhaps by editing
`predicates_of` for the impl itself. The chalk-style implied bounds
setup ought to fix this.
#45829 when a renamed import conflict with a previous import
Fix the suggestion when a renamed import conflict.
It check if the snipped contains `" as "`, and if so uses everything before for the suggestion.
