| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This includes the following stabilizations:
- tcpstream_connect_timeout https://github.com/rust-lang/rust/pull/44563
- iterator_for_each https://github.com/rust-lang/rust/pull/44567
- ord_max_min https://github.com/rust-lang/rust/pull/44593
- compiler_fences https://github.com/rust-lang/rust/pull/44595
- needs_drop https://github.com/rust-lang/rust/pull/44639
- vec_splice https://github.com/rust-lang/rust/pull/44640
|
|
|
|
|
|
|
|
|
|
updated clippy and rls as it uses the iterator_for_each
|
|
|
|
It's going to be backported to beta.
|
|
|
|
|
|
Fix inconsistent doc headings
This fixes headings reading "Unsafety" and "Example", they should be "Safety" and "Examples" according to RFC 1574.
r? @steveklabnik
|
|
Fixes #41701.
|
|
Add [T]::swap_with_slice
The safe version of a method from `ptr`, like `[T]::copy_from_slice` is.
Tracking issue: https://github.com/rust-lang/rust/issues/44030
|
|
This fixes headings reading "Unsafety" and "Example", they should be
"Safety" and "Examples" according to RFC 1574.
|
|
The safe version of a method from ptr, like [T]::copy_from_slice
|
|
Generate builtin impls for `Clone`
This fixes a long-standing ICE and limitation where some builtin types implement `Copy` but not `Clone` (whereas `Clone` is a super trait of `Copy`).
However, this PR has a few side-effects:
* `Clone` is now marked as a lang item.
* `[T; N]` is now `Clone` if `T: Clone` (currently, only if `T: Copy` and for `N <= 32`).
* `fn foo<'a>() where &'a mut (): Clone { }` won't compile anymore because of how bounds for builtin traits are handled (e.g. same thing currently if you replace `Clone` by `Copy` in this example). Of course this function is unusable anyway, an error would pop as soon as it is called.
Hence, I'm wondering wether this PR would need an RFC...
Also, cc-ing @nikomatsakis, @arielb1.
Related issues: #28229, #24000.
|
|
Fix typo in doc
|
|
Missing links
r? @rust-lang/docs
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/39294.
|
|
|
|
r=QuietMisdreavus
Fixed typo in RefCell::get_mut
"[...] is usually not you want." => "[...] is usually not what you want."
|
|
Document that `std::hash::Hasher::finish()` does not reset the hasher.
Clarifies the fact that `finish()` doesn’t in fact end or reset the hasher. This was surprising to me …
Follows up on and fixes #43763
|
|
Fix typos & us spellings
Fixing some typos and non en-US spellings.
(Update of PR https://github.com/rust-lang/rust/pull/42812 )
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
Add missing newline in Deref docs to fix rendering
Fixes #43866.
(Verified locally.)
r? @steveklabnik
|
|
Fixes #43866.
|
|
Implement `RefCell::replace` and `RefCell::swap`
Tracking issue: #43570
|
|
Fixes #28229.
Fixes #24000.
|
|
Don't inline debug methods
The inner methods aren't inlined, so this puts more pressure on LLVM for
literally no benefit.
Closes #43843
|
|
The inner methods aren't inlined, so this puts more pressure on LLVM for
literally no benefit.
Closes #43843
|
|
Fix for issue #39827
*Cause of the issue*
While preparing for `trans_intrinsic_call()` invoke arguments are processed with `trans_argument()` method which excludes zero-sized types from argument list (to be more correct - all arguments for which `ArgKind` is `Ignore` are filtered out). As result `volatile_store()` intrinsic gets one argument instead of expected address and value.
*How it is fixed*
Modification of the `trans_argument()` method may cause side effects, therefore change was implemented in `volatile_store()` intrinsic building code itself. Now it checks function signature and if it was specialised with zero-sized type, then emits `C_nil()` instead of accessing non-existing second argument.
|
|
- removes warnings introduced in changeset 0cd3587
- makes documentation more neat and grammatically correct
|
|
Fix some typos
Follow up of #43794
If refined my script a little bit and found some more.
|
|
Improve std::ops docs
Fixes #29365. (This fixes all but one point from @steveklabnik's list, but that point was referring to examples of implementing range traits, but there are no range traits in std::ops.)
The main changes are quite a bit of copyediting, adding more "real" examples for some of the traits, incorporating some guidance from the API docs, more linking (cross-docs and to the book & reference), cleaning up examples, moving things around, and so on. Refer to the commit messages for more details.
Note: I decided to link to the second edition of the book since I think it's more appropriate now for the sections I linked, if this is not okay, please say so!
|
|
* fixed link typos and copy-paster errors
* rewrote Fn* explanations
* `RHS = Self` -> `RHS` is `Self` (added that to all applicable places as
well)
* fixed up some links
* s/MutDeref/DerefMut
* removed remaining superfluous `fn main()`s
* fixed some minor phrasings and factual errors and inaccuracies
std::ops docs: Fix phrasing and factual errors/inaccuracies
|
|
|
|
- updates documentation on volatile memory intrinsics, now the case of
zero-sized types is mentioned explicitly.
Volatile memory operations which doesn't affect memory at all are omitted
in LLVM backend, e.g. if number of elements is zero or type used in
generic specialisation is zero-sized, then LLVM intrinsic or related code
is not generated. This was not explicitly documented before in Rust
documentation and potentially could cause issues.
|
|
Fix some typos
I wrote a really naive script and found those typos in the documentation.
|
|
Put `intrinsics::unreachable` on a possible path to stabilization
Mark it with the `unreachable` feature and put it into the `mem` module.
This is a pretty straight-forward API that can already be simulated in
stable Rust by using `transmute` to create an uninhabited enum that can
be matched.
|
|
|
|
|
|
|
|
Fixed mutable vars being marked used when they weren't
#### NB : bootstrapping is slow on my machine, even with `keep-stage` - fixes for occurances in the current codebase are <s>in the pipeline</s> done. This PR is being put up for review of the fix of the issue.
Fixes #43526, Fixes #30280, Fixes #25049
### Issue
Whenever the compiler detected a mutable deref being used mutably, it marked an associated value as being used mutably as well. In the case of derefencing local variables which were mutable references, this incorrectly marked the reference itself being used mutably, instead of its contents - with the consequence of making the following code emit no warnings
```
fn do_thing<T>(mut arg : &mut T) {
... // don't touch arg - just deref it to access the T
}
```
### Fix
Make dereferences not be counted as a mutable use, but only when they're on borrows on local variables.
#### Why not on things other than local variables?
* Whenever you capture a variable in a closure, it gets turned into a hidden reference - when you use it in the closure, it gets dereferenced. If the closure uses the variable mutably, that is actually a mutable use of the thing being dereffed to, so it has to be counted.
* If you deref a mutable `Box` to access the contents mutably, you are using the `Box` mutably - so it has to be counted.
|
|
Avoid calling the column!() macro in panic
Closes #43057
This "fix" adds a new macro called `__rust_unstable_column` and to use it instead of the `column` macro inside panic. The new macro can be shadowed as well as `column` can, but its very likely that there is no code that does this in practice.
There is no real way to make "unstable" macros that are usable by stable macros, so we do the next best thing and prefix the macro with `__rust_unstable` to make sure people recognize it is unstable.
r? @alexcrichton
|
|
#[must_use] for functions
This implements [RFC 1940](https://github.com/rust-lang/rfcs/pull/1940).
The RFC and discussion thereof seem to suggest that tagging `PartialEq::eq` and friends as `#[must_use]` would automatically lint for unused comparisons, but it doesn't work out that way (at least the way I've implemented it): unused `.eq` method calls get linted, but not `==` expressions. (The lint operates on the HIR, which sees binary operations as their own thing, even if they ultimately just call `.eq` _&c._.)
What do _you_ think??
Resolves #43302.
|
|
Add an overflow check in the Iter::next() impl for Range<_> to help with vectorization.
This helps with vectorization in some cases, such as (0..u16::MAX).collect::<Vec<u16>>(),
as LLVM is able to change the loop condition to use equality instead of less than and should help with #43124. (See also my [last comment](https://github.com/rust-lang/rust/issues/43124#issuecomment-319098625) there.) This PR makes collect on ranges of u16, i16, i8, and u8 **significantly** faster (at least on x86-64 and i686), and pretty close, though not quite equivalent to a [manual unsafe implementation](https://is.gd/nkoecB). 32 ( and 64-bit values on x86-64) bit values were already vectorized without this change, and they still are. This PR doesn't seem to help with 64-bit values on i686, as they still don't vectorize well compared to doing a manual loop.
I'm a bit unsure if this was the best way of implementing this, I tried to do it with as little changes as possible and avoided changing the step trait and the behavior in RangeFrom (I'll leave that for others like #43127 to discuss wider changes to the trait). I tried simply changing the comparison to `self.start != self.end` though that made the compiler segfault when compiling stage0, so I went with this method instead for now.
As for `next_back()`, reverse ranges seem to optimise properly already.
|
