Don't expect a rcvr in `print_disambiguation_help`
We don't necessarily have a receiver when we are both accidentally using the `.` operator *AND* we have more than one ambiguous method candidate.
Fixes#117728
fix: Diagnose everything in nested items, not just def diagnostics
Turns out we only calculated def diagnostics for these before (was wondering why I wasn't getting any type mismatches)
internal: Migrate assists to the structured snippet API, part 4
Continuing from #15260
Migrates the following assists:
- `add_turbo_fish`
- `add_type_ascription`
- `destructure_tuple_binding`
- `destructure_tuple_binding_in_subpattern`
I did this a while ago, but forgot to make a PR for the changes until now. 😅
rustc_log: provide a way to init logging based on the values, not names, of the env vars
Miri wants to affect how rustc does logging. So far this required setting environment variables before calling `rustc_driver::init_rustc_env_logger`. However, `set_var` is a function one should really [avoid calling](https://github.com/rust-lang/rust/issues/90308), so this adds the necessary APIs to rustc such that Miri can just pass it the *values* of all the log-relevant environment variables, rather than having to change the global environment.
Add richer structure for Stable MIR Projections
Resolves https://github.com/rust-lang/project-stable-mir/issues/49.
Projections in Stable MIR are currently just strings. This PR replaces that representation with a richer structure, namely projections become vectors of `ProjectionElem`s, just as in MIR. The `ProjectionElem` enum is heavily based off of the MIR `ProjectionElem`.
This PR is a draft since there are several outstanding issues to resolve, including:
- How should `UserTypeProjection`s be represented in Stable MIR? In MIR, the projections are just a vector of `ProjectionElem<(),()>`, meaning `ProjectionElem`s that don't have Local or Type arguments (for `Index`, `Field`, etc. objects). Should `UserTypeProjection`s be represented this way in Stable MIR as well? Or is there a more user-friendly representation that wouldn't drag along all the `ProjectionElem` variants that presumably can't appear?
- What is the expected behavior of a `Place`'s `ty` function? Should it resolve down the chain of projections so that something like `*_1.f` would return the type referenced by field `f`?
- Tests should be added for `UserTypeProjection`
minor: Allow multiple snippet edits in a `TextDocumentEdit`
Explicitly[^1] allow a single `TextDocumentEdit` to have multiple `SnippetTextEdit`s. This allows things like renaming extracted variables and functions without having to go through a separate rename step. For an example of what this looks like, see the video in [this comment](https://github.com/microsoft/vscode/issues/145374#issuecomment-1177341711).
The behavior described here lines up with [what VSCode does](bdc113ffe1/src/vscode-dts/vscode.d.ts (L3728-L3731)), and presumably what the eventual LSP behavior will be.
[^1]: This was technically the case before #15269, a single `TextDocumentEdit` always had multiple edits which were `InsertTextFormat.Snippet` as all of the edits were marked as being snippets, even if there weren't any tab stops or placeholders.
