handle rustc args properly in bootstrap
Because `RUSTFLAGS` gets overwritten during the conversion from `Cargo` to `Command`, the passed rustc args were being lost. This change combines the rustc args with the values that override `RUSTFLAGS`.
Fixes#123228
Port `run-make/issue-7349` to a codegen test
The test does not need to be a run-make test, it can use the codegen test infrastructure.
Also took the opportunity to rename the test to `no-redundant-item-monomorphization` so it's not just some opaque issue number.
Part of #121876.
Actually use the inferred `ClosureKind` from signature inference in coroutine-closures
A follow-up to https://github.com/rust-lang/rust/pull/123349, which fixes another subtle bug: We were not taking into account the async closure kind we infer during closure signature inference.
When I pass a closure directly to an arg like `fn(x: impl async FnOnce())`, that should have the side-effect of artificially restricting the kind of the async closure to `ClosureKind::FnOnce`. We weren't doing this -- that's a quick fix; however, it uncovers a second, more subtle bug with the way that `move`, async closures, and `FnOnce` interact.
Specifically, when we have an async closure like:
```
let x = Struct;
let c = infer_as_fnonce(async move || {
println!("{x:?}");
}
```
The outer closure captures `x` by move, but the inner coroutine still immutably borrows `x` from the outer closure. Since we've forced the closure to by `async FnOnce()`, we can't actually *do* a self borrow, since the signature of `AsyncFnOnce::call_once` doesn't have a borrowed lifetime. This means that all `async move` closures that are constrained to `FnOnce` will fail borrowck.
We can fix that by detecting this case specifically, and making the *inner* async closure `move` as well. This is always beneficial to closure analysis, since if we have an `async FnOnce()` that's `move`, there's no reason to ever borrow anything, so `move` isn't artificially restrictive.
Match ergonomics: implement "`&`pat everywhere"
Implements the eat-two-layers (feature gate `and_pat_everywhere`, all editions) ~and the eat-one-layer (feature gate `and_eat_one_layer_2024`, edition 2024 only, takes priority on that edition when both feature gates are active)~ (EDIT: will be done in later PR) semantics.
cc #123076
r? ``@Nadrieril``
``@rustbot`` label A-patterns A-edition-2024
Support running library tests in Miri
This adds a new bootstrap subcommand `./x.py miri` which can test libraries in Miri. This is in preparation for eventually doing that as part of bors CI, but this PR only adds the infrastructure, and doesn't enable it yet.
`@rust-lang/bootstrap` should this be `x.py test --miri library/core` or `x.py miri library/core`? The flag has the advantage that we don't have to copy all the arguments from `Subcommand::Test`. It has the disadvantage that most test steps just ignore `--miri` and still run tests the regular way. For clippy you went the route of making it a separate subcommand. ~~I went with a flag now as that seemed easier, but I can change this.~~ I made it a new subcommand. Note however that the regular cargo invocation would be `cargo miri test ...`, so `x.py` is still going to be different in that the `test` is omitted. That said, we could also make it `./x.py miri-test` to make that difference smaller -- that's in fact more consistent with the internal name of the command when bootstrap invokes cargo.
`@rust-lang/libs` ~~unfortunately this PR does some unholy things to the `lib.rs` files of our library crates.~~
`@m-ou-se` found a way that entirely avoids library-level hacks, except for some new small `lib.miri.rs` files that hopefully you will never have to touch. There's a new hack in cargo-miri but there it is in good company...
Because `RUSTFLAGS` gets overwritten during the conversion from `Cargo` to `Command`,
the passed rustc args were being lost. This change combines the rustc args with the values
that override `RUSTFLAGS`.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
This is achieved by converting `+<fpu>,-d32,{,-fp64}` to `+<fpu>d16{,sp}`.
By using a single additive feature that captures `d16` vs `d32` and `sp` vs
`dp`, we prevent `-<feature>` from overriding `-C target-cpu` at build time.
Remove extraneous `-fp16` from `armv7r` targets, as this is not included in
`vfp3` anyway, but was preventing `fp16` from being enabled by e.g.,
`-C target-cpu=cortex-r7`, which does support `fp16`.
Restore typeid_for_instance default behavior of performing self type
erasure, since it's the most common case and what it does most of the
time. Using concrete self (or not performing self type erasure) is for
assigning a secondary type id, and secondary type ids are only assigned
when they're unique and to methods, and also are only tested for when
methods are used as function pointers.
Rollup of 9 pull requests
Successful merges:
- #123206 (Require Pointee::Metadata to be Freeze)
- #123363 (change `NormalizesTo` to fully structurally normalize)
- #123407 (Default to light theme if JS is enabled but not working)
- #123417 (Add Description for cargo in rustdoc documentation)
- #123437 (Manually run `clang-format` on `CoverageMappingWrapper.cpp`)
- #123454 (hir: Use `ItemLocalId::ZERO` in a couple more places)
- #123464 (Cleanup: Rename `HAS_PROJECTIONS` to `HAS_ALIASES` etc.)
- #123477 (do not ICE in `fn forced_ambiguity` if we get an error)
- #123478 (CFI: Add test for `call_once` addr taken)
r? `@ghost`
`@rustbot` modify labels: rollup
CFI: Add test for `call_once` addr taken
One of the proposed ways to reduce the non-passed argument erasure would cause this test to fail. Adding this now ensures that any attempt to reduce non-passed argument erasure won't make the same mistake.
r? `@compiler-errors`
cc `@rcvalle`
do not ICE in `fn forced_ambiguity` if we get an error
see the comment. currently causing an ICE in typenum which we've been unable to minimize.
r? `@compiler-errors`
Cleanup: Rename `HAS_PROJECTIONS` to `HAS_ALIASES` etc.
The name of the bitflag `HAS_PROJECTIONS` and of its corresponding method `has_projections` is quite historical dating back to a time when projections were the only kind of alias type.
I think it's time to update it to clear up any potential confusion for newcomers and to reduce unnecessary friction during contributor onboarding.
r? types
Manually run `clang-format` on `CoverageMappingWrapper.cpp`
In the current version of #123409, there are several unrelated changes to `CoverageMappingWrapper.cpp` that seem to be the result of running `clang-format` on that file.
Instead of asking for those changes to be undone, I figure it's easier to just make them myself as a separate PR, since I was vaguely intending to do that at some point anyway.
In a few cases I've strategically added comments to make the grouping of parameters a little nicer, but mostly it doesn't matter much.
Add Description for cargo in rustdoc documentation
As most people use cargo now, I prioritised the description for cargo in rustdoc documentation.
I also added how to open the generated doc with cargo.
Btw, may I ask how to use `./x tidy`? It says `warning: `tidy` is not installed;`
Default to light theme if JS is enabled but not working
It doesn't [fix] #123399 but it allows to reduce the problem:
* if JS is completely disabled, then `noscript.css` will be applied
* if JS failed for any reason, then the light theme will be applied (because `noscript.css` won't be applied)
r? `@notriddle`
change `NormalizesTo` to fully structurally normalize
notes in https://hackmd.io/wZ016dE4QKGIhrOnHLlThQ
need to also update the dev-guide once this PR lands. in short, the setup is now as follows:
`normalizes-to` internally implements one step normalization, applying that normalization to the `goal.predicate.term` causes the projected term to get recursively normalized. With this `normalizes-to` normalizes until the projected term is rigid, meaning that we normalize as many steps necessary, but at least 1.
To handle rigid aliases, we add another candidate only if the 1 to inf step normalization failed. With this `normalizes-to` is now full structural normalization. We can now change `AliasRelate` to simply emit `normalizes-to` goals for the rhs and lhs.
This avoids the concerns from https://github.com/rust-lang/trait-system-refactor-initiative/issues/103 and generally feels cleaner
One of the proposed ways to reduce the non-passed argument erasure would
cause this test to fail. Adding this now ensures that any attempt to
reduce non-passed argument erasure won't make the same mistake.
