| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We need to add the `T: Index<Arg>` obligation to be resolved later as well,
otherwise we can't make inferences about `Arg` later based on the `Index` impls.
This still doesn't fix indexing with integer variables though; there's a further
problem with Chalk floundering because of the variable, I think.
|
| |
|
|
|
|
|
|
| |
'Unknown' int/float types actually never exist as such, they get replaced by
type variables immediately. So the whole `Uncertain<IntTy>` thing was
unnecessary and just led to a bunch of match branches that were never hit.
|
|
|
|
|
| |
They should not be applied in expression or pattern contexts, unless there are
other explicitly given type args.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is working, but I'm not that happy with how the lowering works. We might
need an additional representation between `TypeRef` and `Ty` where names are
resolved and `impl Trait` bounds are separated out, but things like inference
variables don't exist and `impl Trait` is always represented the same
way.
Also note that this doesn't implement correct handling of RPIT *inside* the
function (which involves turning the `impl Trait`s into variables and creating
obligations for them). That intermediate representation might help there as
well.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
I.e.
- `Self(x)` or `Self` in tuple/unit struct impls
- `Self::Variant(x)` or `Self::Variant` in enum impls
- the same in patterns
Fixes #4454.
|
| |
|
| |
|
|
|
|
|
| |
Still no break-with-value or labels, but at least we know that `loop { break; }`
doesn't diverge.
|
|
|
|
|
|
|
|
| |
Divergence here means that for some reason, the end of a block will not be
reached. We tried to model this just using the never type, but that doesn't work
fully (e.g. in `let x = { loop {}; "foo" };` x should still have type `&str`);
so this introduces a `diverges` flag that the type checker keeps track of, like
rustc does.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
It's not entirely clear what subnode ranges should mean in the
presence of macros, so let's leave them out for now. We are not using
them heavily anyway.
|
| |
|
|
|
|
|
|
|
| |
It improves compile time in `--release` mode quite a bit, it doesn't
really slow things down and, conceptually, it seems closer to what we
want the physical architecture to look like (we don't want to
monomorphise EVERYTHING in a single leaf crate).
|
| |
|
| |
|
|
|
|
| |
Fixes #3306.
|
| |
|
|
|
|
|
|
|
|
|
| |
E.g. for `&{ some_string() }` in a context where a `&str` is expected, we
reported a mismatch inside the block. The problem is that we're passing an
expectation of `str` down, but the expectation is more of a hint in this case.
There's a long comment in rustc about this, which I just copied.
Also, fix reported location for type mismatches in macros.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
don't belong
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the same change as we did with `crate_def_map` and it does seem
that we mostly spend time in salsa, without recomputing much on
rust-analyzer side.
Example output:
```
233ms - handle_inlay_hints
163ms - get_inlay_hints
163ms - SourceAnalyzer::new
67ms - def_with_body_from_child_node
67ms - analyze_container
67ms - analyze_container
67ms - Module::from_definition
67ms - Module::from_file
67ms - crate_def_map
0ms - parse_macro_query (6 calls)
0ms - raw_items_query (1 calls)
66ms - ???
0ms - crate_def_map (1 calls)
0ms - crate_def_map (1 calls)
96ms - infer
2ms - trait_solve_query (2 calls)
94ms - ???
0ms - body_with_source_map_query (1 calls)
0ms - crate_def_map (1 calls)
[...]
```
Signed-off-by: Michal Terepeta <[email protected]>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #2547.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
When calling a function, argument-position impl Trait is transparent; same for
return-position impl Trait when inside the function. So in these cases, we need
to represent that type not by `Ty::Opaque`, but by a type variable that can be
unified with whatever flows into there.
|