11936: Ignore `Drop` and `Destruct` bounds for now r=flodiebold a=flodiebold
- `T: ~const Drop` has a special meaning in Rust 1.61 that we don't implement. (So ideally, we'd only ignore `~const Drop`, but this should be fine for now.)
- `Destruct` impls are built-in in 1.62 (current nightlies), so until the builtin impls are supported by Chalk, we ignore them as well. Since `Destruct` is implemented for everything in non-const contexts IIUC, this should also work fine.
Fixes#11932.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
- `T: ~const Drop` has a special meaning in Rust 1.61 that we don't implement.
(So ideally, we'd only ignore `~const Drop`, but this should be fine
for now.)
- `Destruct` impls are built-in in 1.62 (current nightlies as of 08-04-2022), so until
the builtin impls are supported by Chalk, we ignore them as well.
Since `Destruct` is implemented for everything in non-const contexts
IIUC, this should also work fine.
Fixes#11932.
11920: Consider types of const generics r=flodiebold a=HKalbasi
fix#11913
We should emit type_mismatch in const generics, probably after #7434. Currently they will lead to a misleading, time of use type error (like the added test).
Co-authored-by: hkalbasi <hamidrezakalbasi@protonmail.com>
11930: internal: move function unsafety determination out of the ItemTree r=jonas-schievink a=jonas-schievink
Resolves some FIXMEs.
I've also renamed some FnFlags to be more explicit about what they represent (presence of keywords, not necessarily presence of semantics)
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11925: internal: Add and use `HirFormatter::write_{str,char}` r=Veykril a=lnicola
Saves slightly over 3 KB of `text`, but comparing the total with that from two weeks ago in #11776, this is a losing battle (we're 951 KB larger).
```
text data bss dec hex filename
24693512 1542704 4424 26240640 1906680 rust-analyzer-baseline
24690216 1542112 4424 26236752 1905750 rust-analyzer-pr
```
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11927: internal: Use bitflags for `FnFlags` r=jonas-schievink a=jonas-schievink
Previously we didn't do this because it didn't pull its weight, but now we actually do some bitops
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11924: internal: remove `FnFlags::IS_IN_EXTERN_BLOCK` r=jonas-schievink a=jonas-schievink
This flag was determined purely based on the AST, which cannot work reliably since macros are allowed in `extern` blocks (in which case the function would not have an extern block parent in the AST).
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11915: fix: Attempt to resolve paths in const arguments heuristically in IDE layer r=Veykril a=Veykril
While we don't support const args in type inference yet, we can at least
make use of the fallback path resolution to resolve paths in const args
in the IDE layer to enable some features for them.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
While we don't support const args in type inference yet, we can at least
make use of the fallback path resolution to resolve paths in const args
in the IDE layer to enable some features for them.
11905: internal: Remove hir_expand macro recursion check r=jonas-schievink a=jonas-schievink
This check is insufficient to ensure finite macro nesting, and so all callers already have their own recursion limit, which makes this check redundant.
...at least I hope it's redundant. Would be great if someone could double-check this.
Originally, this check was added in https://github.com/rust-analyzer/rust-analyzer/pull/3671
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11891: Better error message on Flycheck Error message (from: unactionable error message if we are using `clippy` as the checker) r=Veykril a=flipbit03
I have commented on this [S-unactionable issue](https://github.com/rust-analyzer/rust-analyzer/issues/6589) that the Flycheck error message should maybe provide a hint about what tool it actually runs. Searching on some places on the Internet I've found multiple people, including myself, losing copious amounts of time on the same issue. So I've decided to make this very small PR :-)
From an user experience standpoint, the current error message is unhelpful to the end user, because the end user does not know exactly what it needs to check/fix (outdated, broken, or missing `cargo clippy`). In my own case, `cargo clippy` was actually missing altogether (developing off `rust:1.59.0-bullseye` official Docker image).
Thanks in advance!
Co-authored-by: Cadu <cadu.coelho@gmail.com>
11904: internal: Wrap macros in expr position in `MacroExpr` node r=jonas-schievink a=jonas-schievink
This lets us distinguish them from macros in item position just by looking at the syntax tree.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/11854
bors r+
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
11899: fix: Skip match check on patterns of unexpected TyKind::FnDef r=Veykril a=iDawer
Match checking does not expect patterns of `TyKind::FnDef` type.
It seems that in _rustc_ match checking is ruled out due to such type errors at the typecheck stage.
Spotted in #11319
Co-authored-by: iDawer <ilnur.iskhakov.oss@outlook.com>
11896: fix: Show the path to be created in the unresolved-module fix label r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11894: complete pattern args based on type name r=Veykril a=cameron1024
Addresses #11892
Changes function argument completion to cover a case like this:
```rust
struct Foo { bar: i32 }
fn qux(Foo { bar }: Foo) {
println!("{bar}");
}
```
When completing the function call for `qux`, instead of expanding to `qux(_)`, it will now expand to `qux(foo)` (based on the snake-cased version of the name of the ADT)
Non ADTs are unaffected
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: cameron1024 <cameron.studdstreet@gmail.com>
11865: Fix: Select correct insert position for disabled group import r=jonasbb a=jonasbb
The logic for importing with and without `group_imports` differed
significantly when no previous group existed. This lead to the problem
of using the wrong position when importing inside a module (#11585) or
when inner attributes are involved.
The existing code for grouped imports is better and takes these things
into account.
This PR changes the flow to use the pre-existing code for adding a new
import group even for the non-grouped import settings.
Some coverage markers are updated and the `group` is removed, since they
are now invoked in both cases (grouping and no grouping).
Tests are updated and two tests (empty module and inner attribute) are
added.
Fixes#11585
Co-authored-by: Jonas Bushart <jonas@bushart.org>
