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>
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.)
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.
Add a lint to catch clashing `extern` fn declarations.
Closes#69390.
Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.
This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.
r? @eddyb
This patch adds two methods to `Duration`. The first, `Duration::zero`,
provides a `const` constructor for getting an zero-length duration. This
is also what `Default` provides (this was clarified in the docs), though
`default` is not `const`.
The second, `Duration::is_zero`, returns true if a `Duration` spans no
time (i.e., because its components are all zero). Previously, the way to
do this was either to compare both `as_secs` and `subsec_nanos` to 0, to
compare against `Duration::new(0, 0)`, or to use the `u128` method
`as_nanos`, none of which were particularly elegant.
Refactor `try_find` a little
~~This works like `find_map`, but mapping to a `Try` type. It stops when `Ok` is `Some(value)`, with an additional short-circuit on `Try::Error`. This is similar to the unstable `try_find`, but has the advantage of being able to directly return the user's `R: Try` type directly, rather than converting to `Result`.~~
(removed -- `try_find_map` was declined in review)
This PR also refactors `try_find` a little to match style. The `E` type parameter was unnecessary, so it's now removed. The folding closure now has reduced parametricity on just `T = Self::Item`, rather
than the whole `Self` iterator type. There's otherwise no functional change in this.
Specialization is unsound
As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949, it might be a good idea to warn users of specialization that the feature they are using is unsound.
I also expanded the "incomplete feature" warning to link the user to the tracking issue.
The `E` type parameter was unnecessary, so it's now removed. The folding
closure now has reduced parametricity on just `T = Self::Item`, rather
than the whole `Self` iterator type. There's otherwise no functional
change in this.
Document unsafety in slice/sort.rs
Let me know if these documentations are accurate c:
I don't think I am capable enough to document the safety of `partition_blocks`, however.
Related issue #66219
first stage of implementing LLVM code coverage
This PR replaces #70680 (WIP toward LLVM Code Coverage for Rust) since I am re-implementing the Rust LLVM code coverage feature in a different part of the compiler (in MIR pass(es) vs AST).
This PR updates rustc with `-Zinstrument-coverage` option that injects the llvm intrinsic `instrprof.increment()` for code generation.
This initial version only injects counters at the top of each function, and does not yet implement the required coverage map.
Upcoming PRs will add the coverage map, and add more counters and/or counter expressions for each conditional code branch.
Rust compiler MCP https://github.com/rust-lang/compiler-team/issues/278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
***[I put together some development notes here, under a separate branch.](cfa0b21d34/src/test/codegen/coverage-experiments/README-THIS-IS-TEMPORARY.md)***
Ensure std benchmarks get tested.
This ensures that the std benchmarks don't break in the future. Currently they aren't compiled or tested on CI, so they can easily bitrot. Testing a benchmark runs it with one iteration. Adding these should only add a few seconds to CI.
Closes#54176Closes#61913
Mention functions pointers in the documentation
Fixes#51615.
This mentions function pointers in the documentation for `core::mem::zeroed`, adding them to the list of types that are **always** wrong when zeroed, with `&T` and `&mut T`.
@rustbot modify labels: T-doc, C-enhancement, T-libs
Tweak "non-primitive cast" error
- Suggest borrowing expression if it would allow cast to work.
- Suggest using `<Type>::from(<expr>)` when appropriate.
- Minor tweak to `;` typo suggestion.
Partily address #47136.
Add tests for 'impl Default for [T; N]'
Related: #71690.
This pull request adds two tests:
- Even it T::default() panics, no leaks occur.
- [T; 0] is Default even if T is not.
I believe at some moment `Default` impl for arrays will be rewritten to use const generics instead of macros, and these tests will help to prevent behavior changes.
add raw_ref macros
In https://github.com/rust-lang/rust/issues/64490, various people were in favor of exposing `&raw` as a macro first before making the actual syntax stable. So this PR (unstably) introduces those macros.
I'll create the tracking issue if we're okay moving forward with this.
