aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir/src/ty
Commit message (Collapse)AuthorAgeFilesLines
...
* account for impls generated by macrosAleksey Kladov2019-09-181-0/+17
|
* Remove assoc type selection code for now to fix crashesFlorian Diebold2019-09-172-25/+10
|
* Add test for `T::Item` cyclesFlorian Diebold2019-09-171-0/+42
|
* Remove TraitItem and ImplItem in favor of AssocItemFlorian Diebold2019-09-173-23/+20
|
* Small review improvementsFlorian Diebold2019-09-171-5/+3
|
* Add test for `<T>::Item`Florian Diebold2019-09-171-10/+22
|
* Refactor some moreFlorian Diebold2019-09-172-49/+85
| | | | | | Type-relative paths (`<T>::foo`) also need to work in type context, for example `<T>::Item` is legal. So rather than returning the type ref from the resolver function, just check it before.
* Refactor associated item resolution moreFlorian Diebold2019-09-172-124/+120
| | | | | When resolving an associated item in value namespace, use the `Ty` lowering code for the segments before the last instead of replicating it.
* Refactor a bit to prepare for resolving trait assoc itemsFlorian Diebold2019-09-171-30/+27
|
* Resolve assoc types on type parametersFlorian Diebold2019-09-172-24/+61
| | | | | | E.g. `fn foo<T: Iterator>() -> T::Item`. It seems that rustc does this only for type parameters and only based on their bounds, so we also only consider traits from bounds.
* Adapt some testsFlorian Diebold2019-09-171-12/+12
|
* Merge #1817bors[bot]2019-09-163-76/+111
|\ | | | | | | | | | | | | | | 1817: Support path starting with a type r=matklad a=uHOOCCOOHu The path syntax `<Ty>::foo` Co-authored-by: uHOOCCOOHu <[email protected]>
| * Define known paths and group namesuHOOCCOOHu2019-09-152-26/+13
| |
| * Support path starting with a typeuHOOCCOOHu2019-09-152-65/+113
| |
* | Gracefully handle `const _` items in `ConstData`Dylan MacKenzie2019-09-161-1/+1
|/
* Support bare `Trait` without dynFlorian Diebold2019-09-142-12/+11
|
* Upgrade ChalkFlorian Diebold2019-09-142-13/+0
| | | | ... and remove Ty::UnselectedProjection. It'll be handled differently.
* Specify desirable namespace when calling resolveAleksey Kladov2019-09-132-188/+176
| | | | That way, we are able to get rid of a number of unreachable statements
* rename AdtDef -> AdtAleksey Kladov2019-09-122-20/+18
|
* generalize impl_froms to nested enumsAleksey Kladov2019-09-121-19/+9
|
* make various enums "inherit" from AdtDefAleksey Kladov2019-09-122-32/+32
|
* start cleaning up the resolutionAleksey Kladov2019-09-122-36/+12
| | | | | | | Nameres related types, like `PerNs<Resolution>`, can represent unreasonable situations, like a local in a type namespace. We should clean this up, by requiring that call-site specifies the kind of resolution it expects.
* Infer box expressionuHOOCCOOHu2019-09-112-0/+57
|
* 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]>
| * StripuHOOCCOOHu2019-09-091-3/+0
| |
| * Make macro scope a real name scopeuHOOCCOOHu2019-09-092-0/+61
| | | | | | | | 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.
* | also make "unknown" case non-enumerableNiko Matsakis2019-09-091-1/+1
| |
* | make all traits non-enumerableNiko Matsakis2019-09-091-9/+1
|/ | | | | As discussed on Zulip, this actually matches the present behavior of rustc.
* Rename `textual_macro` -> `legacy_macro`uHOOCCOOHu2019-09-081-1/+1
| | | | Add comments
* Resolve textual scoped macros inside itemuHOOCCOOHu2019-09-081-0/+35
|
* cleanup hir db importsAleksey Kladov2019-09-084-7/+11
|
* Fix crash for super trait cyclesFlorian Diebold2019-09-071-0/+21
|
* Fix Chalk environmentsFlorian Diebold2019-09-072-3/+4
| | | | | 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-073-12/+32
| | | | | 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-075-23/+26
|
* Add some more testsFlorian Diebold2019-09-071-0/+205
|
* Make type walking infrastructure a bit nicerFlorian Diebold2019-09-036-19/+9
| | | | | If/when we switch to using Chalk's Ty, we'll need to replace this by its `Fold` trait, but I didn't want to import the whole thing just yet.
* 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-034-46/+135
|
* Add test for assoc type bindingsFlorian Diebold2019-09-031-0/+65
|
* Correctly build BodySourceMap for macro-expanded expressionsAleksey Kladov2019-09-031-8/+25
|
* clearer ignoreAleksey Kladov2019-09-031-1/+1
|
* remove needless refsAleksey Kladov2019-09-031-2/+2
|
* use recrod terminology for hir::PatAleksey Kladov2019-09-031-2/+2
|
* fix hir for new block syntaxAleksey Kladov2019-09-021-1/+1
|
* Add an expr_source method analogous to the source methods in the code modelFlorian Diebold2019-09-021-2/+2
| | | | ... and use that instead of exposing the source map.
* :arrow_up: instaAleksey Kladov2019-08-291-1167/+1265
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 14:32:09 +0000