| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This merely upgrades our protocol support. It does not add any of the new features.
|
|
|
|
|
| |
Tuple in type annotation expands correctly;
Expansion will prefer the following delimiter when possible.
New regression tests added to verify the consistency between tuple expansion in type annotation and tuple expansion in rvalue.
|
| |
|
| |
|
| |
|
| |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
2500: Fix format_args expansion & go to definition r=matklad a=flodiebold
The expansion of format_args wasn't yet correct enough to type-check. Also make macros in statement position expand to expressions for now, since it's not handled correctly in HIR lowering yet. This finally fixes go to definition within print macros, I think :slightly_smiling_face:
2505: Remove more dead code r=matklad a=matklad
2506: Remove one more Ty r=matklad a=matklad
Co-authored-by: Florian Diebold <[email protected]>
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |/ |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Expanding to statements isn't handled properly yet and breaks things.
|
| | | |
|
| |/ |
|
| | | |
| \ | |
| \ | |
| \ | |
|\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
2501: Fix coercion from &Foo to an inference variable in a reference r=matklad a=flodiebold
We didn't try to unify within the reference, but we should.
2502: Delay legacy macro expansion r=matklad a=edwin0cheng
This PR make the following changes:
* Delay legacy macro expansion such that we concentrated all item collecting macro expansion in one place.
* Add `MacroDirective` to replace 3-tuples
* After this refactoring, no macro is expanded recursively, hence we can remove the `MacroStackMonitor` and we handle the expansion limit by the fix-point loop count.
2503: Code: check whether the LSP binary is in PATH r=matklad a=lnicola
I'm not really sure about the TS changes. I just made a couple of functions async and it seems to work.
Co-authored-by: Florian Diebold <[email protected]>
Co-authored-by: Edwin Cheng <[email protected]>
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |/ |
|
|/ /
| |
| |
| | |
We didn't try to unify within the reference, but we should.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2499: Remove ty from code_model r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\| |
| |/
|/|
| |
| |
| |
| |
| | |
2498: Drop some unused methods r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
2466: Handle partial resolve cases r=matklad a=edwin0cheng
Another try to fix #2443 :
We resolve all imports every time in `DefCollector::collect` loop even it is resolved previously.
This is because other unresolved imports and macros will bring in another `PerNs`, so we can only assume that it has been partially resolved.
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
We don't have LifetimeParam yet, but they are planned!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Skip slow tests by default
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This makes `hir_def::GenericParams` flatter. The logic for
re-numbering the params is moved to hir instead.
|
| | | |
|
|/ /
| |
| |
| | |
Probably fixes #2464.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2489: Implement `format_args` r=flodiebold a=flodiebold
This fixes a huge amount of type mismatches (because every format call was a type mismatch so far); I also hoped to get go to def working within `format!` etc., and the test says it should, but in practice it still doesn't seem to...
Also remove the `len` parameter from `Name::new_inline_ascii`, which I'm assuming was only there because of `const fn` limitations?
cc @edwin0cheng
Co-authored-by: Florian Diebold <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|