1786: Various minor trait improvements r=matklad a=flodiebold
- lower bounds on trait definition, i.e. super traits
- use super traits for associated types
- use traits from where clauses and their super traits for method resolution
- lower fn-like paths (i.e. `Fn(X, Y) -> Z`)
- pass the environment to Chalk in the correct way to make elaboration work, i.e. inferring things like `T: Clone` from `T: Copy`. The clauses need to be wrapped in `FromEnv` clauses for that to work, which I didn't do before.
- add some tests for closure inference already
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
1780: add option to disable notify r=matklad a=matklad
This should help if notify uses 100% of CPU. Put
```
{
"rust-analyzer.useClientWatching": true,
}
```
into `.vscode/settings.json` (or appropriate config of your editor) to use editor's file watching capabilites instead of notify
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
1771: Further tweak for macro_use on extern crate r=matklad a=uHOOCCOOHu
Some more tweaks to #1743 to behave more like `rustc`
1. Hoist macros from `#[macro_use] extern crate`, so that they can be used before `extern crate`.
2. Implicit `#[macro_use]` for `prelude` if exists
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
1743: Support `#[macro_use]` on `extern crate` r=matklad a=uHOOCCOOHu
Unfortunately, #1688 is still an issue. My guess is wrong :(
Co-authored-by: uHOOCCOOHu <hooccooh1896@gmail.com>
1757: Assoc type bindings r=flodiebold a=flodiebold
This adds support for type bindings (bounds like `where T: Iterator<Item = u32>`).
It doesn't yet work in as many situations as I'd like because of some [Chalk problems](https://github.com/rust-lang/chalk/issues/234). But it works in some situations, and will at least not bitrot this way ;)
(part of the problem is that we use `Normalize` to normalize associated types, but produce `ProjectionEq` goals from where clauses, so Chalk can't normalize using the environment; this would be fixed by using `ProjectionEq` for normalization, which I think is the 'proper' way, but then we'd run into those ambiguity problems everywhere...)
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
