Emit `'_` for lifetime generics in `HirDisplay`
This makes the generated code not linted by `rust_2018_idioms` lint. But that is an allow by default lint, so should we do this? Maybe we should only do this for `DisplayTarget::SourceCode`?
fix: consider outer binders when folding captured items' type
Fixes#14966
Basically, the crash is caused by us producing a broken type and passing it to chalk: `&dyn for<type> [for<> Implemented(^1.0: A<^0.0>)]` (notice the innermost bound var `^0.0` has no corresponding binder). It's created in `CapturedItemWithoutTy::with_ty()`, which didn't consider outer binders when folding types to replace placeholders with bound variables.
The fix is one-liner, but I've also refactored the surrounding code a little.
- use `DefWithBodyId::as_generic_def_id()`
- add comments on `InferenceResult` invariant
- move local helper function to bottom to comply with style guide
MIR episode 5
This PR inits drop support (it is very broken at this stage, some things are dropped multiple time, drop scopes are wrong, ...) and adds stdout support (`println!` doesn't work since its expansion is dummy, but `stdout().write(b"hello world\n")` works if you use `RA_SYSROOT_HACK`) for interpreting. There is no useful unit test that it can interpret yet, but it is a good sign that it didn't hit a major road block yet.
In MIR lowering, it adds support for slice pattern and anonymous const blocks, and some fixes so that we can evaluate `SmolStr::new_inline` in const eval. With these changes, 57 failed mir body remains.
fix: Diagnose non-value return and break type mismatches
Could definitely deserve more polished diagnostics, but this at least brings the message across for now.
Introduce macro sub-namespaces and `macro_use` prelude
This PR implements two mechanisms needed for correct macro name resolution: macro sub-namespace and `macro_use` prelude.
- [macro sub-namespaces][subns-ref]
Macros have two sub-namespaces: one for function-like macro and the other for those in attributes (including custom derive macros). When we're resolving a macro name for function-like macro, we should ignore non-function-like macros, and vice versa.
This helps resolve single-segment macro names because we can (and should, as rustc does) fallback to names in preludes when the name in the current module scope is in different sub-namespace.
- [`macro_use` prelude][prelude-ref]
`#[macro_use]`'d extern crate declarations (including the standard library) bring their macros into scope, but they should not be prioritized over local macros (those defined in place and those explicitly imported).
We have been bringing them into legacy (textual) macro scope, which has the highest precedence in name resolution. This PR introduces the `macro_use` prelude in crate-level `DefMap`s, whose precedence is lower than local macros but higher than the standard library prelude.
The first 3 commits are drive-by fixes/refactors.
Fixes#8828 (prelude)
Fixes#12505 (prelude)
Fixes#12734 (prelude)
Fixes#13683 (prelude)
Fixes#13821 (prelude)
Fixes#13974 (prelude)
Fixes#14254 (namespace)
[subns-ref]: https://doc.rust-lang.org/reference/names/namespaces.html#sub-namespaces
[prelude-ref]: https://doc.rust-lang.org/reference/names/preludes.html#macro_use-prelude
Make line-index a lib, use nohash_hasher
These seem like they are not specific to rust-analyzer and could be pulled out to their own libraries. So I did.
https://github.com/azdavis/millet/issues/31
Register obligations during path inference
Fixes#14635
When we infer path expressions that resolve to some generic item, we need to consider their generic bounds. For example, when we resolve a path `Into::into` to `fn into<?0, ?1>` (note that `?0` is the self type of trait ref), we should register an obligation `?0: Into<?1>` or else their relationship would be lost.
Relevant part in rustc is [`add_required_obligations_with_code()`] that's called in [`instantiate_value_path()`].
[`instantiate_value_path()`]: 3462f79e94/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs (L1052)
[`add_required_obligations_with_code()`]: 3462f79e94/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs (L1411)
Fix explicit deref problems in closure capture
fix the `need-mut` part of #14562
Perhaps surprisingly, it wasn't unique immutable borrow. The code still doesn't emit any of them, and I think those won't happen in edition 2021 (which is currently the only thing implemented), since we always capture `&mut *x` instead of `&mut x`. But I'm not very sure about it.
Normalize associated types in paths in expressions
Part of #14393
When we resolve paths in expressions (either path expressions or paths in struct expressions), there's a need of projection normalization, which `TyLoweringContext` cannot do on its own. We've been properly applying normalization for paths in struct expressions without type anchor, but not for others:
```rust
enum E {
S { v: i32 }
Empty,
}
impl Foo for Bar {
type Assoc = E;
fn foo() {
let _ = Self::Assoc::S { v: 42 }; // path in struct expr without type anchor; we already support this
let _ = <Self>::Assoc::S { v: 42 }; // path in struct expr with type anchor; resolves with this PR
let _ = Self::Assoc::Empty; // path expr; resolves with this PR
}
}
```
With this PR we correctly resolve the whole path, but we need some more tweaks in HIR and/or IDE layers to properly resolve a qualifier (prefix) of such paths and provide IDE features that are pointed out in #14393 to be currently broken.
MIR episode 3
This PR adds lowering for try operator and overloaded dereference, and adds evaluating support for function pointers and trait objects. It also adds a flag to `analysis-stats` to show percentage of functions that it fails to emit mir for them, which is currently `20%` (which is somehow lying, as most of the supported `80%` are tests). The most offenders are closure (1975 items) and overloaded index (415 items). I will try to add overloaded index before monday to have it in this PR, and tackle the closure in the next episode.
