about summary refs log tree commit diff
path: root/src/libcore
AgeCommit message (Collapse)AuthorLines
2020-02-12Rollup merge of #67585 - ranma42:fix/char-is-ascii-codegen, r=AmanieuDylan DPC-10/+40
Improve `char::is_ascii_*` codegen This PR is an attempt to fix https://github.com/rust-lang/rust/issues/65127 A couple of warnings: 1. the generated code might be further improved (in LLVM and/or MIR) by emitting better comparison sequences; in particular, this would improve the performance of "complex" checks such as those in `is_ascii_punctuation` 2. the second commit is currently marked "DO NOT MERGE", because it regresses SIMD on `u8` slices; this could likely be fixed by improving the computation/usage of demanded bits in LLVM An alternative approach to remove the code duplication might be the use of macros, but currently most of the duplication is actually in the doc comments, so maybe just keeping the redundancy could be ok
2020-02-12Rollup merge of #69027 - TimDiekmann:zeroed-alloc, r=AmanieuYuki Okushi-0/+137
Add missing `_zeroed` varants to `AllocRef` The majority of the allocator wg has decided to add the missing `_zeroed` variants to `AllocRef`: > these should be added since they can be efficiently implemented with the `mremap` system call on Linux. `mremap` allows you to move/grow/shrink a memory mapping, and any new pages added for growth are guaranteed to be zeroed. > > If `AllocRef` does not have these methods then the user will have to manually write zeroes to the added memory since the API makes no guarantees on their contents. For the full discussion please see https://github.com/rust-lang/wg-allocators/issues/14. This PR provides default implementations for `realloc_zeroed`, `alloc_excess_zeroed`, `realloc_excess_zeroed`, and `grow_in_place_zeroed`. r? @Amanieu
2020-02-12Rollup merge of #69026 - TimDiekmann:common-usage, r=AmanieuYuki Okushi-199/+2
Remove common usage pattern from `AllocRef` This removes the common usage patterns from `AllocRef`: - `alloc_one` - `dealloc_one` - `alloc_array` - `realloc_array` - `dealloc_array` Actually, they add nothing to `AllocRef` except a [convenience wrapper around `Layout` and other methods in this trait](https://doc.rust-lang.org/1.41.0/src/core/alloc.rs.html#1076-1240) but have a major flaw: The documentation of `AllocRefs` notes, that > some higher-level allocation methods (`alloc_one`, `alloc_array`) are well-defined on zero-sized types and can optionally support them: it is left up to the implementor whether to return `Err`, or to return `Ok` with some pointer. With the current API, `GlobalAlloc` does not have those methods, so they cannot be overridden for `liballoc::Global`, which means that even if the global allocator would support zero-sized allocations, `alloc_one`, `alloc_array`, and `realloc_array` for `liballoc::Global` will error, while calling `alloc` with a zeroed-size `Layout` could succeed. Even worse: allocating with `alloc` and deallocating with `dealloc_{one,array}` could end up with not calling `dealloc` at all! For the full discussion please see https://github.com/rust-lang/wg-allocators/issues/18 r? @Amanieu
2020-02-11Document stabilized versions of atomic singlethreaded fencesLeSeulArtichaut-0/+24
2020-02-11Remove references to `wrapping` methodsLeSeulArtichaut-10/+10
2020-02-11Fix mistake in atomic comparaison docsLeSeulArtichaut-19/+19
2020-02-11Add newline between summary and stable version documentationLeSeulArtichaut-1/+144
2020-02-11Document stable versions of number-related intrinsicsLeSeulArtichaut-2/+32
2020-02-11Document stable versions of memory-related intrinsicsLeSeulArtichaut-0/+25
2020-02-11Document stable versions of `type_name` and `type_id`LeSeulArtichaut-0/+4
2020-02-11Document stable versions of `f32` and `f64` intrinsicsLeSeulArtichaut-2/+240
Fix links
2020-02-11Auto merge of #68491 - pnkfelix:hide-niches-under-unsafe-cell, r=olibors-0/+2
Hide niches under UnsafeCell Hide any niche of T from type-construction context of `UnsafeCell<T>`. Fix #68303 Fix #68206
2020-02-11Improve `char::is_ascii_*` codeAndrea Canciani-10/+40
These methods explicitly check if a char is in a specific ASCII range, therefore the `is_ascii()` check is not needed, but LLVM seems to be unable to remove it. WARNING: this change improves the performance on ASCII `char`s, but complex checks such as `is_ascii_punctuation` become slower on non-ASCII `char`s.
2020-02-10Auto merge of #69030 - Dylan-DPC:rollup-t9uk7vc, r=Dylan-DPCbors-20/+41
Rollup of 6 pull requests Successful merges: - #68897 (clean up E0275 explanation) - #68908 (Add long error code explanation message for E0637 ) - #68932 (self-profile: Support arguments for generic_activities.) - #68986 (Make ASCII ctype functions unstably const ) - #69007 (Clean up E0283 explanation) - #69014 (change an instance of span_bug() to struct_span_err() to avoid ICE) Failed merges: r? @ghost
2020-02-10Add `repr(no_niche)` to `UnsafeCell`. Fix #68303.Felix S. Klock II-0/+2
2020-02-10Add missing `_zeroed` varants to `AllocRef`Tim Diekmann-0/+137
2020-02-10Remove common usage pattern from `AllocRef`Tim Diekmann-199/+2
2020-02-10Rollup merge of #68986 - ecstatic-morse:const-ascii-ctype, r=CentrilDylan DPC-20/+41
Make ASCII ctype functions unstably const Makes the following inherent methods on `u8` and `char` unstable `const fn`: * `is_ascii_alphabetic` * `is_ascii_uppercase` * `is_ascii_lowercase` * `is_ascii_alphanumeric` * `is_ascii_digit` * `is_ascii_hexdigit` * `is_ascii_punctuation` * `is_ascii_graphic` * `is_ascii_whitespace` * `is_ascii_control` cc #68983
2020-02-10Auto merge of #68835 - CAD97:sound-range-inclusive, r=Mark-Simulacrumbors-53/+26
Remove problematic specialization from RangeInclusive Fixes #67194 using the approach [outlined by Mark-Simulacrum](https://github.com/rust-lang/rust/issues/67194#issuecomment-581669549). > I believe the property we want is that if `PartialEq(&self, &other) == true`, then `self.next() == other.next()`. It is true that this is satisfied by removing the specialization and always doing `is_empty.unwrap_or_default()`; the "wrong" behavior there arises from calling `next()` having an effect on initially empty ranges, as we should be in `is_empty = true` but are not (yet) there. It might be possible to detect that the current state is always empty (i.e., `start > end`) and then not fill in the empty slot. I think this might solve the problem without regressing tests; however, this could have performance implications. > That approach essentially states that we only use the `is_empty` slot for cases where `start <= end`. That means that `Idx: !Step` and `start > end` would both behave the same, and correctly -- we do not need the boolean if we're not ever going to emit any values from the iterator. This is implemented here by replacing the `is_empty: Option<bool>` slot with an `exhausted: bool` slot. This flag is - `false` upon construction, - `false` when iteration has not yielded an element -- importantly, this means it is always `false` for an iterator empty by construction, - `false` when iteration has yielded an element and the iterator is not exhausted, and - only `true` when iteration has been used to exhaust the iterator. For completeness, this also adds a note to the `Debug` representation to note when the range is exhausted.
2020-02-10Fuse FlattenCompat's inner iteratorTim Vermeulen-4/+7
2020-02-10Fix Peekable::next_backTim Vermeulen-1/+5
2020-02-10Rollup merge of #68976 - ecstatic-morse:const-non-zero, r=dtolnayDylan DPC-1/+2
Make `num::NonZeroX::new` an unstable `const fn` cc #53718 These require `#[feature(const_if_match)]`, meaning they must remain unstable for the time being.
2020-02-09Don't return empty slice on last iteration with matched terminator. Test ↵Pyry Kontio-123/+161
reverse iteration.
2020-02-09Implement split_inclusive for slice and str, an splitting iterator that ↵Pyry Kontio-1/+383
includes the matched part in the iterated substrings as a terminator.
2020-02-08Make `u8::is_ascii` a stable `const fn`Dylan MacKenzie-1/+2
`char::is_ascii` is already a stable `const fn`, so there is no reason for `u8::is_ascii` to be unstable.
2020-02-08Make the ASCII ctype inherent methods constDylan MacKenzie-20/+41
2020-02-08Make integer power methods constDylan MacKenzie-14/+31
2020-02-08Use bespoke macro instead of `?` inside const fnsDylan MacKenzie-6/+16
2020-02-08[!] Use `rustc_inherit_overflow_checks` in `next_power_of_two`Dylan MacKenzie-3/+2
I believe the previous code was calling `ops::Add::add` instead of the `+` operator to get this behavior.
2020-02-08Make `num::NonZeroX::new` an unstable `const fn`Dylan MacKenzie-1/+2
2020-02-09Rollup merge of #68946 - mjbshaw:must_use, r=mjbshawDylan DPC-0/+13
Mark several functions and methods in core::cmp as #[must_use] These functions and methods aren't mutating functions and ignoring the result of them is likely a bug in the user's code.
2020-02-09Rollup merge of #68918 - brson:unwrapdoc, r=Dylan-DPCDylan DPC-63/+75
Don't use the word "unwrap" to describe "unwrap" methods It's tautological, and "unwrap" is essentially Rust-specific jargon. I was teaching a newbie some Rust, and doing the usual hand-waving about error handling using unwrap. They asked what 'unwrap' means. I said look it up in the docs. The docs read (paraphrased) "unwrap unwraps". I was embarrassed. This changes all the Option/Result functions with unwrapping behavior to use a variation on a single description: > "Returns the contained `Some/Ok` value [or ...]." It also renames the closure of `Result::unwrap_or_else` to `default` for consistency with `Option`, and perhaps makes a few other small tweaks. Previous: https://github.com/rust-lang/rust/pull/68849
2020-02-08Remove problematic specialization from RangeInclusiveCAD97-53/+26
2020-02-08Mark several functions and methods in core::cmp as #[must_use]Michael Bradshaw-0/+13
2020-02-08Auto merge of #68358 - matthewjasper:spec-fix, r=nikomatsakisbors-57/+91
Remove some unsound specializations This removes the unsound and exploitable specializations in the standard library * The `PartialEq` and `Hash` implementations for `RangeInclusive` are changed to avoid specialization. * The `PartialOrd` specialization for slices now specializes on a limited set of concrete types. * Added some tests for the soundness problems.
2020-02-07Don't use the word 'unwrap' to describe core unwrapping functionsBrian Anderson-26/+38
It's tautological, and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words "return", "contain", "consume". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.
2020-02-06Rollup merge of #68886 - tom-a-wagner:master, r=Mark-SimulacrumDylan DPC-0/+12
Mark fn map_or() as eagerly evaluated. In the docs for option.rs and result.rs, it is noted for all *_or() functions that they are eagerly evaluated, except for the map_or() function. This commit adds this missing documentation to the two files. Closes #68866
2020-02-06Rollup merge of #68524 - jonas-schievink:generator-resume-arguments, r=ZoxcDylan DPC-4/+31
Generator Resume Arguments cc https://github.com/rust-lang/rust/issues/43122 and https://github.com/rust-lang/rust/issues/56974 Blockers: * [x] Fix miscompilation when resume argument is live across a yield point (https://github.com/rust-lang/rust/pull/68524#issuecomment-578459069) * [x] Fix 10% compile time regression in `await-call-tree` benchmarks (https://github.com/rust-lang/rust/pull/68524#issuecomment-578487162) * [x] Fix remaining 1-3% regression (https://github.com/rust-lang/rust/pull/68524#issuecomment-579566255) - resolved (https://github.com/rust-lang/rust/pull/68524#issuecomment-581144901) * [x] Make dropck rules account for resume arguments (https://github.com/rust-lang/rust/pull/68524#issuecomment-578541137) Follow-up work: * Change async/await desugaring to make use of this feature * Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)
2020-02-06Add primitive module to libcore/stdMark Rousskov-0/+70
This re-exports the primitive types from libcore at `core::primitive` to allow macro authors to have a reliable location to use them from.
2020-02-06Mark fn map_or() as eagerly evaluated.Tom A. Wagner-0/+12
In the docs for option.rs and result.rs, it is noted for all *_or() functions that they are eagerly evaluated, except for the map_or() function. This commit adds this missing documentation to the two files.
2020-02-05Rollup merge of #68809 - ecstatic-morse:const-int-functions, r=oli-obkDylan DPC-49/+108
Make more arithmetic functions unstably const This is a smaller version of #66884 (thanks @9999years) that constifies many of the arithmetic functions on integer primitives from #53718 that were blocked on #49146. This makes the following things unstably const. - `feature = const_int_unchecked_arith` - `intrinsics::unchecked_add` - `intrinsics::unchecked_sub` - `intrinsics::unchecked_mul` - `intrinsics::unchecked_div` - `intrinsics::unchecked_rem` - `feature = const_checked_int_methods` - `checked_add` - `checked_sub` - `checked_mul` - `checked_div` (Uses `intrinsics::unchecked_div` internally) - `checked_rem` (Uses `intrinsics::unchecked_rem` internally) - `checked_neg` - `checked_shl` - `checked_shr` - `checked_abs` - `feature = const_saturating_int_methods` - `saturating_mul` - `saturating_neg` (Uses `intrinsics::unchecked_sub` internally) - `saturating_abs` (Uses `intrinsics::unchecked_sub` internally) - `feature = const_wrapping_int_methods` - `wrapping_div` - `wrapping_rem` - `feature = const_overflowing_int_methods` - `overflowing_div` - `overflowing_rem` - `feature = const_euclidean_int_methods` - `checked_div_euclid` - `checked_rem_euclid` - `wrapping_div_euclid` - `wrapping_rem_euclid` - `overflowing_div_euclid` - `overflowing_rem_euclid` Exponentiation and operations on the `NonZero` types are left to a later PR. r? @oli-obk cc @rust-lang/wg-const-eval @rust-lang/libs
2020-02-05Reorder declarations of Result::expect_err/unwrap_err to match OptionBrian Anderson-22/+22
2020-02-05Reorder declarations of Result::export/unwrap to match OptionBrian Anderson-17/+17
2020-02-04Use consistent feature namingDylan MacKenzie-49/+49
2020-02-04Rollup merge of #68810 - ollie27:once_with_copy, r=Dylan-DPCDylan DPC-1/+1
Remove Copy impl from OnceWith Iterators typically don't implement `Copy` and this shouldn't be an exception.
2020-02-04Make saturating arithmetic using intrinsics `const`Dylan MacKenzie-2/+4
2020-02-04Make checked division `const`Dylan MacKenzie-4/+8
2020-02-04Const-stabilize some arithmetic intrinsicsDylan MacKenzie-0/+6
2020-02-04Make wrapping arithmetic `const`Dylan MacKenzie-4/+8
Co-Authored-By: 9999years <rbt@sent.as>
2020-02-04Make `saturating_mul` a `const fn`Dylan MacKenzie-6/+13
Co-Authored-By: 9999years <rbt@sent.as>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 15:28:40 +0000