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 <edwin0cheng@gmail.com>
2497: Remove MacroFileKind r=matklad a=edwin0cheng
This PR move `to_macro_file_kind` to `hir_expand::db` and use it to get the `FragmentKind` directly, such that we can remove `MacroFileKind`.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2492: Refactor generic parameteres lowering r=flodiebold a=matklad
indices and parent params seem to be concerns, specific to `hir_ty`, so move them there.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
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 <flodiebold@gmail.com>
2484: DynMap r=matklad a=matklad
Implement a `DynMap` a semi-dynamic, semi-static map, which helps to thread heterogeneously typed info in a uniform way. Totally inspired by df3bee3038/compiler/frontend/src/org/jetbrains/kotlin/resolve/BindingContext.java.
@flodiebold wdyt? Seems like a potentially useful pattern for various source-map-like things.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
SourceAnalyzer didn't work properly within expression macro expansions because
it didn't find the enclosing function. Fix this by going up the expansion chain
to find ancestors. This makes the test work, but apparently in real usage it's
still not working.
2487: Don't unify within a reference r=matklad a=flodiebold
If we are expecting a `&Foo` and get a `&something`, when checking the `something`, we are *expecting* a `Foo`, but we shouldn't try to unify whatever we get with that expectation, because it could actually be a `&Foo`, and `&&Foo` coerces to `&Foo`. So this fixes quite a few false type mismatches.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
If we are expecting a `&Foo` and get a `&something`, when checking the
`something`, we are *expecting* a `Foo`, but we shouldn't try to unify whatever
we get with that expectation, because it could actually be a `&Foo`, and `&&Foo`
coerces to `&Foo`. So this fixes quite a few false type mismatches.
