Per #112156, using `&` in `format!` may cause a small perf delay, so I tried to clean up one module at a time format usage. This PR includes a few removals of the ref in format (they do compile locally without the ref), as well as a few format inlining for consistency.
GCC uses the `-fshort-enums` ABI for arm-none and the `int`-sized enum
ABI for arm-linux.
Clang uses the `int`-sized enum ABI for all arm targets.
Both options are permitted by AAPCS.
Rust is matching GCC's behavior for these targets, as interop with code
code compiled by GCC is desirable in the bare-metal context. See #87917.
Fix #[inline(always)] on closures with target feature 1.1
Fixes#108655. I think this is the most obvious solution that isn't overly complicated. The comment includes more justification, but I think this is likely better than demoting the `#[inline(always)]` to `#[inline]`, since existing code is unaffected.
Support interpolated block for `try` and `async`
I'm putting this up for T-lang discussion, to decide whether or not they feel like this should be supported. This was raised in #112952, which surprised me. There doesn't seem to be a *technical* reason why we don't support this.
### Precedent:
This is supported:
```rust
macro_rules! always {
($block:block) => {
if true $block
}
}
fn main() {
always!({});
}
```
### Counterpoint:
However, for context, this is *not* supported:
```rust
macro_rules! unsafe_block {
($block:block) => {
unsafe $block
}
}
fn main() {
unsafe_block!({});
}
```
If this support for `async` and `try` with interpolated blocks is *not* desirable, then I can convert them to instead the same diagnostic as `unsafe $block` and make this situation a lot less ambiguous.
----
I'll try to write up more before T-lang triage on Tuesday. I couldn't find anything other than #69760 for why something like `unsafe $block` is not supported, and even that PR doesn't have much information.
Fixes#112952
Remove Scope::Elision from bound-vars resolution.
This scope is a remnant of HIR-based lifetime resolution.
It's only role was to ensure that object lifetime resolution falled back to `'static`. This can be done using `ObjectLifetimeDefault` scope.
Get rid of subst-relate incompleteness in new solver
We shouldn't need subst-relate if we have bidirectional-normalizes-to in the new solver.
The only potential issue may happen if we have an unconstrained projection like `<Wrapper<?0> as Trait>::Assoc == <Wrapper<T> as Trait>::Assoc` where they both normalize to something that doesn't mention any substs, which would possibly prefer `?0 = T` if we fall back to subst-relate. But I'd prefer if we remove incompleteness until we can determine some case where we need them, and the bidirectional-normalizes-to seems better to have in general.
I can update https://github.com/rust-lang/trait-system-refactor-initiative/issues/26 and https://github.com/rust-lang/trait-system-refactor-initiative/issues/25 once this lands.
r? `@lcnr`
Tweak spans for self arg, fix borrow suggestion for signature mismatch
1. Adjust a suggestion message that was annoying me
2. Fix#112503 by recording the right spans for the `self` part of the `&self` 0th argument
3. Remove the suggestion for adjusting a trait signature on type mismatch, bc that's gonna probably break all the other impls of the trait even if it fixes its one usage 😅
Reuse the MIR validator for MIR inlining
Instead of having the inliner home-cook its own validation, we just check that the substituted MIR body passes the regular validation.
The MIR validation is first split in two: control flow validation (MIR syntax and CFG invariants) and type validation (subtyping relationship in assignments and projections). Only the latter can be affected by instantiating type parameters.
editor/code: Break down CI steps to know what is failing easily
This do the thing I mentioned in https://github.com/rust-lang/rust-analyzer/pull/15265#issuecomment-1634424385
This aims to improve CI status check more readable.
I tried to use [`jobs.<job_id>.if`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif) to make the configuration
more shortly once.
But it could not fire the `end-success` or `end-failure` status if some jobs in the workflow were skipped. This causes an integration problem with bors.
By their reasons, this patch still uses `jobs.<job_id>.steps[*].if`.
---
To do this change, we reorganize npm-script.
| previous | after |
|--------------------|----------------------------------------|
| `npm run lint` | `npm run lint && npm run format:check` |
| `npm run fix` | `npm run lint:fix && npm run format` |
The previous `npm run fix` sometimes does not complete fix automatically because ESLint's autofix doees not follow prettier's formatting. So we need to run `npm run lint:fix && npm run format` by this order.
To do this change, we reorganize npm-script.
| previous | after |
|--------------------|----------------------------------------|
| `npm run lint` | `npm run lint && npm run format:check` |
| `npm run fix` | `npm run lint:fix && npm run format` |
The previous `npm run fix` sometimes does not complete fix automatically
because ESLint's autofix doees not follow prettier's formatting.
So we need to run `npm run lint:fix && npm run format` by this order.
Sync rustc_codegen_cranelift
This time Cranelift has been updated to 0.98. A couple of bugs have been fixed and a decent amount of x86 vendor intrinsics have been implemented.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
limit `change_visibility` assist to applicable items
this pr limits the `change_visibility` assist to applicable items. top level items in this context means items that are not nested within `fn`s or `trait`s.
now
```rs
fn foo {
// assists on this `struct` keyword won't include `change_visibility`
struct Bar {}
}
trait Foo {
// same with the `fn` here
fn bar();
}
```
