| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
variant_count: avoid incorrect dummy implementation
This also avoids a stage 0 doctest failure.
|
|
|
|
|
|
|
|
Optimise fast path of checked_ops with `unlikely`
This PR marks paths returning `None` in checked_ops as unlikely to improvde codegen.
Fixes #73731
|
|
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
|
|
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
|
|
Implement `slice_strip` feature
Tracking issue: #73413
|
|
|
|
Fix comma in debug_assert! docs
|
|
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
|
|
|
|
Does not yet make its constness stable, though. Use of
`Location::caller` in const contexts is still gated by
`#![feature(const_caller_location)]`.
|
|
And final part!!!
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
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
|
|
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
|
|
|
|
|
|
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
|
|
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.
|
|
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
|
|
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
|
|
|
|
|
|
|
|
Co-authored-by: Lukas Kalbertodt <lukas.kalbertodt@gmail.com>
|
|
|
|
|
|
Adds a clearer message for when the async keyword is missing from a f…
…unction
This is a somewhat simple fix for #66731.
Under the current version of Rust, if a user has a rust file that looks like this:
```rust
fn boo (){}
async fn foo() {
boo().await;
}
fn main() {
}
```
And they attempt to run it, they will receive an error message that looks like this:
```bash
error: incorrect use of `await` --> test.rs:4:14 | 4 | boo.await(); | ^^ help: `await` is not a method call, remove the parentheses error[E0277]: the trait bound `fn() {boo}: std::future::Future` is not satisfied --> test.rs:4:5 | 4 | boo.await(); | ^^^^^^^^^ the trait `std::future::Future` is not implemented for `fn() {boo}` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`.
```
This is not very clear.
With the changes made in this PR, when a user compiles and runs that same rust code, they will receive an error message that looks like this:
```bash
error[E0277]: `()` is not a future.
--> test.rs:4:5
|
4 | boo().await;
| ^^^^^^^^^^^ `()` is not a future
|
= help: the trait `std::future::Future` is not implemented for `()`
= note: required by `std::future::Future::poll`
```
In the future, I think we should make this error message even clearer, perhaps through a solution like the one described in [this comment](https://github.com/rust-lang/rust/issues/66731#issuecomment-644394287). However, as that potentially involves a major change proposal, I would rather get this change in now and make the error message a little clearer while an MCP is drafted and discussed.
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
|
|
Also, run RustFmt on the clashing_extern_fn test case and update
stderrs.
|
|
|
|
Remove irrelevant comment
Iterator is no longer a lang item since 216e72f8d9499d012e23bc4563215e693fcb4f35.
|
|
add missing doc links
The doc comments contain ``[`size_of_val`]`` but the link target was missing.
|
|
They are gated by internal feature gate const_likely
|
|
Fix links in `SliceIndex` documentation
See [this doc](https://doc.rust-lang.org/nightly/std/slice/trait.SliceIndex.html#tymethod.get_unchecked) whose links aren't active because of this missing newline.
|
|
Fix ptr doc warnings.
#73398 added some stray backtick lines which cause warnings when the docs are built.
|
|
Add unstable `core::mem::variant_count` intrinsic
Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`.
I've shown this to a couple of people and they invariably ask 'why on earth?', but there's actually a very neat use case:
At the moment, if you want to create an opaque array type that's indexed by an `enum` with one element for each variant, you either have to hard-code the number of variants, add a `LENGTH` variant or use a `Vec`, none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic, it becomes possible to write the following:
```rust
#[derive(Copy, Clone)]
enum OpaqueIndex {
A = 0,
B,
C,
}
struct OpaqueVec<T>(Box<[T; std::mem::num_variants::<OpaqueIndex>()]>);
impl<T> std::ops::Index<OpaqueIndex> for OpaqueVec<T> {
type Output = T;
fn index(&self, idx: OpaqueIndex) -> &Self::Output {
&self.0[idx as usize]
}
}
```
(We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.)
|
|
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
|
|
|
|
Add TryFrom<{int}> for NonZero{int}
Adds `TryFrom<{int}> for NonZero{int}`.
It uses the existing `NonZero{int}::new()` and `Option::ok_or()` functions, meaning the checks are not repeated.
I also added tests, I tried to follow the convention I saw in the test file.
I also used `#[stable(feature = "nzint_try_from_int_conv", since = "1.46.0")]`, but I have no idea if the feature/version are correctly named or even correct.
|
|
Fixes #70718
This commit allows making associated items (e.g. associated functions
and types) into lang items via the `#[lang]` attribute. This allows such
items to be accessed directly, rather than by iterating over the parent
item's associated items.
I've added `FnOnce::Output` as a lang item, and updated one old usage to
use the new lang item. The remaining uses can be updated separately.
|
|
|
|
|
