about summary refs log tree commit diff
path: root/src/libcore
AgeCommit message (Collapse)AuthorLines
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-05add (unchecked) indexing methods to raw pointers and NonNullRalf Jung-15/+103
2020-07-05make unchecked slice indexing helper methods use raw pointersRalf Jung-129/+134
2020-07-05call the mut version as_mut_ptr and also add an as_ptr-like method to ↵Ralf Jung-2/+23
NonNull slices
2020-07-05add as_ptr method to raw slicesRalf Jung-0/+42
2020-07-05variant_count: avoid incorrect dummy implementationRalf Jung-7/+2
2020-07-05Remove LengthAtMost32Roman Proskuryakov-25/+0
2020-07-05Remove the usage of the LengthAtMost32 traitRoman Proskuryakov-77/+19
2020-07-05Fix spacing in Iterator fold docIvan Tham-2/+2
2020-07-04remove LengthAtMost32 on AsRef/Borrow impl for arrayAndrey Zgarbul-16/+4
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-01Add feature const_optionBenoît du Garreau-4/+9
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-29Derive common traits for panic::Location.Adam Perry-1/+23
Add documentation about the host/target behavior of Location::file.
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-29stabilize const_ascii_ctype_on_intrinsicsTrevor Spiteri-21/+40
2020-06-29stabilize const_int_signTrevor Spiteri-1/+2
2020-06-29stabilize const_saturating_int_methodsTrevor Spiteri-9/+11
2020-06-29stabilize some const_checked_int_methodsTrevor Spiteri-13/+26
2020-06-29stabilize const_nonzero_int_methodsTrevor Spiteri-1/+2
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>
2020-06-28Add comment on use of unsafeVillSnow-0/+9
2020-06-28Fix comma in debug_assert! docspierwill-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-14 04:19:56 +0000