| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| | |
1076: Const body inference r=flodiebold a=Lapz
This is the second part of #887. I've added type inference on const bodies and introduced the DefWithBody containing Function, Const and Static. I want to add tests but im unsure on how I would go about testing that completions work.
Co-authored-by: Lenard Pratt <[email protected]>
|
| |
| |
| |
| |
| |
| | |
and added inference the inference test
reduce code duplication
|
|/ |
|
|
|
|
| |
... to make the infer_trait_method_simple test have the correct result.
|
| |
|
| |
|
|
|
|
| |
Fixes #1030.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
982: Implement BindingMode for pattern matching. r=flodiebold a=mjkillough
Implement `BindingMode` for pattern matching, so that types can be
correctly inferred using match ergonomics. The binding mode defaults to
`Move` (referred to as 'BindingMode::BindByValue` in rustc), and is
updated by automatic dereferencing of the value being matched.
Fixes #888.
- [Binding modes in The Reference](https://doc.rust-lang.org/reference/patterns.html#binding-modes)
- [`rustc` implementation](https://github.com/rust-lang/rust/blob/e17c48e2f21eefd59748e364234efc7037a3ec96/src/librustc_typeck/check/_match.rs#L77) (and [definition of `BindingMode`](https://github.com/rust-lang/rust/blob/e957ed9d10ec589bdd523b88b4b44c41b1ecf763/src/librustc/ty/binding.rs))
- [Match Ergonomics RFC](https://github.com/rust-lang/rfcs/blob/master/text/2005-match-ergonomics.md#binding-mode-rules)
Co-authored-by: Michael Killough <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Implement `BindingMode` for pattern matching, so that types can be
correctly inferred using match ergonomics. The binding mode defaults to
`Move` (referred to as 'BindingMode::BindByValue` in rustc), and is
updated by automatic dereferencing of the value being matched.
|
|/
|
|
|
| |
This allows removing the names from Adt and FnDef (and more later), as a first
step towards aligning more with chalk's Ty :)
|
| |
|
|
|
|
| |
None of them works correctly yet, of course.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I think it'll be better to make the path resolution the number of unresolved
segments, not the first unresolved index; then this error could simply not have
happened. But I'll do that separately.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
866: Implement basic support for Associated Methods r=flodiebold a=vipentti
This is my attempt at learning to understand how the type inference works by adding basic support for associated methods. Currently it does not resolve associated types or constants.
The basic idea is that `Resolver::resolve_path` returns a new `PathResult` type, which has two variants, `FullyResolved` and `PartiallyResolved`, fully resolved matches the previous behavior, where as `PartiallyResolved` contains the `PerNs<Resolution` in addition to a `segment_index` which contains the index of the segment which we failed to resolve. This index can then be used to continue inference in `infer_path_expr` using the `Type` we managed to resolve.
This changes some of the previous apis, so looking for feedback and suggestions.
This should enable fixing #832
Co-authored-by: Ville Penttinen <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This is done in `infer_path_expr`. When `Resolver::resolve_path` returns
`PartiallyResolved`, we use the returned `Resolution` together with the given
`segment_index` to check if we can find something matching the segment at
segment_index in the impls for that particular type.
|
|/
|
|
|
|
| |
Also make them display a tiny bit nicer.
Fixes #860.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Wrap them in a LiteralPat node so they can be distinguished from literal
expressions.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
701: Minor type inference tweaks r=flodiebold a=marcusklaas
Pass down expectation for reference expressions and type the guard in match expressions.
I wasn't able to add a test for the former addition because the type variable previously introduced would always resolve to the right type in the things I tried!
Co-authored-by: Marcus Klaas de Vries <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
This might be the cause of #587.
|
|
|
|
| |
then is not always a block...
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #651.
|
| |
|
| |
|