aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir
Commit message (Collapse)AuthorAgeFilesLines
* Upgrade Chalk againFlorian Diebold2019-09-241-3/+6
|
* Merge #1898bors[bot]2019-09-232-2/+2
|\ | | | | | | | | | | | | | | | | 1898: Drive by lints r=kjeremy a=kjeremy Co-authored-by: kjeremy <[email protected]> Co-authored-by: Jeremy Kolb <[email protected]>
| * Drive by lintskjeremy2019-09-232-2/+2
| |
* | Upgrade ChalkFlorian Diebold2019-09-231-4/+6
|/
* Split off path expression inference code into submoduleFlorian Diebold2019-09-232-172/+199
|
* Handle projection types from ChalkFlorian Diebold2019-09-221-1/+5
|
* Handle associated type shorthand (`T::Item`)Florian Diebold2019-09-226-22/+168
| | | | | | | | | | | | This is only allowed for generic parameters (including `Self` in traits), and special care needs to be taken to not run into cycles while resolving it, because we use the where clauses of the generic parameter to find candidates for the trait containing the associated type, but the where clauses may themselves contain instances of short-hand associated types. In some cases this is even fine, e.g. we might have `T: Trait<U::Item>, U: Iterator`. If there is a cycle, we'll currently panic, which isn't great, but better than overflowing the stack...
* fix module attr pathgfreezy2019-09-203-2/+40
|
* introduce FromSource traitEkaterina Babshukova2019-09-196-111/+247
|
* account for impls generated by macrosAleksey Kladov2019-09-183-28/+74
|
* Merge #1862bors[bot]2019-09-1712-242/+336
|\ | | | | | | | | | | | | | | 1862: Assoc item resolution refactoring (again) r=flodiebold a=flodiebold This is #1849, with the associated type selection code removed for now. Handling cycles there will need some more thought. Co-authored-by: Florian Diebold <[email protected]>
| * 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-177-88/+41
| |
| * Small review improvementsFlorian Diebold2019-09-171-5/+3
| |
| * Add test for `<T>::Item`Florian Diebold2019-09-171-10/+22
| |
| * Refactor some moreFlorian Diebold2019-09-174-57/+100
| | | | | | | | | | | | 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-175-38/+66
| |
| * 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
| |
* | remove confusing codeAleksey Kladov2019-09-171-31/+1
|/ | | | | | I must confess I don't really understand what this code is trying to do, but it definitely misreports changes during fixedpoint iteration, and no tests fail if I remove it, so...
* Merge #1817bors[bot]2019-09-169-144/+227
|\ | | | | | | | | | | | | | | 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-156-49/+63
| |
| * Move store TypeRef of type based path in PathKinduHOOCCOOHu2019-09-153-20/+10
| |
| * Support path starting with a typeuHOOCCOOHu2019-09-157-124/+203
| |
* | Remove `is_unnamed`Dylan MacKenzie2019-09-161-4/+0
| |
* | Gracefully handle `const _` items in `ConstData`Dylan MacKenzie2019-09-162-5/+9
|/
* Add `DotDotPat` to ASTDylan MacKenzie2019-09-151-0/+1
| | | | This is modeled on `PlaceholderPat`.
* Support bare `Trait` without dynFlorian Diebold2019-09-142-12/+11
|
* Upgrade ChalkFlorian Diebold2019-09-143-58/+0
| | | | ... and remove Ty::UnselectedProjection. It'll be handled differently.
* make PerNs non-genericAleksey Kladov2019-09-134-34/+30
|
* Specify desirable namespace when calling resolveAleksey Kladov2019-09-138-408/+458
| | | | That way, we are able to get rid of a number of unreachable statements
* rename AdtDef -> AdtAleksey Kladov2019-09-1211-67/+64
|
* generalize impl_froms to nested enumsAleksey Kladov2019-09-124-58/+26
|
* make various enums "inherit" from AdtDefAleksey Kladov2019-09-1211-98/+132
|
* start cleaning up the resolutionAleksey Kladov2019-09-125-49/+59
| | | | | | | 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.
* add macros with local_inner_macros argumentJasperDeSutter2019-09-122-1/+40
|
* Merge #1818bors[bot]2019-09-125-1/+68
|\ | | | | | | | | | | | | | | 1818: Infer box expression r=matklad a=uHOOCCOOHu Infer `box e` to be `std::boxed::Box<T>` where `e: T` Co-authored-by: uHOOCCOOHu <[email protected]>
| * Infer box expressionuHOOCCOOHu2019-09-115-1/+68
| |
* | fix panic when fetching genericsAleksey Kladov2019-09-121-5/+5
|/ | | | due to macro expansion, the root node is not always a file
* Merge #1796bors[bot]2019-09-113-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1796: Support completion for macros r=matklad a=uHOOCCOOHu This is based on #1795 , and fixes #1727 Also prettify hover text of macros. Some screenshorts below: Completion in item place. <img width="416" alt="Screenshot_20190910_134056" src="https://user-images.githubusercontent.com/14816024/64587159-fa72da00-d3d0-11e9-86bb-c98f169ec08d.png"> After pressing `tab`. <img width="313" alt="Screenshot_20190910_134111" src="https://user-images.githubusercontent.com/14816024/64587160-fa72da00-d3d0-11e9-9464-21e3f6957bd7.png"> Complete macros from `std`. <img width="588" alt="Screenshot_20190910_134147" src="https://user-images.githubusercontent.com/14816024/64587161-fb0b7080-d3d0-11e9-866e-5161f0d1b546.png"> Hover text. <img width="521" alt="Screenshot_20190910_134242" src="https://user-images.githubusercontent.com/14816024/64587162-fb0b7080-d3d0-11e9-8f09-ad17e3f6702a.png"> Co-authored-by: uHOOCCOOHu <[email protected]>
| * Fix typouHOOCCOOHu2019-09-113-3/+3
| |
* | cleanup expansion to item listAleksey Kladov2019-09-102-2/+4
|/
* Merge #1795bors[bot]2019-09-097-239/+393
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-092-12/+3
| |
| * Make macro scope a real name scopeuHOOCCOOHu2019-09-098-236/+399
| | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-30 15:30:13 +0000