Support tail calls in mir via `TerminatorKind::TailCall`
This is one of the interesting bits in tail call implementation — MIR support.
This adds a new `TerminatorKind` which represents a tail call:
```rust
TailCall {
func: Operand<'tcx>,
args: Vec<Operand<'tcx>>,
fn_span: Span,
},
```
*Structurally* this is very similar to a normal `Call` but is missing a few fields:
- `destination` — tail calls don't write to destination, instead they pass caller's destination to the callee (such that eventual `return` will write to the caller of the function that used tail call)
- `target` — similarly to `destination` tail calls pass the caller's return address to the callee, so there is nothing to do
- `unwind` — I _think_ this is applicable too, although it's a bit confusing
- `call_source` — `become` forbids operators and is not created as a lowering of something else; tail calls always come from HIR (at least for now)
It might be helpful to read the interpreter implementation to understand what `TailCall` means exactly, although I've tried documenting it too.
-----
There are a few `FIXME`-questions still left, ideally we'd be able to answer them during review ':)
-----
r? `@oli-obk`
cc `@scottmcm` `@DrMeepster` `@JakobDegen`
Cache hir_owner_nodes in ParentHirIterator.
Lint level computation may traverse deep HIR trees using that iterator. This calls `hir_owner_nodes` many times for the same HIR owner, which is wasterful.
This PR caches the value to allow a more efficient iteration scheme.
r? ghost for perf
Make `can_eq` process obligations (almost) everywhere
Move `can_eq` to an extension trait on `InferCtxt` in `rustc_trait_selection`, and change it so that it processes obligations. This should strengthen it to be more accurate in some cases, but is most important for the new trait solver which delays relating aliases to `AliasRelate` goals. Without this, we always basically just return true when passing aliases to `can_eq`, which can lead to weird errors, for example #127149.
I'm not actually certain if we should *have* `can_eq` be called on the good path. In cases where we need `can_eq`, we probably should just be using a regular probe.
Fixes#127149
r? lcnr
Add an option to use "::" for the external crate prefix.
Fixes#11823 .
Hi I'm very new to rust-analyzer and not sure how the review process are. Can somebody take a look at this PR? thanks!
Bootstrap command refactoring: quality-of-life improvements (step 4)
Continuation of https://github.com/rust-lang/rust/pull/127120.
This PR simply introduce two new functions (`BootstrapCommand:run` and `command`) that make it a bit easier to use commands in bootstrap. It also adds several `#[must_use]` annotations. This shouldn't (hopefully) have any effect on behavior.
Especially the first commit IMO makes any code that runs commands more readable, and allows using the API in a fluent way, without needing to jump back and forth between the command and the `Build(er)`.
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
fix: Fix runnables being incorrectly constructed
I've misunderstood parts of the code here which caused runnables to arbitrarily break :) (I have yet to understand the conditions that made them break though, there is some odd caching involved I feel like ...)
Fixes https://github.com/rust-lang/rust-analyzer/issues/17402
Elaboration tweaks
Removes `Filter::OnlySelfThatDefines` and reimplements `transitive_bounds_that_define_assoc_item` as a separate function, since I don't want to have to uplift that mode since it's both an implementation detail (only exists to avoid cycles in astconv) and requires exposing `Ident` as an associated type on `Interner`.
r? lcnr
internal: Clean up runnable lsp extension
This feels like a natural addition to me, and also allows us to drop the expect-test hardcoding from the extension. Additionally, `cargoExtraArgs` is pointless, all the client will do is merge it with `cargoArgs` so the server can do that instead of delegating that to the client.
implement `libc::sched_setaffinity` on linux
fixes https://github.com/rust-lang/miri/issues/2749
the implementation, like `libc::sched_getaffinity`, just always returns `EINVAL`, which kind of simulates a device with zero cpus. I believe the idea is that callers of this function always do it to optimize, so they are likely to gracefully recover from this function returning an error.
based on the libc crate, these functions are also available on android and freebsd (but not on macos or windows). So should the implementation of the `sched_*` functions just be copied to the android and freebsd shims?
Rollup of 8 pull requests
Successful merges:
- #123600 (impl PathBuf::add_extension and Path::with_added_extension)
- #127107 (Improve dead code analysis)
- #127221 (Improve well known value check-cfg diagnostic for the standard library)
- #127333 (Split `SolverDelegate` back out from `InferCtxtLike`)
- #127363 (Improve readability of some fmt code examples)
- #127366 (Use `ControlFlow` results for visitors that are only looking for a single value)
- #127368 (Added dots at the sentence ends of rustc AST doc)
- #127393 (Remove clubby789 from review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove clubby789 from review rotation
These days I'm unfortunately too busy to be able to take up reviews, and it looks like some PRs have been blocked on this 😓
