Rollup of 5 pull requests
Successful merges:
- #126620 (Actually taint InferCtxt when a fulfillment error is emitted)
- #126649 (Fix `feature = "nightly"` in the new trait solver)
- #126652 (Clarify that anonymous consts still do introduce a new scope)
- #126703 (reword the hint::blackbox non-guarantees)
- #126708 (Minimize `can_begin_literal_maybe_minus` usage)
r? `@ghost`
`@rustbot` modify labels: rollup
Minimize `can_begin_literal_maybe_minus` usage
`can_begin_literal_maybe_minus` is used in a few confusing ways. This PR makes them clearer.
r? ``@spastorino``
reword the hint::blackbox non-guarantees
People were tripped up by the "precludes", interpreting it that this function must not ever be used in cryptographic contexts rather than the std lib merely making zero promises about it being fit-for-purpose.
What remains unchanged is that if someone does try to use it *despite the warnings* then it is on them to pin their compiler versions and verify the assembly of every single binary build they do.
Clarify that anonymous consts still do introduce a new scope
See https://github.com/rust-lang/rust/issues/120363#issuecomment-2177064702
This error message is misleading: it's trying to say that `const _ : () = ...` is a workaround for the lint, but by saying that anonymous constants are treated as being in the parent scope, it makes them appear useless for scope-hiding.
They *are* useful for scope-hiding, they are simply treated as part of the parent scope when it comes to this lint.
Actually taint InferCtxt when a fulfillment error is emitted
And avoid checking the global error counter
fixes#122044fixes#123255fixes#123276fixes#125799
We currently use `can_begin_literal_maybe_minus` in a couple of places
where only string literals are allowed. This commit introduces a
more specific function, which makes things clearer. It doesn't change
behaviour because the two functions affected (`is_unsafe_foreign_mod`
and `check_keyword_case`) are always followed by a call to `parse_abi`,
which checks again for a string literal.
It's clearer this way, because the `Interpolated` cases in
`can_begin_const_arg` and `is_pat_range_end_start` are more permissive
than the `Interpolated` cases in `can_begin_literal_maybe_minus`.
Implement `array::repeat`
See rust-lang/libs-team#310.
I've decided to make the function use the input value as last element instead of cloning it to every position and dropping it, and to make this part of the API so that callers are not surprised by this behaviour.
TODO: open a tracking issue. I'll wait for the ACP to be accepted, first.
`@rustbot` label +T-libs-api +T-libs
r? libs
People were tripped up by the "precludes", interpreting it that this function
must not ever be used in cryptographic contexts rather than the std lib merely
making zero promises about it being fit-for-purpose.
What remains unchanged is that if someone does try to use it *despite the warnings*
then it is on them to pin their compiler versions and verify the assembly of every
single binary build they do.
Apparently MIR borrowck cares about at least one of these for checking variance.
In runtime MIR, though, there's no need for them as `PtrToPtr` does the same thing.
(Banning them simplifies passes like GVN that no longer need to handle multiple cast possibilities.)
Rework doc-test attribute documentation example
This PR change the doc-test attribute documentation example to prefer a more neutral example `deny(dead_code)`, instead of `deny(warnings)`, which is less susceptible to breakage across Rust version.
r? ```@GuillaumeGomez```
Fix duplicated attributes on nonterminal expressions
This PR fixes a long-standing bug (#86055) whereby expression attributes can be duplicated when expanded through declarative macros.
First, consider how items are parsed in declarative macros:
```
Items:
- parse_nonterminal
- parse_item(ForceCollect::Yes)
- parse_item_
- attrs = parse_outer_attributes
- parse_item_common(attrs)
- maybe_whole!
- collect_tokens_trailing_token
```
The important thing is that the parsing of outer attributes is outside token collection, so the item's tokens don't include the attributes. This is how it's supposed to be.
Now consider how expression are parsed in declarative macros:
```
Exprs:
- parse_nonterminal
- parse_expr_force_collect
- collect_tokens_no_attrs
- collect_tokens_trailing_token
- parse_expr
- parse_expr_res(None)
- parse_expr_assoc_with
- parse_expr_prefix
- parse_or_use_outer_attributes
- parse_expr_dot_or_call
```
The important thing is that the parsing of outer attributes is inside token collection, so the the expr's tokens do include the attributes, i.e. in `AttributesData::tokens`.
This PR fixes the bug by rearranging expression parsing to that outer attribute parsing happens outside of token collection. This requires a number of small refactorings because expression parsing is somewhat complicated. While doing so the PR makes the code a bit cleaner and simpler, by eliminating `parse_or_use_outer_attributes` and `Option<AttrWrapper>` arguments (in favour of the simpler `parse_outer_attributes` and `AttrWrapper` arguments), and simplifying `LhsExpr`.
r? `@petrochenkov`
Rollup of 6 pull requests
Successful merges:
- #125447 (Allow constraining opaque types during subtyping in the trait system)
- #125766 (MCDC Coverage: instrument last boolean RHS operands from condition coverage)
- #125880 (Remove `src/tools/rust-demangler`)
- #126154 (StorageLive: refresh storage (instead of UB) when local is already live)
- #126572 (override user defined channel when using precompiled rustc)
- #126662 (Unconditionally warn on usage of `wasm32-wasi`)
r? `@ghost`
`@rustbot` modify labels: rollup
Unconditionally warn on usage of `wasm32-wasi`
This commit is a continuation of the work originally proposed in rust-lang/compiler-team#607 and later amended in
rust-lang/compiler-team#695. The end goal is to rename `wasm32-wasi` to `wasm32-wasip1` to reflect WASI's development and distinguish the preexisting target from the `wasm32-wasip2` target that WASI is now developing. Work for this transition began in #120468 which landed in Rust 1.78 which became stable on 2024-05-02.
This implements the next phase of the transition plan to warn on usage of `wasm32-wasi`. This is intended to help alert users that a removal is pending and all release channels have the replacement available as well. This will reach stable on 2024-09-05. The next stage of the plan is to remove the `wasm32-wasi` target some time in October 2024 which means that the removal will reach stable on 2025-01-09. For reference a full schedule of this transition is listed [here].
Currently this implementation is a simple unconditional warning whenever `rustc --target wasm32-wasi` is invoked. As-implemented there's no way to turn off the warning other than to switch to the `wasm32-wasip1` target.
[here]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
override user defined channel when using precompiled rustc
We need to override `rust.channel` if it's manually specified when using the CI rustc. This is because if the compiler uses a different channel than the one specified in config.toml, tests may fail due to using a different channel than the one used by the compiler during tests.
For more context, see https://github.com/rust-lang/rust/pull/122709#issuecomment-2165246281.
Remove `src/tools/rust-demangler`
`rust-demangler` is a small binary that reads a list of mangled symbols from stdin, demangles them (using the `rustc-demangle` library crate), and prints the demangled symbols to stdout.
It was added as part of the initial implementation of coverage instrumentation in 2020/2021, so that coverage tests could pass it to `llvm-cov --Xdemangler` when generating coverage reports. It has been largely untouched since then.
As of #125816 it is no longer used by coverage tests, and has no remaining in-tree uses.
There is code in bootstrap to build and package the demangler, but it's unclear where the resulting binaries actually end up, or whether there's any reasonable way for `rustup` users to obtain them.
---
For users needing a command-line demangler, `rustfilt` exists and is more actively maintained. It's also quite easy to use the `rustc-demangle` library to build a custom command-line demangler if necessary, with only a few lines of code.
The tool's name (`rust-demangler`) is easily confused with the name of the library crate `rustc-demangle`, so removing the tool will eliminate that confusion. There also doesn't appear to be much reason to use `rust-demangler` over `rustfilt`.
---
This PR therefore removes the tool, and removes all of its associated code from bootstrap.
MCP filed: https://github.com/rust-lang/compiler-team/issues/754
MCDC Coverage: instrument last boolean RHS operands from condition coverage
Fresh PR from #124652
--
This PR ensures that the top-level boolean expressions that are not part of the control flow are correctly instrumented thanks to condition coverage.
See discussion on https://github.com/rust-lang/rust/issues/124120.
Depends on `@Zalathar` 's condition coverage implementation #125756.
Allow constraining opaque types during subtyping in the trait system
Previous attempt: https://github.com/rust-lang/rust/pull/123979
Sometimes we don't immediately perform subtyping, but instead register a subtyping obligation and solve that obligation when its inference variables become resolved. Unlike immediate subtyping, we currently do not allow registering hidden types for opaque types. This PR also allows that.
It now parses outer attributes before collecting tokens. This avoids the
problem where the outer attribute tokens were being stored twice -- for
the attribute tokesn, and also for the expression tokens.
Fixes#86055.
Rollup of 7 pull requests
Successful merges:
- #123782 (Test that opaque types can't have themselves as a hidden type with incompatible lifetimes)
- #124580 (Suggest removing unused tuple fields if they are the last fields)
- #125787 (Migrate `bin-emit-no-symbols` `run-make` test to `rmake`)
- #126553 (match lowering: expand or-candidates mixed with candidates above)
- #126594 (Make async drop code more consistent with regular drop code)
- #126654 (Make pretty printing for `f16` and `f128` consistent)
- #126656 (rustc_type_ir: Omit some struct fields from Debug output)
r? `@ghost`
`@rustbot` modify labels: rollup
Combine `NotYetParsed` and `AttributesParsed` into a single variant,
because (a) that reflects the structure of the code that consumes
`LhsExpr`, and (b) because that variant will have the `Option` removed
in a later commit.
The `Option<AttrWrapper>` one maps to the first two variants, and the
`P<Expr>` one maps to the third. Weird. The code is shorter and clearer
without them.
