| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
fix `intrinsics::needs_drop` docs
|
|
A way forward for pointer equality in const eval
r? @varkor on the first commit and @RalfJung on the second commit
cc #53020
|
|
|
|
|
|
|
|
Co-authored-by: Bastian Kauschke <bastian_kauschke@hotmail.de>
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
Update bootstrap to rustc 1.45.0-beta.2 (1dc0f6d8e 2020-06-15)
Pulls in changes from #73326.
Closes #73286
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
This lint checks that all declarations for extern fns of the same name
are declared with the same types.
|
|
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
|
|
|
|
|
|
memory access sanity checks: abort instead of panic
Suggested by @Mark-Simulacrum, this should help reduce the performance impact of these checks.
|
|
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.](https://github.com/richkadel/rust/blob/cfa0b21d34ee64e4ebee226101bd2ef0c6757865/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 #54176
Closes #61913
|
|
|
|
Improve document for `Result::as_deref(_mut)` methods
cc #50264
|
|
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
|
