Example
---
```rust
macro_rules! foo {
($($x:$0)*) => ();
}
```
**Completion items**:
```text
ba block
ba expr
ba expr_2021
ba ident
ba item
ba lifetime
ba literal
ba meta
ba pat
ba pat_param
ba path
ba stmt
ba tt
ba ty
ba vis
```
It sees them as regular impls; the details are abstracted. It's beautiful for the IDE layer, and less beautiful for `hir`, so this is a big change.
Some small differences still exist:
- We show builtin derives impl (to the IDE layer) as if they have had no generic parameters. It is possible to show the parameters, but that means also having to handle fake impls in `TypeParam` etc., and the benefit is questionable.
- Getting the fn *def* type of a method of a builtin derive impl is not supported, as there is no real `FunctionId`, therefore no `CallableDefId`. The trait method is returned instead. Note: getting the fn *ptr* type of the method is supported well.
- Builtin derive impls and their methods do not fully support `HasSource`, because, well, they have no source (at least, not in the form of `ast::Impl` and `ast::Fn`). To support them, we use the derive's `TextRange` where possible, and the trait method's source when not.
It's important to note that the def map still records the `MacroCallId`. I have doubts over this, as this means it's very easy to create the queries we don't want to create, but it does make things more convenient. In particular, a nicety of this setup is that even "Expand macro recursively" works (it creates the macro input/output query, but given that they will only be created when the user invokes the command, that does not seem to be a problem).
And remove it when needed, the opposite of what was previously, where we stored without a tuple and tupled for the solver (because it requires that).
Because this is what rustc does, and generally, the closer we follow rustc, the easier our lives become.
The weird name `signature_unclosure()` also comes from rustc.
Remap both absolute and relative paths when building `rustc` and `std`
Turns out [#150110](https://github.com/rust-lang/rust/issues/150110) didn't work as expected, because when the standard library sources are present, we [helpfully un-remap the paths](e951f470d7/compiler/rustc_metadata/src/rmeta/decoder.rs (L1656-L1702)) to the local directory of the user, including when we are building the compiler and standard library it-self (duh!), and since those paths are absolute (not relative), our purely relative remapping didn't pick them up.
This behavior wasn't a issue before because the un-remap logic immediately tries to remap them again, and since we had the absolute remapping we would just remap them to the the same thing.
To fix that issue I've adjusted our remapping to remap both the absolute and relative paths when building `rustc` and `std`, as well as added a run-make to make sure we don't regress it again (with a new `needs-std-remap-debuginfo` directive).
r? `@jieyouxu`
The diagnostics collection globally tracks the generation for all loaded workspaces as its shared between them, yet the flycheck actors track their own separate generations per workspace.
This mismatch could cause flycheck to not work correctly when multiple workspaces were loaded.
std: Use `usleep` temporarily on WASI targets
This fixes some fallout from rust-lang/rust#147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to rust-lang/rust#149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release.
Closesrust-lang/rust#150290
remove llvm_enzyme and enzyme fallbacks from most places
Using dlopen to get symbols has the nice benefit that rustc itself doesn't depend on libenzyme symbols anymore. We can therefore delete most fallback implementations in the backend (independently of whether we enable enzyme or not). When trying to use autodiff on nightly, we will now fail with a nice error if and only if we fail to load libEnzyme-21.so in our backend.
Verified:
Build as nightly, without Enzyme
Build as nightly, with Enzyme
Build as stable (without Enzyme)
With this PR we will now run `tests/ui/autodiff` on nightly, the tests are passing.
r? `@kobzol`
fix ICE when {{root}} appears in import suggestions
Fixesrust-lang/rust#150103
When wrong nested imports like `use A::{::Fish}` were used, the internal {{root}} would appear in diagnostic suggestions, causing an ICE in `join_path_idents` which asserted that **{{root}} should only appear at the start of a path**.
r? ``@matthiaskrgr``
