A small diagnostic improvement for dropping_copy_types
For a value `m` which implements `Copy` trait, `drop(m);` does nothing.
We now suggest user to ignore it by a abstract and general note: `let _ = ...`.
I think we can give a clearer note here: `let _ = m;`
fixes#125189
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Currently we can't automatically enforce formatting on tests (see #125637), but
we can at least keep things relatively tidy by occasionally running the
formatter manually.
This was done by temporarily commenting out the `"/tests/"` exclusion in
`rustfmt.toml`, and then running `x fmt tests/coverage` and
`x test coverage --bless`.
For coverage tests, splitting code across multiple lines often makes the
resulting coverage report easier to interpret, so we force rustfmt to retain
line breaks by adding dummy line comments with `//`.
Silence some resolve errors when there have been glob import errors
When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors.
A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors.
Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unnameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over.
Partially address #96799.
Make more of the test suite run on Mac Catalyst
Combined with https://github.com/rust-lang/rust/pull/125225, the only failing parts of the test suite are in `tests/rustdoc-js`, `tests/rustdoc-js-std` and `tests/debuginfo`. Tested with:
```console
./x test --target=aarch64-apple-ios-macabi library/std
./x test --target=aarch64-apple-ios-macabi --skip=tests/rustdoc-js --skip=tests/rustdoc-js-std --skip=tests/debuginfo tests
```
Will probably put up a PR later to enable _running_ on (not just compiling for) Mac Catalyst in CI, though not sure where exactly I should do so? `src/ci/github-actions/jobs.yml`?
Note that I've deliberately _not_ enabled stack overflow handlers on iOS/tvOS/watchOS/visionOS (see https://github.com/rust-lang/rust/issues/25872), but rather just skipped those tests, as it uses quite a few APIs that I'd be weary about getting rejected by the App Store (note that Swift doesn't do it on those platforms either).
r? ``@workingjubilee``
CC ``@thomcc``
``@rustbot`` label O-ios O-apple
Add `--print=check-cfg` to get the expected configs
This PR adds a new `--print` variant `check-cfg` to get the expected configs.
Details and rational can be found on the MCP: https://github.com/rust-lang/compiler-team/issues/743
``@rustbot`` label +F-check-cfg +S-waiting-on-MCP
r? ``@petrochenkov``
When we encounter a situation where we'd suggest `pin!()`, we now account for that expression exising as part of an assignment and provide an appropriate suggestion:
```
error[E0599]: no method named `poll` found for type parameter `F` in the current scope
--> $DIR/pin-needed-to-poll-3.rs:19:28
|
LL | impl<F> Future for FutureWrapper<F>
| - method `poll` not found for this type parameter
...
LL | let res = self.fut.poll(cx);
| ^^^^ method not found in `F`
|
help: consider pinning the expression
|
LL ~ let mut pinned = std::pin::pin!(self.fut);
LL ~ let res = pinned.as_mut().poll(cx);
|
```
Fix#125661.
The following suggestion is incorrect, as it doesn't account for the binding:
```
error[E0599]: no method named `poll` found for type parameter `F` in the current scope
--> $DIR/pin-needed-to-poll-3.rs:19:28
|
LL | impl<F> Future for FutureWrapper<F>
| - method `poll` not found for this type parameter
...
LL | let res = self.fut.poll(cx);
| ^^^^ method not found in `F`
|
help: consider pinning the expression
|
LL ~ let res = let mut pinned = std::pin::pin!(self.fut);
LL ~ pinned.as_mut().poll(cx);
|
```
NVPTX: Avoid PassMode::Direct for args in C abi
Fixes#117480
I must admit that I'm confused about `PassMode` altogether, is there a good sum-up threads for this anywhere? I'm especially confused about how "indirect" and "byval" goes together. To me it seems like "indirect" basically means "use a indirection through a pointer", while "byval" basically means "do not use indirection through a pointer".
The return used to keep `PassMode::Direct` for small aggregates. It turns out that `make_indirect` messes up the tests and one way to fix it is to keep `PassMode::Direct` for all aggregates. I have mostly seen this PassMode mentioned for args. Is it also a problem for returns? When experimenting with `byval` as an alternative i ran into [this assert](61a3eea804/compiler/rustc_codegen_llvm/src/abi.rs (L463C22-L463C22))
I have added tests for the same kind of types that is already tested for the "ptx-kernel" abi. The tests cannot be enabled until something like #117458 is completed and merged.
CC: ``@RalfJung`` since you seem to be the expert on this and have already helped me out tremendously
CC: ``@RDambrosio016`` in case this influence your work on `rustc_codegen_nvvm`
``@rustbot`` label +O-NVPTX
Omit non-needs_drop drop_in_place in vtables
This replaces the drop_in_place reference with null in vtables. On librustc_driver.so, this drops about ~17k (11%) dynamic relocations from the output, since many vtables can now be placed in read-only memory, rather than having a relocated pointer included.
This makes a tradeoff by adding a null check at vtable call sites. I'm not sure that's readily avoidable without changing the vtable format (e.g., so that we can use a pc-relative relocation instead of an absolute address, and avoid the dynamic relocation that way). But it seems likely that the check is cheap at runtime.
Accepted MCP: https://github.com/rust-lang/compiler-team/issues/730
When encountering `use foo::*;` where `foo` fails to be found, and we later
encounter resolution errors, we silence those later errors.
A single case of the above, for an *existing* import on a big codebase would
otherwise have a huge number of knock-down spurious errors.
Ideally, instead of a global flag to silence all subsequent resolve errors,
we'd want to introduce an unameable binding in the appropriate rib as a
sentinel when there's a failed glob import, so when we encounter a resolve
error we can search for that sentinel and if found, and only then, silence
that error. The current approach is just a quick proof of concept to
iterate over.
Partially address #96799.
This adds the `only-apple`/`ignore-apple` compiletest directive, and
uses that basically everywhere instead of `only-macos`/`ignore-macos`.
Some of the updates in `run-make` are a bit redundant, as they use
`ignore-cross-compile` and won't run on iOS - but using Apple in these
is still more correct, so I've made that change anyhow.
`-Znext-solver`: eagerly normalize when adding goals
fixes#125269. I am not totally with this fix and going to keep this open until we have a more general discussion about how to handle hangs caused by lazy norm in the new solver.
We still check for the `rental`/`allsorts-rental` crates. But now if
they are detected we just emit a fatal error, instead of emitting a
warning and providing alternative behaviour.
The original "hack" implementing alternative behaviour was added
in #73345.
The lint was added in #83127.
The tracking issue is #83125.
The direct motivation for the change is that providing the alternative
behaviour is interfering with #125174 and follow-on work.
