| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
```
error[E0432]: unresolved import `some_novel_crate`
--> file.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
```
On resolve errors where there might be a missing crate, mention `cargo add foo`:
```
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `nope`
--> $DIR/conflicting-impl-with-err.rs:4:11
|
LL | impl From<nope::Thing> for Error {
| ^^^^ use of unresolved module or unlinked crate `nope`
|
= help: if you wanted to use a crate named `nope`, use `cargo add nope` to add it to your `Cargo.toml`
```
|
|
We were previously printing the full type on the "this expression has type" label.
```
error[E0308]: mismatched types
--> $DIR/secondary-label-with-long-type.rs:8:9
|
LL | let () = x;
| ^^ - this expression has type `((..., ..., ..., ...), ..., ..., ...)`
| |
| expected `((..., ..., ..., ...), ..., ..., ...)`, found `()`
|
= note: expected tuple `((..., ..., ..., ...), ..., ..., ...)`
found unit type `()`
= note: the full type name has been written to '$TEST_BUILD_DIR/diagnostic-width/secondary-label-with-long-type/secondary-label-with-long-type.long-type-3987761834644699448.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Reported in a comment of #135919.
|
|
This changes the `cenum_impl_drop_cast` lint to be a hard error. This
lint has been deny-by-default and warning in dependencies since
https://github.com/rust-lang/rust/pull/97652 about 2.5 years ago.
Closes https://github.com/rust-lang/rust/issues/73333
|
|
support wasm inline assembly in `naked_asm!`
fixes https://github.com/rust-lang/rust/issues/135518
Webassembly was overlooked previously, but now `naked_asm!` and `#[naked]` functions work on the webassembly targets.
Or, they almost do right now. I guess this is no surprise, but the `wasm32-unknown-unknown` target causes me some trouble. I'll add some inline comments with more details.
r? ```````@bjorn3```````
cc ```````@daxpedda,``````` ```````@tgross35```````
|
|
On lang, we've recently been discussing the drop order with respect to
`let` chains apropos of how we shortened temporary lifetimes in Rust
2024 and how we may shorten them further in the future.
Here we add an extensive set of tests that demonstrate the drop order
in the cases that interest us.
|
|
|
|
|
|
Get rid of RunCompiler
The various `set_*` methods that have been removed can be replaced by setting the respective fields in the `Callbacks::config` implementation. `set_using_internal_features` was often forgotten and it's equivalent is now done automatically.
|
|
handle global trait bounds defining assoc types
This also fixes the compare-mode for
- tests/ui/coherence/coherent-due-to-fulfill.rs
- tests/ui/codegen/mono-impossible-2.rs
- tests/ui/trivial-bounds/trivial-bounds-inconsistent-projection.rs
- tests/ui/nll/issue-61320-normalize.rs
I first considered the alternative to always prefer where-bounds during normalization, regardless of how the trait goal has been proven by changing `fn merge_candidates` instead. https://github.com/rust-lang/rust/blob/ecda83b30f0f68cf5692855dddc0bc38ee8863fc/compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs#L785
This approach is more restrictive than behavior of the old solver to avoid mismatches between trait and normalization goals. This may be breaking in case the where-bound adds unnecessary region constraints and we currently don't ever try to normalize an associated type. I would like to detect these cases and change the approach to exactly match the old solver if required. I want to minimize cases where attempting to normalize in more places causes code to break.
r? `@compiler-errors`
|
|
r=compiler-errors
Add missing check for async body when suggesting await on futures.
Currently the compiler suggests adding `.await` to resolve some type conflicts without checking if the conflict happens in an async context. This can lead to the compiler suggesting `.await` in function signatures where it is invalid. Example:
```rs
trait A {
fn a() -> impl Future<Output = ()>;
}
struct B;
impl A for B {
fn a() -> impl Future<Output = impl Future<Output = ()>> {
async { async { () } }
}
}
```
```
error[E0271]: expected `impl Future<Output = impl Future<Output = ()>>` to be a future that resolves to `()`, but it resolves to `impl Future<Output = ()>`
--> bug.rs:6:15
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found future
|
note: calling an async function returns a future
--> bug.rs:6:15
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `A::{synthetic#0}`
--> bug.rs:2:27
|
2 | fn a() -> impl Future<Output = ()>;
| ^^^^^^^^^^^ required by this bound in `A::{synthetic#0}`
help: consider `await`ing on the `Future`
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>>.await {
| ++++++
```
The documentation of suggest_await_on_expect_found (`compiler/rustc_trait_selection/src/error_reporting/infer/suggest.rs:156`) even mentions such a check but does not actually implement it.
This PR adds that check to ensure `.await` is only suggested within async blocks.
There were 3 unit tests whose expected output needed to be changed because they had the suggestion outside of async. One of them (`tests/ui/async-await/dont-suggest-missing-await.rs`) actually tests that exact problem but expects it to be present.
Thanks to `@llenck` for initially noticing the bug and helping with fixing it
|
|
Implement `ByteStr` and `ByteString` types
Approved ACP: https://github.com/rust-lang/libs-team/issues/502
Tracking issue: https://github.com/rust-lang/rust/issues/134915
These types represent human-readable strings that are conventionally,
but not always, UTF-8. The `Debug` impl prints non-UTF-8 bytes using
escape sequences, and the `Display` impl uses the Unicode replacement
character.
This is a minimal implementation of these types and associated trait
impls. It does not add any helper methods to other types such as `[u8]`
or `Vec<u8>`.
I've omitted a few implementations of `AsRef`, `AsMut`, and `Borrow`,
when those would be the second implementation for a type (counting the
`T` impl), to avoid potential inference failures. We can attempt to add
more impls later in standalone commits, and run them through crater.
In addition to the `bstr` feature, I've added a `bstr_internals` feature
for APIs provided by `core` for use by `alloc` but not currently
intended for stabilization.
This API and its implementation are based *heavily* on the `bstr` crate
by Andrew Gallant (`@BurntSushi).`
r? `@BurntSushi`
|
|
Co-authored-by: Waffle Lapkin <waffle.lapkin@gmail.com>
|
|
|
|
|
|
|
|
|
|
- Convert `run-pass` to `check-pass`, the test is about closure
inference based on expected type, does not need to run-pass.
- Dropped unnecessary ignores.
|
|
- Use `needs-threads` instead of `ignore-sgx`.
- Remove unnecessary import and `#![allow(unused_import)]`.
|
|
- Use `only-unix` instead of `ignore-windows`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Ignore unused value, remove `#![allow(unused_variable)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Ignore unused value, remove `#![allow(unused_variable)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Remove unnecessary `mut`, remove `#[allow(unused_mut)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Ignore unused value, remove `#![allow(unused_variable)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Ignore an unused variable and remove `#![allow(unused_variables)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Unwrap a must-use I/O result and remove `#![allow(unused_must_use)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Remove already stable feature gate and remove
`#![allow(stable_features)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Remove unnecessary `mut` and remove `#![allow(unused_mut)]`.
- Replace `ignore-*` with `needs-process`.
|
|
- Replace `ignore-windows` with `only-unix`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Replace `ignore-windows` with `only-unix`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Remove unnecessary `#![allow(unused_imports)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Remove already stable feature gate and remove
`#![allow(stable_features)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Replace `ignore-windows` -> `only-unix` since the test exercises Unix
signals and `ExitStatus::code` behavior that's specific to Unix.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Remove redundant `#![allow(stable_features)]`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Remove already stable feature gate and `#![allow(stable_features)]`.
- Replace `ignore-windows` with `only-unix`.
- Replace `ignore-*` with `needs-subprocess`.
|
|
- Convert `ignore-windows` to `only-unix`.
- Convert `ignore-*` to `needs-subprocess`.
|
|
- Remove already stabilized feature gate and
`#![allow(stable_features)]`.
- Convert `ignore-windows` to `only-unix`.
- Convert `ignore-*` to `needs-subprocess`.
|
|
|
|
- Change test to check only.
- Don't ignore `wasm` or `sgx`.
- Gate test to be Unix only because Unix `CommandExt` influences the
suggestion.
- Run rustfix on the suggestion.
|
|
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
|
|
It has become nothing other than a wrapper around run_compiler.
|
|
|
|
LLVM 20 choses a different unroll factor for the loop.
|
|
Split this into two tests, one for LLVM 19 and one for LLVM 20.
|
|
Update windows-gnu targets to set `DebuginfoKind::DWARF`
These targets have always used DWARF debuginfo and not CodeView/PDB debuginfo like the MSVC Windows targets. However, their target definitions claim to use `DebuginfoKind::PDB` probably to ensure that we do not try to allow the use of split-DWARF debuginfo.
This does not appear to be necessary since the targets set their supported split debug info to `Off`. I've looked at all of the uses of these properties and this patch does not appear to cause any functional changes in compiler behavior. I also added UI tests to attempt to validate there is no change in the behavior of these options on stable compilers.
cc ````@mati865```` since you mentioned this in #135739
cc ````@davidtwco```` for split-dwarf
|
|
amy-kwan:amy-kwan/reprc-struct-diagnostic-power-alignment, r=workingjubilee
[AIX] Lint on structs that have a different alignment in AIX's C ABI
This PR adds a linting diagnostic on AIX for repr(C) structs that are required to follow
the power alignment rule. A repr(C) struct needs to follow the power alignment rule if
the struct:
- Has a floating-point data type (greater than 4-bytes) as its first member, or
- The first member of the struct is an aggregate, whose recursively first member is a
floating-point data type (greater than 4-bytes).
The power alignment rule for eligible structs is currently unimplemented, so a linting
diagnostic is produced when such a struct is encountered.
|
|
r=lcnr
Don't ICE in coerce when autoderef fails to structurally normalize non-WF type in new solver
r? lcnr
|
|
|
|
|
