The docs currently say, "If the closure returns false, it will try again, and call the closure on the next element." But this happens regardless of whether the closure returns true or false.
Rollup merge of #48221 - rkruppe:improve-ctypes-lint, r=estebank
Overhaul improper_ctypes output
This snowballed into a rather big set of improvements to the diagnostics of the improper_ctypes lint. See commits for details, including effects of each change on the `compile-fail/improper-ctypes.rs` test (now a UI test), which is pretty gnarly and hopefully not representative of real code, but covers a lot of different error cases.
Rollup merge of #48157 - scottmcm:try-for-each, r=dtolnay
Add Iterator::try_for_each
The fallible version of `for_each` aka the stateless version of `try_fold`. Inspired by @cuviper's comment in https://github.com/rust-lang/rust/pull/45379#issuecomment-338370020 as a more direct and obvious solution than `.map(f).collect::<Result<(), _>>()`.
Like `for_each`, no need for an `r` version thanks to overrides in `Rev`.
Rollup merge of #48123 - nikomatsakis:issue-47244-expected-num-args, r=estebank
detect wrong number of args when type-checking a closure
Instead of creating inference variables for those argument types, use
the trait error-reporting code to give a nicer error. This also
improves some other spans for existing tests.
bors [Fri, 23 Feb 2018 11:21:29 +0000 (11:21 +0000)]
Auto merge of #47799 - topecongiro:fix-span-of-visibility, r=petrochenkov
Fix span of visibility
This PR
1. adds a closing parenthesis to the span of `Visibility::Crate` (e.g. `pub(crate)`). The current span only covers `pub(crate`.
2. adds a `span` field to `Visibility::Restricted`. This span covers the entire visibility expression (e.g. `pub (in self)`). Currently all we can have is a span for `Path`.
This PR is motivated by the bug found in rustfmt (https://github.com/rust-lang-nursery/rustfmt/issues/2398).
The first change is a strict improvement IMHO. The second change may not be desirable, as it adds a field which is currently not used by the compiler.
Matt Brubeck [Thu, 22 Feb 2018 20:05:30 +0000 (12:05 -0800)]
[docs] Minor wording changes to drain_filter docs
The docs currently say, "If the closure returns false, it will try
again, and call the closure on the next element." But this happens
regardless of whether the closure returns true or false.
Guillaume Gomez [Wed, 21 Feb 2018 15:29:53 +0000 (16:29 +0100)]
Rollup merge of #48352 - JakubAdamWieczorek:mailmap, r=petrochenkov
Update .mailmap with my real name
Good morning, the Rust team!
Once upon a time I was a modest-scale contributor. Sadly, various turbulences made me step away from my participation in the project. It's great to see how far it's gone.
I would appreciate it if you accepted this small change to the .mailmap file so that it shows my real name as back then I was using an alias. If doubts arise if I am the same person, I will be happy to provide further evidence. :)
Gated on https://github.com/rust-lang/rust/pull/48095 - I based the branch atop that so i could show off the change in one of its tests, the actual change in this PR is just the last commit
There are a handful of unfortunate assumptions in the way rustdoc processes `extern crate` statements in doctests:
1. In the absence of an `extern crate` statement in the test, if the test also uses the local crate name, it will automatically insert an `extern crate cratename;` statement into the test.
2. If the doctest *does* include an `extern crate` statement, rustdoc will not automatically insert one, on the assumption that doing so would introduce a duplicate import.
3. If a doctest does not have the substring `fn main` outside a comment, rustdoc will wrap the whole doctest in a generated `fn main` so it can be compiled.
In short, whenever you write a doctest like this...
This creates issues when compiled, because now `my_crate` isn't even properly in scope! This forces people who want to have multiple crates in their doctests (or an explicit `extern crate` statement) to also manually include their own `fn main`, so rustdoc doesn't put their imports in the wrong place.
This PR just taps into another processing step rustdoc does to doctests: Whenever you add an `#![inner_attribute]` to the beginning of a doctest, rustdoc will actually splice those out and put it before the generated `fn main`. Now, we can just do the same with `extern crate`s at the beginning, too, and get a much nicer experience.
Now, the above example will be converted into this:
Guillaume Gomez [Wed, 21 Feb 2018 15:29:46 +0000 (16:29 +0100)]
Rollup merge of #47833 - Aaron1011:final_auto_trait, r=GuillaumeGomez
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any synthetic implementations for auto traits. Currently, this is only done for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types which automatically implement the trait. Effectively, this is a list of all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take generic bounds into account. For example, a type
```rust
struct Foo<T>(T)
```
will have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
```rust
struct Foo<T>(T)
struct Wrapper<T>(Foo<T>)
unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes this sound somehow
```
Then Wrapper will have the following impl generated:
```rust
impl<T> Send for Wrapper<T>
```
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send' to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are taken into account by synthetic impls:
However, if a type can *never* implement a particular auto trait (e.g. `struct MyStruct<T>(*const T)`), then a negative impl will be generated (in this case, `impl<T> !Send for MyStruct<T>`)
All of this means that a user should be able to copy-paste a syntheticimpl into their code, without any observable changes in behavior (assuming the rest of the program remains unchanged).
Take 2^5 as examples in document of pow() (fixes #48396)
Current document takes 2^4, which is equal to 4^2.
This example is not very helpful for those unfamiliar with math words in English and thus rely on example codes.
Aaron Hill [Wed, 22 Nov 2017 21:16:55 +0000 (16:16 -0500)]
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
bors [Sun, 18 Feb 2018 06:02:35 +0000 (06:02 +0000)]
Auto merge of #47687 - SimonSapin:panic-impl, r=sfackler
RFC 2070 part 1: PanicInfo and Location API changes
This implements part of https://rust-lang.github.io/rfcs/2070-panic-implementation.html
Tracking issue: https://github.com/rust-lang/rust/issues/44489
* Move `std::panic::PanicInfo` and `std::panic::Location` to a new `core::panic` module. The two types and the `std` module were already `#[stable]` and stay that way, the new `core` module is `#[unstable]`.
* Add a new `PanicInfo::message(&self) -> Option<&fmt::Arguments>` method, which is `#[unstable]`.
* Implement `Display` for `PanicInfo` and `Location`
projects / rust.git / log