Auto merge of #60128 - jimblandy:futures-doc-fix, r=withoutboats
Doc fixes for core::future::Future.
Fixed outdated reference to `waker` argument; now futures are passed a
`Context`, from which one can obtain a `waker`.
Cleaned up explanation of what happens when you call `poll` on a completed
future. It doesn't make sense to say that `poll` implementations can't cause
memory unsafety; no safe function is ever allowed to cause memory unsafety, so
why mention it here? It seems like the intent is to say that the `Future` trait
doesn't say what the consequences of excess polls will be, and they might be
bad; but that the usual constraints that Rust imposes on any non-`unsafe`
function still apply. It's also oddly specific to say 'memory corruption'
instead of just 'undefined behavior'; UB is a bit jargony, so the text should
provide examples.
Jim Blandy [Sat, 20 Apr 2019 02:10:24 +0000 (19:10 -0700)]
Doc fixes for core::future::Future.
Fixed outdated reference to `waker` argument; now futures are passed a
`Context`, from which one can obtain a `waker`.
Cleaned up explanation of what happens when you call `poll` on a completed
future. It doesn't make sense to say that `poll` implementations can't cause
memory unsafety; no safe function is ever allowed to cause memory unsafety, so
why mention it here? It seems like the intent is to say that the `Future` trait
doesn't say what the consequences of excess polls will be, and they might be
bad; but that the usual constraints that Rust imposes on any non-`unsafe`
function still apply. It's also oddly specific to say 'memory corruption'
instead of just 'undefined behavior'; UB is a bit jargony, so the text should
provide examples.
Changes:
````
Update compiletest_rs
Typo
Fix dogfood error
Add lint PathBufPushOverwrite
Update *.stderr file
Remove code duplication
Format code
Add test for debug_assert!(false)
Don't lint debug_assert!(false)
Add run-rustfix for option_map_or_none lint
Move two cast_lossless tests to their correct files
Change naive_bytecount applicability MaybeIncorrect
Add tests for declare_lint_pass and impl_lint_pass
Use lint pass macros
Document `declare_lint_pass!`
Fix lint_without_lint_pass internal lint
Use {get,match}_def_path from LateContext
Remove uplifted functions {get,match}_def_path from Clippy
Add run-rustfix for len_zero lint
Add run-rustfix for bool_comparison lint
Add run-rustfix for deref_addrof lint
while_let_loop uses placeholders in suggestions
Remove rust-toolchain file from clippy_dev
Update adding_lints.md
Update PULL_REQUEST_TEMPLATE
Add new lint checklist
Create PULL_REQUEST_TEMPLATE
Only suggest .copied() for Option right now
Also suggest .copied() when .clone() is called on a Copy type
Suggest .copied() instead of .cloned() in map_clone when dealing with references
Deny rustc internal lints
Remove clippy::default_hash_types internal lint
Enable -Zunstable-options in .cargo/config
````
Changes:
````
Update compiletest_rs
Typo
Fix dogfood error
Add lint PathBufPushOverwrite
Update *.stderr file
Remove code duplication
Format code
Add test for debug_assert!(false)
Don't lint debug_assert!(false)
Add run-rustfix for option_map_or_none lint
Move two cast_lossless tests to their correct files
Change naive_bytecount applicability MaybeIncorrect
Add tests for declare_lint_pass and impl_lint_pass
Use lint pass macros
Document `declare_lint_pass!`
Fix lint_without_lint_pass internal lint
Use {get,match}_def_path from LateContext
Remove uplifted functions {get,match}_def_path from Clippy
Add run-rustfix for len_zero lint
Add run-rustfix for bool_comparison lint
Add run-rustfix for deref_addrof lint
while_let_loop uses placeholders in suggestions
Remove rust-toolchain file from clippy_dev
Update adding_lints.md
Update PULL_REQUEST_TEMPLATE
Add new lint checklist
Create PULL_REQUEST_TEMPLATE
Only suggest .copied() for Option right now
Also suggest .copied() when .clone() is called on a Copy type
Suggest .copied() instead of .cloned() in map_clone when dealing with references
Deny rustc internal lints
Remove clippy::default_hash_types internal lint
Enable -Zunstable-options in .cargo/config
````
Auto merge of #60072 - RalfJung:linked-list, r=shepmaster
fix LinkedList invalidating mutable references
The test `test_insert_prev` failed in Miri due to what I consider a bug in `LinkedList`: in various places, `NonNull::as_mut` got called to modify the `prev`/`next` pointers of existing nodes. In particular, the unstable `insert_next` has to modify the `next` pointer of the node that was last handed out by the iterator; to this end it creates a mutable reference to the *entire node* that overlaps with the mutable reference to the node's content that was handed out by the iterator! Thus, the next use if said mutable reference is UB.
In code:
```rust
loop {
match it.next() { // mutable reference handed to us
None => break,
Some(elt) => {
it.insert_next(*elt + 1); // this invalidates `elt` because it creates an overlapping mutable reference
match it.peek_next() {
Some(x) => assert_eq!(*x, *elt + 2), // this use of `elt` now is a use of an invalid pointer
None => assert_eq!(8, *elt),
}
}
}
}
```
This PR fixes that by using `as_ptr` instead of `as_mut`. This avoids invalidating the mutable reference that was handed to the user. I did this in all methods called by iterators, just to be sure.
Auto merge of #60077 - RalfJung:miri-alloc-tests, r=joshtriplett
make liballoc internal test suite mostly pass in Miri
I discovered, to my surprise, that liballoc has two test suites: `liballoc/tests`, and a bunch of stuff embedded directly within liballoc. The latter was not covered by [miri-test-libstd](https://github.com/RalfJung/miri-test-libstd) yet. This disables in Miri the tests that Miri cannot support or runs too slowly.
Auto merge of #60104 - Centril:rollup-7vmae1a, r=Centril
Rollup of 16 pull requests
Successful merges:
- #59915 (Implement event filtering for self-profiler.)
- #59933 (Make clear that format padding doesn't work for Debug)
- #60023 (implement specialized nth_back() for Bytes, Fuse and Enumerate)
- #60032 (Remove unwanted z-index change)
- #60041 (Simplify the returning of a Result a bit)
- #60045 (Suggest appropriate path when calling associated item on bare types)
- #60052 (Correct unused parameter diagnostic)
- #60056 (Update rustfmt to 1.2.1)
- #60060 (whitelist RTM x86 target cpu feature)
- #60061 (Change suggestion of field when not in self context)
- #60064 (Point at try `?` on errors affecting the err match arm of the desugared code)
- #60078 (Use more realistic example for thread builder)
- #60080 (Fix small errors in docs for `rchunks_exact` and `rchunks_exact_mut`.)
- #60082 (Update miri)
- #60097 (Use -mergefunc-use-aliases for any LLVM >= 8)
- #60098 (libcore: deny `elided_lifetimes_in_paths`)
Rollup merge of #60097 - cuviper:llvm8-mergefunc-use-aliases, r=rkruppe
Use -mergefunc-use-aliases for any LLVM >= 8
This functionality is not specific to Rust's LLVM, but any starting in LLVM 8.0,
as noted in <https://github.com/rust-lang/rust/pull/56358#discussion_r237702197>.
Rollup merge of #60060 - mtak-:rtm-x86-feature, r=petrochenkov
whitelist RTM x86 target cpu feature
This PR adds support for intels restricted transactional memory cpu feature. I mostly copied what was done for the [movbe](https://github.com/rust-lang/rust/pull/57999) feature.
Rollup merge of #60045 - estebank:suggest-std, r=petrochenkov
Suggest appropriate path when calling associated item on bare types
When looking at the documentation for `std::f32` or `std::str`, for
example, it is easy to get confused and assume `std::f32` and `f32`
are the same thing. Because of this, it is not uncommon to attempt
writing `f32::consts::PI` instead of the correct
`std::f32::consts::PI`. When encountering the former, which results
in an access error due to it being an inexistent path, try to access
the same path under `std`. If this succeeds, this information is
stored for later tweaking of the final E0599 to provide an
appropriate suggestion.
Rollup merge of #59915 - michaelwoerister:sp-event-filters-1, r=wesleywiser
Implement event filtering for self-profiler.
This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from https://github.com/rust-lang/rust/pull/59515 and, for the moment, is meant for performance testing.
Suggest appropriate path when calling associated item on bare types
When looking at the documentation for `std::f32` or `std::str`, for
example, it is easy to get confused and assume `std::f32` and `f32`
are the same thing. Because of this, it is not uncommon to attempt
writing `f32::consts::PI` instead of the correct
`std::f32::consts::PI`. When encountering the former, which results
in an access error due to it being an inexistent path, try to access
the same path under `std`. If this succeeds, this information is
stored for later tweaking of the final E0599 to provide an
appropriate suggestion.
This suggestion applies to both E0233 and E0599 and is only checked
when the first ident of a path corresponds to a primitive type.
Rollup merge of #60037 - eddyb:actually-its-param, r=estebank
Resolve inconsistency in error messages between "parameter" and "variable".
The inconsistency was introduced in 104fe1c4db24f860b890dfd25577f23ee111279a (#33619), when a label saying `type variable` was added to an error with a message talking about `type parameters`.
Given that `parameter` is far more prevalent when referring to generics in the context of Rust, IMO it should be that in both the message and the label.
Rollup merge of #59984 - gluyas:collections-with_capacity-doc-fix, r=rkruppe
Remove collection-specific `with_capacity` documentation from `std::collections`
Fixes #59931
The style of `std::collections` module doc is very much a beginner friendly guide, and documenting niche, collection-specific behaviour feels out of place, if not brittle.
The note about `VecDeque` is outdated (see issue), and while `Vec` probably won't change its guarantees any time soon, the users who are interested in its allocation properties will find that in its own documentation.
Auto merge of #59527 - matklad:sized-index, r=Centril
Add test checking that Index<T: ?Sized> works
I've noticed that we have an `Idx: ?Sized` bound on the **index** in the `Index`, which seems strange given that we accept index by value. My guess is that it was meant to be removed in https://github.com/rust-lang/rust/pull/23601, but was overlooked.
If I remove this bound, `./x.py src/libstd/ src/libcore/` passes, which means at least that this is not covered by test.
I think there's three things we can do here:
* run crater with the bound removed to check if there are any regressions, and merge this, to be consistent with other operator traits
* run crater, get regressions, write a test for this with a note that "hey, we tried to fix it, its unfixable"
* decide, in the light of by-value DSTs, that this is a feature rather than a bug, and add a test
cc @rust-lang/libs
EDIT: the forth alternative is that there exist a genuine reason why this is the case, but I failed to see it :D
projects / rust.git / log