| Age | Commit message (Collapse) | Author | Lines |
|---|
|
weiznich:diagnostic_do_not_recommend_also_skips_help, r=compiler-errors
Allows `#[diagnostic::do_not_recommend]` to supress trait impls in suggestions as well
This commit changes the error reporting mechanism for not implemented traits to skip impl marked as `#[diagnostic::do_not_recommend]` in the help part of the error message ("the following other types implement trait `Foo`:"). The main use case here is to allow crate authors to skip non-meaningful confusing suggestions. A common example for this are fully generic impls on tuples.
Related to https://github.com/rust-lang/rust/issues/51992
r? `@compiler-errors`
|
|
Make sure that labels are defined after the primary span in diagnostics
Putting a `#[label]` before a `#[primary_span]` results in that label being overwritten, due to the semantics of `Diagnostic::span` and the fact that labels are stored in the `MultiSpan` of the diagnostic.
This isn't possible to fix in general, since a lot of code actually *relies* in this overwriting behavior (e.g. `rustc_on_unimplemented`). However, it's useful to enforce this for derive-diagnostics, since this is certainly never what you intend to do in a derived diagnostic, where all the fields are meaningful parts of the diagnostic being rendered.
This only matters for `#[label]`, since those are the ones stored in the `MultiSpan` of the error.
We could also make this "just work" by sorting the attrs or processing the primary span attr first, however I think it's kinda pointless to do.
There was 1 case where this mattered, but we literally didn't have a test exercising that diagnostic 🙃
|
|
core: Limit remaining f16 doctests to x86_64 linux
On s390x, every use of the f16 data type will currently ICE due to https://github.com/llvm/llvm-project/issues/50374, causing doctest failures on the platform.
Most doctests were already restricted to certain platforms, so fix this by likewise restricting the remaining five.
|
|
Don't mark `DEBUG_EVENT` struct as `repr(packed)`
That would give it alignment of 1 which is ABI-incompatible with its C definition.
|
|
Suggest borrowing on fn argument that is `impl AsRef`
When encountering a move conflict, on an expression that is `!Copy` passed as an argument to an `fn` that is `impl AsRef`, suggest borrowing the expression.
```
error[E0382]: use of moved value: `bar`
--> f204.rs:14:15
|
12 | let bar = Bar;
| --- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait
13 | foo(bar);
| --- value moved here
14 | let baa = bar;
| ^^^ value used here after move
|
help: borrow the value to avoid moving it
|
13 | foo(&bar);
| +
```
Fix #41708
|
|
Avoid follow-up errors and ICEs after missing lifetime errors on data structures
Tuple struct constructors are functions, so when we call them typeck will use the signature tuple struct constructor function to provide type hints. Since typeck mostly ignores and erases lifetimes, we end up never seeing the error lifetime in writeback, thus not tainting the typeck result.
Now, we eagerly taint typeck results by tainting from `resolve_vars_if_possible`, which is called all over the place.
I did not carry over all the `crashes` test suite tests, as they are really all the same cause (missing or unknown lifetime names in tuple struct definitions or generic arg lists).
fixes #124262
fixes #124083
fixes #125155
fixes #125888
fixes #125992
fixes #126666
fixes #126648
fixes #127268
fixes #127266
fixes #127304
|
|
|
|
Require a colon in `//@ normalize-*:` test headers
The previous parser for `//@ normalize-*` headers (before #126370) was so lax that it did not require `:` after the header name. As a result, the test suite contained a mix of with-colon and without-colon normalize headers, both numbering in the hundreds.
This PR updates the without-colon headers to add a colon (matching the style used by other headers), and then updates the parser to make the colon mandatory.
(Because the normalization parser only runs *after* the header system identifies a normalize header, this will detect and issue an error for relevant headers that lack the colon.)
Addresses one of the points of #126372.
|
|
Implement simple, unstable lint to suggest turning closure-of-async-block into async-closure
We want to eventually suggest people to turn `|| async {}` to `async || {}`. This begins doing that. It's a pretty rudimentary lint, but I wanted to get something down so I wouldn't lose the code.
Tracking:
* #62290
|
|
suggestions as well
This commit changes the error reporting mechanism for not implemented
traits to skip impl marked as `#[diagnostic::do_not_recommend]` in the
help part of the error message ("the following other types implement
trait `Foo`:"). The main use case here is to allow crate authors to skip
non-meaningful confusing suggestions. A common example for this are
fully generic impls on tuples.
|
|
r=compiler-errors
Avoid "no field" error and ICE on recovered ADT variant
Fixes https://github.com/rust-lang/rust/issues/126744
Fixes https://github.com/rust-lang/rust/issues/126344, a more general fix compared with https://github.com/rust-lang/rust/pull/127426
r? `@oli-obk`
From `@compiler-errors` 's comment https://github.com/rust-lang/rust/pull/127502#discussion_r1669538204
Seems most of the ADTs don't have taint, so maybe it's not proper to change `TyCtxt::type_of` query.
|
|
|
|
|
|
Migrate `issue-83112-incr-test-moved-file`, `type-mismatch-same-crate-name` and `issue-109934-lto-debuginfo` `run-make` tests to rmake or ui
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
I have noticed that the new UI test `debuginfo-lto-alloc` is outputting artifacts that aren't getting cleaned up because of its `-C incremental`. That might be the justification needed to keep it as a run-make test?
Try it on:
// try-job: test-various // previously passed
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-msvc
|
|
|
|
|
|
Make `visit_clobber`'s impl safe
This was originally introduced in #58061 but I didn't see any perf discussion about it, so let's see what perf says.
r? `@nnethercote`
|
|
On s390x, every use of the f16 data type will currently ICE
due to https://github.com/llvm/llvm-project/issues/50374,
causing doctest failures on the platform.
Most doctests were already restricted to certain platforms,
so fix this by likewise restricting the remaining five.
|
|
Add suggestions for possible missing `fn`, `struct`, or `enum` keywords
Closes #125446
Closes #65381
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #126476 (Fix running bootstrap tests with a local Rust toolchain as the stage0)
- #127094 (E0191 suggestion correction, inserts turbofish)
- #127554 ( do not run test where it cannot run)
- #127564 (Temporarily remove me from review rotation.)
- #127568 (instantiate higher ranked goals in candidate selection again)
- #127569 (Fix local download of Docker caches from CI)
- #127570 ( small normalization improvement)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
small normalization improvement
r? `@compiler-errors`
|
|
Fix local download of Docker caches from CI
https://github.com/rust-lang/rust/pull/127312 broke local downloads of Docker caches from CI, when you wanted to build a Docker image locally. This PR fixes that.
r? `@nikic`
(Can you please check if the cache works for you with this PR?)
|
|
instantiate higher ranked goals in candidate selection again
This reverts #119820 as that PR has a significant impact and breaks code which *feels like it should work*. The impact ended up being larger than we expected during the FCP and we've ended up with some ideas for how we can work around this issue in the next solver. This has been discussed in the previous high bandwidth t-types meeting: https://rust-lang.zulipchat.com/#narrow/stream/326132-t-types.2Fmeetings/topic/2024-07-09.20high.20bandwidth.20meeting.
We'll therefore keep this inconsistency between the two solvers for now and will have to deal with it before stabilizating the use of the new solver outside of coherence: https://github.com/rust-lang/trait-system-refactor-initiative/issues/120.
fixes #125194 after a beta-backport.
The pattern which is more widely used than expected and feels like it should work, especially without deep knowledge of the type system is
```rust
trait Trait<'a> {}
impl<'a, T> Trait<'a> for T {}
fn trait_bound<T: for<'a> Trait<'a>>() {}
// A function with a where-bound which is more restrictive than the impl.
fn function1<T: Trait<'static>>() {
// stable: ok
// with #119820: error as we prefer the where-bound over the impl
// with this PR: back to ok
trait_bound::<T>();
}
```
r? `@rust-lang/types`
|
|
Temporarily remove me from review rotation.
|
|
r=pietroalbini
do not run test where it cannot run
This was seen on Ferrocene, where we have a custom test target that does not have unwind support
|
|
E0191 suggestion correction, inserts turbofish
closes #91997
|
|
Fix running bootstrap tests with a local Rust toolchain as the stage0
When configuring a local Rust toolchain as the stage0 (with `build.rustc` and `build.cargo` in `config.toml`) we noticed there were test failures (both on the Python and the Rust side) due to bootstrap not being able to find rustc and Cargo.
This was due to those two `config.toml` settings not being propagated in the tests. This PR fixes the issue by ensuring rustc and cargo are always configured in tests, using the parent bootstrap's `initial_rustc` and `initial_cargo`.
try-job: x86_64-msvc
Fixes https://github.com/rust-lang/rust/issues/105766
|
|
|
|
That would give it alignment of 1 which is ABI-incompatible with its C
definition.
|
|
Sync rustc_codegen_gcc
Follow-up of https://github.com/rust-lang/rustc_codegen_gcc/pull/535.
cc `@antoyo`
|
|
|
|
reverts #119820
|
|
|
|
Exposing STARTUPINFOW.wShowWindow in CommandExt trait
Hi:
I needed a way to control how a new process's window is displayed in Windows (normal, minimized, maximized, etc).
I noticed that there is no direct way to do that (I even searched for crates doing this, but didn't find any).
Inspecting the standard library source code, I figured that it would be a good addition to CommandExt trait that allows some Windows specific customization to a Command.
This is my first time contributing to Rust, so please bear with me if I'm not following the rules :)
|
|
|
|
|
|
|
|
Migrate `extern-flag-pathless`, `silly-file-names`, `metadata-dep-info`, `cdylib-fewer-symbols` and `symbols-include-type-name` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
`cdylib-fewer-symbols` demands a Windows try-job. (Almost guaranteed to fail, but 7 years is a long time)
try-job: x86_64-gnu-distcheck
try-job: x86_64-msvc
try-job: aarch64-apple
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #124211 (Bump `elided_lifetimes_in_associated_constant` to deny)
- #125627 (migration lint for `expr2024` for the edition 2024)
- #127091 (impl FusedIterator and a size hint for the error sources iter)
- #127461 (Fixup failing fuchsia tests)
- #127484 (`#[doc(alias)]`'s doc: say that ASCII spaces are allowed)
- #127508 (small search graph refactor)
- #127521 (Remove spastorino from SMIR)
- #127532 (documentation: update cmake version)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
documentation: update cmake version
Previously discussed here: https://github.com/rust-lang/rust/issues/127531
|
|
Remove spastorino from SMIR
r? ```@oli-obk```
|
|
small search graph refactor
small improvements which shouldn't impact behavior.
r? ``````@compiler-errors``````
|
|
`#[doc(alias)]`'s doc: say that ASCII spaces are allowed
PR #77570 allowed ASCII spaces in doc aliases, but the documentation wasn't updated to say so.
The code checking the aliases:
https://github.com/rust-lang/rust/blob/7fdefb804ec300fb605039522a7c0dfc9e7dc366/compiler/rustc_passes/src/check_attr.rs#L693-L704
``````@rustbot`````` label +A-docs
|
|
Fixup failing fuchsia tests
The Fuchsia platform passes all tests with these changes. Two tests are ignored because they rely on Fuchsia not returning a status code upon a process aborting. See #102032 and #58590 for more details on that topic.
Many formatting changes are also included in this PR.
r? tmandry
r? erickt
|
|
impl FusedIterator and a size hint for the error sources iter
cc tracking issue #58520
|
|
r=compiler-errors,eholk
migration lint for `expr2024` for the edition 2024
This is adding a migration lint for the current (in the 2021 edition and previous)
to move expr to expr_2021 from expr
Issue https://github.com/rust-lang/rust/issues/123742
I created also a repository to test out the migration https://github.com/vincenzopalazzo/expr2024-cargo-fix-migration
Co-Developed-by: ``@eholk``
|
|
compiler-errors:bump-elided_lifetimes_in_associated_constant, r=BoxyUwU
Bump `elided_lifetimes_in_associated_constant` to deny
It's been 5 versions since this was last bumped. Let's bump it up again.
|
