11579: minor: Future-proof against a next edition by using `>=` and not `==` r=lnicola a=ChayimFriedman2
So that we won't have a strange bug when edition 2024 will land.
rustc [also does that](427cf81206/compiler/rustc_builtin_macros/src/edition_panic.rs (L84)).
Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com>
11573: refactorings and FIXME fixes in text edit r=lnicola a=HansAuger
This is mainly me learning some rust, and only anecdotally about addressing some `fixme`s. Feel free to nope :)
There is a follow up PR in the pipeline which tackles the other two `fixme`s but it's a bit more invasive. So I wanted to get this out of the way
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
11560: internal: Update `url` to make `webrender` build when computing metrics r=jonas-schievink a=lnicola
Closes#9997
This doesn't seem to affect the metrics, but I'm not sure since somehow I get different values than what shows up on CI.
With `stable`:
```
exprs: 94151, ??ty: 96 (0%), ?ty: 25 (0%), !ty: 6
```
CI shows 16.
Also, https://github.com/rust-analyzer/rust-analyzer/pull/7250 strikes again, I can never tell what those numbers are.
r? `@jonas-schievink`
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11562: fix: Don't emit unresolvedReference highlight tags in unlinked files r=Veykril a=Veykril
Emitting these overwrites any syntax based highlighting that is being done in the file, causing a lot of noise if the user gave them a specific color.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11554: fix: fix type mismatches with `unreachable!` macro in Rust 1.59 r=jonas-schievink a=jonas-schievink
should fix https://github.com/rust-analyzer/rust-analyzer/issues/11551
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11552: fix: properly display `$crate` in hovers r=jonas-schievink a=jonas-schievink
We used to print it as `{extern_crate}`, this PR resolves it to the crate's name, or falls back to `$crate` if the crate has no name.
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11550: Refactor autoderef/method resolution r=flodiebold a=flodiebold
- don't return the receiver type from method resolution; instead just
return the autorefs/autoderefs that happened and repeat them. This
ensures all the effects like trait obligations and whatever we learned
about type variables from derefing them are actually applied. Also, it
allows us to get rid of `decanonicalize_ty`, which was just wrong in
principle.
- Autoderef itself now directly works with an inference table. Sadly
this has the effect of making it harder to use as an iterator, often
requiring manual `while let` loops. (rustc works around this by using
inner mutability in the inference context, so that things like unifying
types don't require a unique reference.)
- We now record the adjustments (autoref/deref) for method receivers
and index expressions, which we didn't before.
- Removed the redundant crate parameter from method resolution, since
the trait_env contains the crate as well.
- in the HIR API, the methods now take a scope to determine the trait env.
`Type` carries a trait env, but I think that's probably a bad decision
because it's easy to create it with the wrong env, e.g. by using
`Adt::ty`. This mostly didn't matter so far because
`iterate_method_candidates` took a crate parameter and ignored
`self.krate`, but the trait env would still have been wrong in those
cases, which I think would give some wrong results in some edge cases.
Fixes#10058.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
