Disable Ctrl-C handling on WASM
WASM fundamentally doesn't support signals. If WASI ever gets support for notifying the guest process of a Ctrl-C that happened, this would have to be done through the guest process polling for the signal, which will require thread support in WASI too to be compatible with the api provided by the ctrlc crate.
WASM fundamentally doesn't support signals. If WASI ever gets support
for notifying the guest process of a Ctrl-C that happened, this would
have to be done through the guest process polling for the signal, which
will require thread support in WASI too to be compatible with the api
provided by the ctrlc crate.
compiletest: error when finding a trailing directive
This PR introduce a supplementary check that when checking for a compiletest directive, will also check that the next "word" after that directive is not also by itself a directive.
This is done to avoid situations like this `//@ only-linux only-x86_64` where one might think that both directives are being taken into account while in fact the second in a comment, and so was ignored, until now.
Related to #123730
cc ``@scottmcm``
r? ``@jieyouxu``
Tweak value suggestions in `borrowck` and `hir_analysis`
Unify the output of `suggest_assign_value` and `ty_kind_suggestion`.
Ideally we'd make these a single function, but doing so would likely require modify the crate dependency tree.
Rework ptr-to-ref conversion suggestion for method calls
If we have a value `z` of type `*const u8` and try to call `z.to_string()`, the upstream compiler will show you a note suggesting to call `<*const u8>::as_ref` first.
This PR extends that:
- The note will only be shown when the method would exist on the corresponding reference type
- It can now suggest any of `<*const u8>::as_ref`, `<*mut u8>::as_ref` and `<*mut u8>::as_mut`, depending on what the method needs.
I didn't introduce a `help` message because that's not a good idea with `unsafe` functions (and you'd also need to unwrap the `Option<&_>` somehow).
People should check the safety requirements.
For the simplest case
```rust
fn main() {
let x = 8u8;
let z: *const u8 = &x;
// issue #21596
println!("{}", z.to_string()); //~ ERROR E0599
}
```
the output changes like this:
```diff
error[E0599]: `*const u8` doesn't implement `std::fmt::Display`
--> $DIR/suggest-convert-ptr-to-ref.rs:5:22
|
LL | println!("{}", z.to_string());
| ^^^^^^^^^ `*const u8` cannot be formatted with the default formatter
|
- = note: try using `<*const T>::as_ref()` to get a reference to the type behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref
- = note: using `<*const T>::as_ref()` on a pointer which is unaligned or points to invalid or uninitialized memory is undefined behavior
+note: the method `to_string` exists on the type `&u8`
+ --> $SRC_DIR/alloc/src/string.rs:LL:COL
+ = note: try using the unsafe method `<*const T>::as_ref` to get an optional reference to the value behind the pointer: https://doc.rust-lang.org/std/primitive.pointer.html#method.as_ref
= note: the following trait bounds were not satisfied:
`*const u8: std::fmt::Display`
which is required by `*const u8: ToString`
```
I removed the separate note about the safety requirements because it was incomplete and the linked doc page already has the information you need.
Fixes#83695, but that's more of a side effect. The upstream compiler already suggests the right method name here.
Provide suggestion to dereference closure tail if appropriate
When encoutnering a case like
```rust
use std::collections::HashMap;
fn main() {
let vs = vec![0, 0, 1, 1, 3, 4, 5, 6, 3, 3, 3];
let mut counts = HashMap::new();
for num in vs {
let count = counts.entry(num).or_insert(0);
*count += 1;
}
let _ = counts.iter().max_by_key(|(_, v)| v);
```
produce the following suggestion
```
error: lifetime may not live long enough
--> $DIR/return-value-lifetime-error.rs:13:47
|
LL | let _ = counts.iter().max_by_key(|(_, v)| v);
| ------- ^ returning this value requires that `'1` must outlive `'2`
| | |
| | return type of closure is &'2 &i32
| has type `&'1 (&i32, &i32)`
|
help: dereference the return value
|
LL | let _ = counts.iter().max_by_key(|(_, v)| **v);
| ++
```
Fix#50195.
Rollup of 8 pull requests
Successful merges:
- #122470 (`f16` and `f128` step 4: basic library support)
- #122954 (Be more specific when flagging imports as redundant due to the extern prelude)
- #123314 (Skip `unused_parens` report for `Paren(Path(..))` in macro.)
- #123360 (Document restricted_std)
- #123661 (Stabilize `cstr_count_bytes`)
- #123703 (Use `fn` ptr signature instead of `{closure@..}` in infer error)
- #123756 (clean up docs for `File::sync_*`)
- #123761 (Use `suggest_impl_trait` in return type suggestion on type error)
r? `@ghost`
`@rustbot` modify labels: rollup
Use `suggest_impl_trait` in return type suggestion on type error
Discovered while doing other refactoring. Review with whitespace disabled.
r? estebank
clean up docs for `File::sync_*`
* Clarify that `sync_all` also writes data and not just metadata.
* Clarify that dropping a file is not equivalent to calling `sync_all` and ignoring the result. `sync_all` the still the recommended way to detect errors before closing, because we don't have a dedicated method for that.
* Add a link from `sync_all` to `sync_data`, because that's what the user might want to use instead.
* Add doc aliases for `fsync` -> `sync_all` and `fdatasync` -> `sync_data`. Those are the POSIX standard names for these functions. I was trying to find out what we call `fsync` in Rust and had to search through the source code to find it, so this alias should help with that in the future.
Use `fn` ptr signature instead of `{closure@..}` in infer error
When suggesting a type on inference error, do not use `{closure@..}`. Instead, replace with an appropriate `fn` ptr.
On the error message, use `short_ty_string` and write long types to disk.
```
error[E0284]: type annotations needed for `Select<{closure@lib.rs:2782:13}, _, Expression<'_>, _>`
--> crates/lang/src/parser.rs:41:13
|
41 | let lit = select! {
| ^^^
42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()),
| ---- type must be known at this point
|
= note: the full type name has been written to '/home/gh-estebank/iowo/target/debug/deps/lang-e2d6e25819442273.long-type-4587393693885174369.txt'
= note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan`
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
|
41 | let lit: Select<for<'a, 'b> fn(tokens::Token<'_>, &'a mut MapExtra<'_, 'b, _, _>) -> Option<Expression<'_>>, _, Expression<'_>, _> = select! {
| +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```
instead of
```
error[E0284]: type annotations needed for `Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _>`
--> crates/lang/src/parser.rs:41:13
|
41 | let lit = select! {
| ^^^
42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()),
| ---- type must be known at this point
|
= note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan`
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
|
41 | let lit: Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _> = select! {
| ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```
Address #123630 (test missing).
Document restricted_std
This PR aims to pin down exactly what restricted_std is meant to achieve and what it isn't.
This commit fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/87 by explaining why the error appears and what the choices the user has. The error describes how std cannot function without knowing about some form of OS/platform support. Any features of std that work without an OS should be moved to core/alloc (see https://github.com/rust-lang/rust/issues/27242https://github.com/rust-lang/rust/issues/103765).
Note that the message says "platform" and "environment" because, since https://github.com/rust-lang/rust/pull/120232, libstd can be built for some JSON targets. This is still unsupported (all JSON targets probably should be unstable https://github.com/rust-lang/wg-cargo-std-aware/issues/90), but a JSON target with the right configuration should hopefully have some partial libstd support.
I propose closing https://github.com/rust-lang/wg-cargo-std-aware/issues/69 as "Won't fix" since any support of std without properly configured os, vendor or env fields is very fragile considering future upgrades of Rust or dependencies. In addition there's no likely path to it being fixed long term (making std buildable for all targets being the only solution). This is distinct from tier 3 platforms with limited std support implemented (and as such aren't restricted_std) because these platforms can conceptually work in the future and std support should mainly improve over time.
The alternative to closing https://github.com/rust-lang/wg-cargo-std-aware/issues/69 is a new crate feature for std which escapes the restricted_std mechanism in build.rs. It could be used with the -Zbuild-std-features flag if we keep it permanently unstable, which I hope we can do anyway. A minor side-effect in this scenario is that std wouldn't be marked as unstable if documentation for it were generated with build-std.
cc ```@ehuss```
Skip `unused_parens` report for `Paren(Path(..))` in macro.
fixes#120642
In following code, `unused_parens` suggest change `<($($rest),*)>::bar()` to `<$rest>::bar()` which will cause another err: `error: variable 'rest' is still repeating at this depth`：
```rust
trait Foo {
fn bar();
}
macro_rules! problem {
($ty:ident) => {
impl<$ty: Foo> Foo for ($ty,) {
fn bar() { <$ty>::bar() }
}
};
($ty:ident $(, $rest:ident)*) => {
impl<$ty: Foo, $($rest: Foo),*> Foo for ($ty, $($rest),*) {
fn bar() {
<$ty>::bar();
<($($rest),*)>::bar()
}
}
problem!($($rest),*);
}
}
```
I think maybe we can handle this by avoid warning for `Paren(Path(..))` in the macro. Is this reasonable approach?
`f16` and `f128` step 4: basic library support
This is the next step after https://github.com/rust-lang/rust/pull/121926, another portion of https://github.com/rust-lang/rust/pull/114607
Tracking issue: https://github.com/rust-lang/rust/issues/116909
This PR adds the most basic operations to `f16` and `f128` that get lowered as LLVM intrinsics. This is a very small step but it seemed reasonable enough to add unopinionated basic operations before the larger modules that are built on top of them.
r? ```@Amanieu``` since you were pretty involved in the RFC
cc ```@compiler-errors```
```@rustbot``` label +T-libs-api +S-blocked +F-f16_and_f128
Propagate temporary lifetime extension into if and match.
This PR makes this work:
```rust
let a = if true {
..;
&temp() // used to error, but now gets lifetime extended
} else {
..;
&temp() // used to error, but now gets lifetime extended
};
```
and
```rust
let a = match () {
_ => {
..;
&temp() // used to error, but now gets lifetime extended
}
};
```
to make it consistent with:
```rust
let a = {
..;
&temp() // lifetime is extended
};
```
This is one small part of [the temporary lifetimes work](https://github.com/rust-lang/lang-team/issues/253).
This part is backwards compatible (so doesn't need be edition-gated), because all code affected by this change previously resulted in a hard error.
This reverts commit 049a917535.
The resolution to <https://github.com/rust-lang/rust/issues/123282> is
that the `f16`/`f128` regression in the beta compiler was fixable
without a revert, so the commit adding `#[cfg(not(bootstrap))]` is no
longer useful (added in
<https://github.com/rust-lang/rust/pull/123390>).
Revert this commit because not having these basic impls bootstrap-gated
simplifies everything else that uses them.
Rollup of 7 pull requests
Successful merges:
- #118391 (Add `REDUNDANT_LIFETIMES` lint to detect lifetimes which are semantically redundant)
- #123534 (Windows: set main thread name without re-encoding)
- #123659 (Add support to intrinsics fallback body)
- #123689 (Add const generics support for pattern types)
- #123701 (Only assert for child/parent projection compatibility AFTER checking that theyre coming from the same place)
- #123702 (Further cleanup cfgs in the UI test suite)
- #123706 (rustdoc: reduce per-page HTML overhead)
r? `@ghost`
`@rustbot` modify labels: rollup
Further cleanup cfgs in the UI test suite
This PR does more cleanup of cfgs in our UI test suite, in preparation for adding automatic always on check-cfg (but is IMO worth landing even without that follow up).
To be more specific this PR:
- replaces (the last remaining) never true cfgs by the `FALSE` cfg
- fix `proc-macro/derive-helper-configured.rs` *(typo in directive)*
- and comment some current unused `#[cfg_attr]` *(missing revisions)*
Follow-up to https://github.com/rust-lang/rust/pull/123577.
Only assert for child/parent projection compatibility AFTER checking that theyre coming from the same place
This assertion doesn't make sense until we check that these captures are actually equivalent.
Fixes#123697
<sub>Some days I wonder how I even write code that works...</sub>
Add support to intrinsics fallback body
Before this fix, the call to `body()` would crash, since `has_body()` would return true, but we would try to retrieve the body of an intrinsic which is not allowed.
Instead, the `Instance::body()` function will now convert an Intrinsic into an Item before retrieving its body.
Note: I also changed how we monomorphize the instance body. Unfortunately, the call still ICE for some shims.
r? `@oli-obk`
