| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Move "See also" disambiguation links for primitive types to top
Closes #50384.
<details>
<summary>Images</summary>
</details>
r? @steveklabnik
|
|
add fn `into_inner(self) -> (Idx, Idx)` to RangeInclusive (#49022)
adds `into_inner(self) -> (Idx, Idx)` to RangeInclusive
https://github.com/rust-lang/rust/issues/49022#issuecomment-387645176
|
|
Give SliceIndex impls a test suite of girth befitting the implementation (and fix a UTF8 boundary check)
So one day I was writing something in my codebase that basically amounted to `impl SliceIndex for (Bound<usize>, Bound<usize>)`, and I said to myself:
*Boy, gee, golly! I never realized bounds checking was so tricky!*
At some point when I had around 60 lines of tests for it, I decided to go see how the standard library does it to see if I missed any edge cases. ...That's when I discovered that libcore only had about 40 lines of tests for slicing altogether, and none of them even used `..=`.
---
This PR includes:
* **Literally the first appearance of the word `get_unchecked_mut` in any directory named `test` or `tests`.**
* Likewise the first appearance of `get_mut` used with _any type of range argument_ in these directories.
* Tests for the panics on overflow with `..=`.
* I wanted to test on `[(); usize::MAX]` as well but that takes linear time in debug mode </3
* A horrible and ugly test-generating macro for the `should_panic` tests that increases the DRYness by a single order of magnitude (which IMO wasn't enough, but I didn't want to go any further and risk making the tests inaccessible to next guy).
* Same stuff for str!
* Actually, the existing `str` tests were pretty good. I just helped filled in the holes.
* [A fix for the bug it caught](https://github.com/rust-lang/rust/issues/50002). (only one ~~sadly~~)
|
|
|
|
|
|
Add some explanations for #[must_use]
`#[must_use]` can be given a string argument which is shown whilst warning for things.
We should add a string argument to most of the user-exposed ones.
I added these for everything but the operators, mostly because I'm not sure what to write there or if we need anything there.
|
|
Remove some transmutes
|
|
turn `ManuallyDrop::new` into a constant function
|
|
Add more logarithm constants
Right now, we have `ln(2)` and `ln(10)`, but only `log2(e)` and `log10(e)`. This also adds `log2(10)` and `log10(2)` for consistency.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Suggested by @dylanede at <https://github.com/rust-lang/rust/issues/49150#issuecomment-381071442>.
|
|
As discussed at [1] §3 and [2] and [3], a formal look at pinning requires considering a
distinguished "shared pinned" mode/typestate. Given that, it seems desirable to
at least eventually actually expose that typestate as a reference type. This
renames Pin to PinMut, freeing the name Pin in case we want to use it for a
shared pinned reference later on.
[1] https://www.ralfj.de/blog/2018/04/10/safe-intrusive-collections-with-pinning.html
[2] https://github.com/rust-lang/rfcs/pull/2349#issuecomment-379250361
[3] https://github.com/rust-lang/rust/issues/49150#issuecomment-380488275
|
|
|
|
|
|
|
|
|
|
|
|
All other tests of libcore reside in the tests/ directory,
too. Apparently the tests of `time.rs` weren't run before, at
least not by `x.py test src/libcore`.
|
|
|
|
|
|
nano-optimization for memchr::repeat_byte
This replaces the multiple shifts & bitwise or with a single multiplication
In my benchmarks this performs equally well or better, especially on 64bit systems (it shaves a stable nanosecond on my skylake). This may go against conventional wisdom, but the shifts and bitwise ors cannot be pipelined because of hard data dependencies.
While it may or may not be worthwile from an optimization standpoint, it also reduces code size, so there's basically no downside.
|
|
Forbid constructing empty identifiers from concat_idents
The empty identifier is a [reserved identifier](https://github.com/rust-lang/rust/blob/8a37c75a3a661385cc607d934c70e86a9eaf5fd7/src/libsyntax_pos/symbol.rs#L300-L305) in rust, apparently used for black magicks like representing the crate root or somesuch... and therefore, being able to construct it is Ungood. Presumably.
...even if the macro that lets you construct it is so useless that you can't actually do any damage with it. (and believe me, I tried)
Fixes #50403.
**Note:** I noticed that when you try to do something similar with `proc_macro::Term`, the compiler actually catches it and flags the identifier as reserved. Perhaps a better solution would be to somehow have that same check applied here.
|
|
|
|
Fix a warning in libcore on 16bit targets.
This code is assuming that usize >= 32bits, but it is not the case on
16bit targets. It is producing a warning that can fail the compilation
on MSP430 if deny(warnings) is enabled.
It is very unlikely that someone would actually use this code on
a microcontroller, but since unicode was merged into libcore we
have to compile it on 16bit targets.
I've tried to make sure that the code stays the same on x86,
here is an assembly comparison: https://godbolt.org/g/wFw7dZ
r? @SimonSapin
|
|
|
|
This code is assuming that usize >= 32bits, but it is not the case on
16bit targets. It is producing a warning that will fail the compilation
on MSP430 if deny(warnings) is enabled.
It is very unlikely that someone would actually use this code on
a microcontroller, but since unicode was merged into libcore we
have compile it on 16bit targets.
|
|
Introduce RangeInclusive::{new, start, end} methods and make the fields private.
cc #49022
|
|
stabilize `#[must_use]` for functions and must-use comparison operators (RFC 1940)
r? @nikomatsakis
|
|
|
|
|
|
Fix some broken links in docs.
|
|
Make `Vec::new` a `const fn`
`RawVec::empty/_in` are a hack. They're there because `if size_of::<T> == 0 { !0 } else { 0 }` is not allowed in `const` yet. However, because `RawVec` is unstable, the `empty/empty_in` constructors can be removed when #49146 is done...
|
|
|
|
Added new()/start()/end() methods to RangeInclusive.
Changed the lowering of `..=` to use RangeInclusive::new().
|
|
m*n lines of implementation deserves m*n lines of tests
|
|
|
|
A previous PR fixed one method that was legitimately buggy;
this cleans up the rest to be less diverse, mirroring the
corresponding impls on [T] to the greatest extent possible
without introducing any unnecessary UTF-8 boundary checks at 0.
|
|
|
|
|
|
Fix typo
|
|
This is in the matter of RFC 1940 and tracking issue #43302.
|
|
Added warning for unused arithmetic expressions
The compiler now displays a warning when a binary arithmetic operation is evaluated but not used. This resolves #50124 by following the instructions outlined in the issue. The changes are as follows:
- Added new pattern matching for unused arithmetic expressions in `src/librustc_lint/unused.rs`
- Added `#[must_use]` attributes to the binary operation methods in `src/libcore/internal_macros.rs`
- Added `#[must_use]` attributes to the non-assigning binary operators in `src/libcore/ops/arith.rs`
|
|
std: Mark `ptr::Unique` with `#[doc(hidden)]`
`Unique` is now perma-unstable, so let's hide its docs.
|
|
|
|
|
