aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir/src/ty/tests.rs
Commit message (Collapse)AuthorAgeFilesLines
* Support bare `Trait` without dynFlorian Diebold2019-09-141-10/+10
|
* Infer box expressionuHOOCCOOHu2019-09-111-0/+31
|
* Fix typouHOOCCOOHu2019-09-111-1/+1
|
* Merge #1795bors[bot]2019-09-091-0/+58
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1795: Make macro scope a real name scope and fix some details r=matklad a=uHOOCCOOHu This PR make macro's module scope a real name scope in `PerNs`, instead of handling `Either<PerNs, MacroDef>` everywhere. In `rustc`, the macro scope behave exactly the same as type and value scope. It is valid that macros, types and values having exact the same name, and a `use` statement will import all of them. This happened to module `alloc::vec` and macro `alloc::vec!`. So `Either` is not suitable here. There is a trap that not only does `#[macro_use]` import all `#[macro_export] macro_rules`, but also imports all macros `use`d in the crate root. In other words, it just _imports all macros in the module scope of crate root_. (Visibility of `use` doesn't matter.) And it also happened to `libstd` which has `use alloc_crate::vec;` in crate root to re-export `alloc::vec`, which it both a module and a macro. The current implementation of `#[macro_use] extern crate` doesn't work here, so that is why only macros directly from `libstd` like `dbg!` work, while `vec!` from `liballoc` doesn't. This PR fixes this. Another point is that, after some tests, I figure out that _`macro_rules` does NOT define macro in current module scope at all_. It defines itself in legacy textual scope. And if `#[macro_export]` is given, it also is defined ONLY in module scope of crate root. (Then being `macro_use`d, as mentioned above) (Well, the nightly [Declarative Macro 2.0](https://github.com/rust-lang/rust/issues/39412) simply always define in current module scope only, just like normal items do. But it is not yet supported by us) After this PR, in my test, all non-builtin macros are resolved now. (Hover text for documentation is available) So it fixes #1688 . Since compiler builtin macros are marked as `#[rustc_doc_only_macro]` instead of `#[macro_export]`, we can simply tweak the condition to let it resolved, but it may cause expansion error. Some critical notes are also given in doc-comments. <img width="447" alt="Screenshot_20190909_223859" src="https://user-images.githubusercontent.com/14816024/64540366-ac1ef600-d352-11e9-804f-566ba7559206.png"> Co-authored-by: uHOOCCOOHu <[email protected]>
| * Make macro scope a real name scopeuHOOCCOOHu2019-09-091-0/+58
| | | | | | | | Fix some details about module scoping
* | modify testsNiko Matsakis2019-09-091-6/+6
|/ | | | | | | | Some method resolution tests now yield `{unknown}` where they did not before. Other tests now succeed, likely because this is helping the solver steer its efforts.
* Rename `textual_macro` -> `legacy_macro`uHOOCCOOHu2019-09-081-1/+1
| | | | Add comments
* Resolve textual scoped macros inside itemuHOOCCOOHu2019-09-081-0/+35
|
* Fix crash for super trait cyclesFlorian Diebold2019-09-071-0/+21
|
* Fix Chalk environmentsFlorian Diebold2019-09-071-2/+2
| | | | | The clauses need to be wrapped in `FromEnv` clauses for elaboration (i.e. things like inferring `T: Clone` from `T: Copy`) to work correctly.
* Use traits from where clauses for method resolutionFlorian Diebold2019-09-071-11/+10
| | | | | E.g. if we have `T: some::Trait`, we can call methods from that trait without it needing to be in scope.
* Lower `Fn(X, Y) -> Z` pathsFlorian Diebold2019-09-071-8/+8
|
* Lower bounds on trait definition, and resolve assoc types from super traitsFlorian Diebold2019-09-071-5/+5
|
* Add some more testsFlorian Diebold2019-09-071-0/+205
|
* Properly format `impl Trait<Type = Foo>` typesFlorian Diebold2019-09-031-4/+4
| | | | | | It's a bit complicated because we basically have to 'undo' the desugaring, and the result is very dependent on the specifics of the desugaring and will probably produce weird results otherwise.
* Add support for associated type bindings (`where Trait<Type = X>`)Florian Diebold2019-09-031-18/+44
|
* Add test for assoc type bindingsFlorian Diebold2019-09-031-0/+65
|
* Correctly build BodySourceMap for macro-expanded expressionsAleksey Kladov2019-09-031-8/+25
|
* fix hir for new block syntaxAleksey Kladov2019-09-021-1/+1
|
* :arrow_up: instaAleksey Kladov2019-08-291-1167/+1265
|
* Remove redundant testsKirill Bulatov2019-08-261-63/+5
|
* Make infer_block not unify; add back calculate_least_upper_boundFlorian Diebold2019-08-261-10/+12
|
* An attempt to add the coercion logic for NeverKirill Bulatov2019-08-261-0/+58
|
* Properly coerce never typesKirill Bulatov2019-08-261-7/+0
|
* Remove extra inference testKirill Bulatov2019-08-261-24/+0
|
* Fix never in if expressionsKirill Bulatov2019-08-261-1/+41
|
* Add test marksKirill Bulatov2019-08-261-1/+6
|
* Fix match type inference for Never match armsKirill Bulatov2019-08-261-1/+1
|
* TestsKirill Bulatov2019-08-261-0/+104
|
* Improve/fix type bound loweringFlorian Diebold2019-08-221-0/+33
|
* Handle impl/dyn Trait in method resolutionFlorian Diebold2019-08-221-30/+52
| | | | | | | | | | | | | When we have one of these, the `Trait` doesn't need to be in scope to call its methods. So we need to consider this when looking for method candidates. (Actually I think the same is true when we have a bound `T: some::Trait`, but we don't handle that yet). At the same time, since Chalk doesn't handle these types yet, add a small hack to skip Chalk in method resolution and just consider `impl Trait: Trait` always true. This is enough to e.g. get completions for `impl Trait`, but since we don't do any unification we won't infer the return type of e.g. `impl Into<i64>::into()`.
* Add `impl Trait` and `dyn Trait` typesFlorian Diebold2019-08-221-0/+120
| | | | | | | - refactor bounds handling in the AST a bit - add HIR for bounds - add `Ty::Dyn` and `Ty::Opaque` variants and lower `dyn Trait` / `impl Trait` syntax to them
* Don't add `?` bounds as real boundsAleksey Kladov2019-08-221-0/+29
| | | | closes #1709
* implement initial type inference for index expressionsAleksey Kladov2019-08-171-0/+14
|
* Handle placeholder assoc types when Chalk produces themFlorian Diebold2019-08-121-0/+49
|
* Normalize assoc types in more placesFlorian Diebold2019-08-121-6/+6
|
* Lower fully qualified associated type pathsFlorian Diebold2019-08-121-7/+7
| | | | I.e. `<T as Trait>::Foo`.
* Add another test for assoc type resolutionFlorian Diebold2019-08-121-6/+46
|
* implement while let desugaringAleksey Kladov2019-08-071-0/+20
|
* Move assist test, add literal type inference testPhil Ellison2019-07-291-11/+15
|
* streamline APIAleksey Kladov2019-07-211-4/+2
|
* Merge #1562bors[bot]2019-07-201-0/+35
|\ | | | | | | | | | | | | | | | | 1562: Continue support for .await r=matklad a=unrealhoang - add await expr to ast and HIR Expr - infer type for `.await` Co-authored-by: Unreal Hoang <[email protected]>
| * infer type for awaitUnreal Hoang2019-07-201-0/+35
| | | | | | | | by projecting inner_ty to Future::Output alias
* | rename range -> text_rangeAleksey Kladov2019-07-201-1/+1
|/
* migrate ra_hir to the new rowanAleksey Kladov2019-07-191-5/+5
|
* Merge #1515bors[bot]2019-07-091-0/+79
|\ | | | | | | | | | | | | | | | | | | | | | | 1515: Trait environment r=matklad a=flodiebold This adds the environment, i.e. the set of `where` clauses in scope, when solving trait goals. That means that e.g. in ```rust fn foo<T: SomeTrait>(t: T) {} ``` , we are able to complete methods of `SomeTrait` on the `t`. This affects the trait APIs quite a bit (since every method that needs to be able to solve for some trait needs to get this environment somehow), so I thought I'd do it rather sooner than later ;) Co-authored-by: Florian Diebold <[email protected]>
| * Use environment for associated type normalization as wellFlorian Diebold2019-07-081-0/+19
| |
| * Start handling environment in trait resolutionFlorian Diebold2019-07-081-0/+60
| | | | | | | | | | I.e. if we are inside a function with some where clauses, we assume these where clauses hold.
* | beautify testsUnreal Hoang2019-07-091-20/+36
| |
* | projection over std::ops::Try::Ok to infer try/?Unreal Hoang2019-07-081-0/+37
|/
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-09 12:01:44 +0000