summary refs log tree commit diff
path: root/src/libcore
AgeCommit message (Collapse)AuthorLines
2020-07-14Dummy function to re-add const_transmute feature gateMark Rousskov-1/+5
2020-07-14Auto merge of #73490 - CAD97:range-unchecked-stepping, r=Amanieubors-12/+12
Use step_unchecked more liberally in range iter impls Without these `_unchecked`, these operations on iterators of `char` fail to optimize out the unreachable panicking condition on overflow. cc @cuviper https://github.com/rayon-rs/rayon/pull/771 where this was discovered.
2020-07-11Rollup merge of #74066 - thomcc:optimize-is-ascii, r=nagisaManish Goregaokar-2/+242
Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while, so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version, and `is_ascii_slice_libcore` is the new. I tried to document the code well, so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now, I tried to `debug_assert` all the safety invariants I'm depending on. (Of course, none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway, thanks. Let me know if you have questions/desired changes.
2020-07-11Rollup merge of #72920 - oli-obk:const_transmute, r=RalfJungManish Goregaokar-2/+4
Stabilize `transmute` in constants and statics but not const fn cc #53605 (leaving issue open so we can add `transmute` to `const fn` later) Previous attempt: #64011 r? @RalfJung cc @rust-lang/wg-const-eval
2020-07-11Stabilize `transmute` in constants and statics but not const fnOliver Scherer-2/+4
2020-07-10Rollup merge of #74127 - tamird:allowlist, r=oli-obkManish Goregaokar-1/+1
Avoid "whitelist" Other terms are more inclusive and precise.
2020-07-10Rollup merge of #73887 - DutchGhost:master, r=oli-obkManish Goregaokar-2/+1
stabilize const mem::forget Stabilizes const `mem::forget` as implemented in https://github.com/rust-lang/rust/pull/69617 and tracked in https://github.com/rust-lang/rust/issues/69616. Closes https://github.com/rust-lang/rust/issues/69616
2020-07-10Rollup merge of #72303 - yoshuawuyts:future-poll-fn, r=dtolnayManish Goregaokar-0/+70
Add core::future::{poll_fn, PollFn} This is a sibling PR to #70834, adding `future::poll_fn`. This is a small helper function that helps bridge the gap between "poll state machines" and "async/await". It was first introduced in [futures@0.1.7](https://docs.rs/futures/0.1.7/futures/future/fn.poll_fn.html) in December of 2016, and has been tried and tested as part of the ecosystem for the past 3.5 years. ## Implementation Much of the same reasoning from #70834 applies: by returning a concrete struct rather than an `async fn` we get to mark the future as `Unpin`. It also becomes named which allows storing it in structs without boxing. This implementation has been modified from the implementation in `futures-rs`. ## References - [`futures::future::poll_fn`](https://docs.rs/futures/0.3.5/futures/future/fn.poll_fn.html) - [`async_std::future::poll_fn`](https://docs.rs/async-std/1.5.0/async_std/future/fn.poll_fn.html)
2020-07-10Avoid "whitelist"Tamir Duberstein-1/+1
Other terms are more inclusive and precise.
2020-07-09Rollup merge of #73292 - poliorcetics:fix-link-in-partialeq, r=Dylan-DPCManish Goregaokar-2/+1
Fixing broken link for the Eq trait Fixes #73233.
2020-07-06Expand abbreviation in core::ffi descriptionpierwill-1/+1
2020-07-06Remove pointless `black_box` call, add a comment about the `unaligned_` ↵Thom Chiovoloni-4/+5
benches, and clean up stray semicolon
2020-07-05Rollup merge of #74064 - RalfJung:variant-count-bootstrap, r=kennytmManish Goregaokar-7/+2
variant_count: avoid incorrect dummy implementation This also avoids a stage 0 doctest failure.
2020-07-05Add 'unrolled' is_ascii_align_to benchmark, and move is_ascii benchmarks ↵Thom Chiovoloni-76/+83
into own file
2020-07-05Benchmark the unaligned case for is_ascii, and add missing SAFETYThom Chiovoloni-3/+21
2020-07-05Add benchmark for slice is_ascii using align_toThom Chiovoloni-1/+24
2020-07-05Avoid `vec!` allocation in `is_ascii_slice_*` benchesThom Chiovoloni-9/+36
2020-07-05Optimize is_ascii for &str and &[u8]Thom Chiovoloni-2/+166
2020-07-05variant_count: avoid incorrect dummy implementationRalf Jung-7/+2
2020-07-05Fix spacing in Iterator fold docIvan Tham-2/+2
2020-07-03fix typoBastian Kauschke-1/+1
2020-07-02Rollup merge of #73938 - nbdd0121:checked_opt, r=nagisaManish Goregaokar-27/+43
Optimise fast path of checked_ops with `unlikely` This PR marks paths returning `None` in checked_ops as unlikely to improvde codegen. Fixes #73731
2020-07-02Rollup merge of #73684 - richkadel:llvm-coverage-map-gen-2, r=wesleywiserManish Goregaokar-1/+34
add spans to injected coverage counters, extract with CoverageData query This is the next iteration on the Rust Coverage implementation, and follows PR #73488 @tmandry @wesleywiser I came up with an approach for coverage spans, pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query. I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization). If this approach works for you, I can quickly expand on this to build a separate IndexVec for counter expressions, using a separate call that will be ignored during code generation, but from which I can extract the counter expression values. Let me know your thoughts. Thanks! r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-07-02Rollup merge of #73622 - LeSeulArtichaut:unsafe-libcore, r=nikomatsakisManish Goregaokar-337/+772
Deny unsafe ops in unsafe fns in libcore After `liballoc`, It's time for `libcore` :D I planned to do this bit by bit to avoid having a big chunk of diffs, so to make reviews easier, and to make the unsafe blocks narrower and take the time to document them properly. r? @nikomatsakis cc @RalfJung
2020-07-02Rollup merge of #73414 - lzutao:slice_strip, r=dtolnayManish Goregaokar-0/+62
Implement `slice_strip` feature Tracking issue: #73413
2020-07-01Optimise fast path of checked_ops with `unlikely`Gary Guo-27/+43
2020-07-01Rollup merge of #73846 - pierwill:pierwill-patch-2, r=joshtriplettManish Goregaokar-1/+1
Fix comma in debug_assert! docs
2020-07-01Rollup merge of #73778 - nbdd0121:const_likely, r=oli-obkManish Goregaokar-0/+3
Make `likely` and `unlikely` const, gated by feature `const_unlikely` This PR also contains a fix to allow `#[allow_internal_unstable]` to work properly with `#[rustc_const_unstable]`. cc @RalfJung @nagisa r? @oli-obk
2020-07-01Implement slice_strip featureLzu Tao-0/+62
2020-06-30Stabilize `#[track_caller]`.Adam Perry-12/+6
Does not yet make its constness stable, though. Use of `Location::caller` in const contexts is still gated by `#![feature(const_caller_location)]`.
2020-06-30Deny unsafe ops in unsafe fns, part 6LeSeulArtichaut-93/+185
And final part!!!
2020-06-30Deny unsafe ops in unsafe fns, part 5LeSeulArtichaut-47/+108
2020-06-30Deny unsafe ops in unsafe fns, part 4LeSeulArtichaut-40/+108
2020-06-30Deny unsafe ops in unsafe fns, part 3LeSeulArtichaut-113/+181
2020-06-30Deny unsafe ops in unsafe fns, part 2LeSeulArtichaut-37/+103
2020-06-30Deny unsafe ops in unsafe fns, part 1LeSeulArtichaut-31/+111
2020-06-30stabilize const mem::forgetDodo-2/+1
2020-06-29add spans to injected coverage countersRich Kadel-1/+34
added regions with counter expressions and counters. Added codegen_llvm/coverageinfo mod for upcoming coverage map Move coverage region collection to CodegenCx finalization Moved from `query coverageinfo` (renamed from `query coverage_data`), as discussed in the PR at: https://github.com/rust-lang/rust/pull/73684#issuecomment-649882503 Address merge conflict in MIR instrument_coverage test The MIR test output format changed for int types. moved debug messages out of block.rs This makes the block.rs calls to add coverage mapping data to the CodegenCx much more concise and readable. move coverage intrinsic handling into llvm impl I realized that having half of the coverage intrinsic handling in `rustc_codegen_ssa` and half in `rustc_codegen_llvm` meant that any non-llvm backend would be bound to the same decisions about how the coverage-related MIR terminators should be handled. To fix this, I moved the non-codegen portion of coverage intrinsic handling into its own trait, and implemented it in `rustc_codegen_llvm` alongside `codegen_intrinsic_call`. I also added the (required?) stubs for the new intrinsics to `IntrepretCx::emulate_intrinsic()`, to ensure calls to this function do not fail if called with these new but known intrinsics. address PR Feedback on 28 June 2020 2:48pm PDT
2020-06-29Auto merge of #73032 - yoshuawuyts:stabilize-leading_trailing_ones, r=Amanieubors-13/+12
stabilize leading_trailing_ones This PR stabilizes the `leading_trailing_ones` feature. It's been available on nightly since the start of the year, and hasn't had any issues since. It seems unlikely we'll want to change this, so following up on @djc's suggestion in https://github.com/rust-lang/rust/issues/57969#issuecomment-638405264 I'd like to put forward this PR to stabilize the feature and make it part of `1.46.0`. Thanks! cc/ @djc @rust-lang/libs
2020-06-28Auto merge of #72437 - ecstatic-morse:stabilize-const-if-match, r=oli-obkbors-5/+5
Stabilize `#![feature(const_if_match)]` Quoting from the [stabilization report](https://github.com/rust-lang/rust/issues/49146#issuecomment-616301045): > `if` and `match` expressions as well as the short-circuiting logic operators `&&` and `||` will become legal in all [const contexts](https://doc.rust-lang.org/reference/const_eval.html#const-context). A const context is any of the following: > > - The initializer of a `const`, `static`, `static mut` or enum discriminant. > - The body of a `const fn`. > - The value of a const generic (nightly only). > - The length of an array type (`[u8; 3]`) or an array repeat expression (`[0u8; 3]`). > > Furthermore, the short-circuiting logic operators will no longer be lowered to their bitwise equivalents (`&` and `|` respectively) in `const` and `static` initializers (see #57175). As a result, `let` bindings can be used alongside short-circuiting logic in those initializers. Resolves #49146. Ideally, we would resolve :whale: #66753 before this lands on stable, so it might be worth pushing this back a release. Also, this means we should get the process started for #52000, otherwise people will have no recourse except recursion for iterative `const fn`. r? @oli-obk
2020-06-28Remove uses of `const_loop` in `rustc`Dylan MacKenzie-1/+1
2020-06-28Remove `const_if_match` feature gate from librariesDylan MacKenzie-4/+4
2020-06-28Rollup merge of #73817 - jumbatm:rename-to-clashing-extern-declarations, ↵Manish Goregaokar-2/+2
r=petrochenkov Rename clashing_extern_decl to clashing_extern_declarations. Rename clashing_extern_decl to clashing_extern_declarations to bring in-line with lint naming conventions. Fixes #73802. r? @petrochenkov
2020-06-28Rollup merge of #73800 - nikic:hash_i, r=kennytmManish Goregaokar-5/+5
Forward Hash::write_iN to Hash::write_uN The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself. This used to be the case previously, but was broken in #59982. As the PR description makes no mention of this particular change, I assume it was unintentional. In a local test, this mitigates the regression from #73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.
2020-06-28Rollup merge of #73577 - VillSnow:master, r=AmanieuManish Goregaokar-0/+95
Add partition_point Add partition_point in C++. Although existing binary_search in rust does not suitable when the slice has multiple hits, this function returns exact point of partition. The definition of this function is very clear and able to accept general matter, therefore you can easily get index which you want like lower/upper_bound. https://github.com/rust-lang/rfcs/issues/2184
2020-06-28Update src/libcore/slice/mod.rsVillSnow-1/+1
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2020-06-28Update tracking issue numberVillSnow-1/+1
2020-06-28Update doc commentVillSnow-6/+10
2020-06-28Merge branch 'master' of https://github.com/VillSnow/rustVillSnow-1/+2
2020-06-28Update src/libcore/slice/mod.rsVillSnow-1/+2
Co-authored-by: Lukas Kalbertodt <lukas.kalbertodt@gmail.com>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 20:17:47 +0000