Remove latest Windows SDK from 32-bit CI
This is an alternative to #137766, in case that doesn't work. It is in some ways simpler but is less principled and may be more flaky (as it involves deleting stuff).
try-job: i686-msvc-1
try-job: i686-msvc-2
try-job: dist-i686-msvc
Rollup of 8 pull requests
Successful merges:
- #136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing)
- #136579 (Fix UB in ThinVec::flat_map_in_place)
- #136688 (require trait impls to have matching const stabilities as the traits)
- #136846 (Make `AssocOp` more like `ExprKind`)
- #137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`)
- #137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`)
- #137480 (Return unexpected termination error instead of panicing in `Thread::join`)
- #137694 (Spruce up `AttributeKind` docs)
r? `@ghost`
`@rustbot` modify labels: rollup
Provide a better suggestion message, and make the suggestion verbose.
```
error[E0703]: invalid ABI: found `riscv-interrupt`
--> $DIR/riscv-discoverability-guidance.rs:17:8
|
LL | extern "riscv-interrupt" fn isr() {}
| ^^^^^^^^^^^^^^^^^ invalid ABI
|
= note: invoke `rustc --print=calling-conventions` for a full list of supported calling conventions
help: there's a similarly named valid ABI `"riscv-interrupt-m"`
|
LL | extern "riscv-interrupt-m" fn isr() {}
| ++
```
Don't infer attributes of virtual calls based on the function body
Fixes (after backport) #137646.
Since we don't know the exact implementation of the virtual call, it might write to parameters, we can't infer the readonly attribute.
Wasmtime's `--wasm-features` and `--wasi-modules` flags have been renamed
since these docs were initially written.
Additionally, from my testing I don't believe `--wasm threads` is needed if
`--wasi threads` is passed already.
Note: there was an existing code path involving `Interpolated` in
`MetaItem::from_tokens` that was dead. This commit transfers that to the
new form, but puts an `unreachable!` call inside it.
The one notable test change is `tests/ui/macros/trace_faulty_macros.rs`.
This commit removes the complicated `Interpolated` handling in
`expected_expression_found` that results in a longer error message. But
I think the new, shorter message is actually an improvement.
The original complaint was in #71039, when the error message started
with "error: expected expression, found `1 + 1`". That was confusing
because `1 + 1` is an expression. Other than that, the reporter said
"the whole error message is not too bad if you ignore the first line".
Subsequently, extra complexity and wording was added to the error
message. But I don't think the extra wording actually helps all that
much. In particular, it still says of the `1+1` that "this is expected
to be expression". This repeats the problem from the original complaint!
This commit removes the extra complexity, reverting to a simpler error
message. This is primarily because the traversal is a pain without
`Interpolated` tokens. Nonetheless, I think the error message is
*improved*. It now starts with "expected expression, found `pat`
metavariable", which is much clearer and the real problem. It also
doesn't say anything specific about `1+1`, which is good, because the
`1+1` isn't really relevant to the error -- it's the `$e:pat` that's
important.
Out of cycle sync, as it is complicated and confusing to resolve merge
conflicts on the Rust side. This needs review for
eda3e649a41e0e73cb2e3ee6b98cbf8d7c12acae and
4d8766caaf11a14194406b8997243bb626000aae as well as the comment I'll
leave below.
changelog: none
This feature was stabilized, so the FormatArgs lints should check if the MSRV of
the stabilization is met, rather than checking if the feature is enabled.
Fix 32-bit MSVC CI
By throwing more hardware at it. The large runners should still use the old image. This could buy us a couple of... hours? Days? Who knows.
See https://github.com/rust-lang/rust/issues/137733 for context.
r? `@ghost`
try-job: i686-msvc-1
try-job: i686-msvc-2
try-job: dist-i686-msvc
It is not possible to write a declarative macro, that produces an
attribute w/o
an item attached to it. This means that the `check_item` will already
insert the
span in the map, if it came from an expansion. So additionally checking
if the
macro came from an expansion doesn't add anything here. So the
`check_attribute` function, and with that the problematic `attr.span()`
call can
be completely removed.
Fixes https://github.com/rust-lang/rust-clippy/issues/14303
r? @y21
cc @jdonszelmann
changelog: Fix ICE in [`macro_use_import`] lint
It is not possible to write a declarative macro, that produces an attribute w/o
an item attached to it. This means that the `check_item` will already insert the
span in the map, if it came from an expansion. So additionally checking if the
macro came from an expansion doesn't add anything here. So the
`check_attribute` function, and with that the problematic `attr.span()` call can
be completely removed.
Fixes#14303
That unstable feature completed fcp-close, so the compiler needs to be
migrated away to allow its removal. In this case, `cg_llvm` and `cg_gcc`
were using raw entries to optimize their `const_str_cache` lookup and
insertion. We can change that to separate `get` and (on miss) `insert`
calls, so we still have the fast path avoiding string allocation when
the cache hits.
