aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge #1803bors[bot]2019-09-0916-132/+138
|\ | | | | | | | | | | | | | | 1803: introduce bump as a better-checked alternative to bump_any r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * introduce bump as a better-checked alternative to bump_anyAleksey Kladov2019-09-092-2/+8
| |
| * rename bump -> bump_anyAleksey Kladov2019-09-0916-132/+132
|/
* 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
* | Merge #1800bors[bot]2019-09-092-16/+8
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 1800: make all traits non-enumerable r=flodiebold a=nikomatsakis As discussed on Zulip, this actually matches the present behavior of rustc. r? @flodiebold Co-authored-by: Niko Matsakis <[email protected]>
| * | 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.
* | | Merge #1799bors[bot]2019-09-091-75/+5
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 1799: :arrow_up: chalk r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | :arrow_up: chalkAleksey Kladov2019-09-091-75/+5
|/ /
* | Merge #1789bors[bot]2019-09-0912-19/+186
|\ \ | | | | | | | | | | | | | | | | | | | | | 1789: Debug r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | document moduleAleksey Kladov2019-09-092-8/+27
| | |
| * | introduce hir debugging infraAleksey Kladov2019-09-0911-18/+166
| |/ | | | | | | | | | | | | | | | | | | | | | | This is to make debugging rust-analyzer easier. The idea is that `dbg!(krate.debug(db))` will print the actual, fuzzy crate name, instead of precise ID. Debug printing infra is a separate thing, to make sure that the actual hir doesn't have access to global information. Do not use `.debug` for `log::` logging: debugging executes queries, and might introduce unneded dependencies to the crate graph
* | Merge #1794bors[bot]2019-09-094-5/+8
|\ \ | |/ |/| | | | | | | | | | | 1794: tiny simplification r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * tiny simplificationAleksey Kladov2019-09-094-5/+8
|/
* Merge #1793bors[bot]2019-09-093-2/+44
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1793: Fix outer doc-comments of `macro_rules` r=matklad a=uHOOCCOOHu Document comments of `macro_rules!` is currently parsed outside the `MACRO_CALL` node, which makes `DocCommentsOwner::doc_comments()` always empty. For the input: ```rust /// Some docs macro_rules! foo { () => {}; } ``` Current parsing tree is: ``` SOURCE_FILE COMMENT // <- This should be children of MACRO_CALL WHITESPACE MACRO_CALL PATH <...omitted...> ``` It should be: ``` SOURCE_FILE MACRO_CALL COMMENT WHITESPACE PATH <...omitted...> ``` Co-authored-by: uHOOCCOOHu <[email protected]>
| * Fix outer doc-comments of `macro_rules`uHOOCCOOHu2019-09-093-2/+44
| |
* | Merge #1784bors[bot]2019-09-095-42/+229
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1784: Support textual scoped macros r=matklad a=uHOOCCOOHu Refactor the old simulation with `global_macro_scope`. Now it is quite accurate to resolve textual scoped macros. - Expand textual scoped macros in item and non-item place. - Support `#[macro_use]` on `mod`. - Textual scoped macros are collected into `nameres::ModuleScope`, so I think it makes #1727 easier to fix. - It is implemented in a simple way to `clone()` current scoped macro ids into sub-modules. Though only indices are cloned, it will still increase some resolving time. Well, I've not bench-marked yet. In my test with vscode extension, it can now successfully expand `dbg!` from `std` without `std::` prefix. "Goto definition" also works. Screenshot here: <img width="281" alt="Screenshot_20190907_043442" src="https://user-images.githubusercontent.com/14816024/64458794-ddb47900-d128-11e9-95e3-1c8569978825.png"> Co-authored-by: uHOOCCOOHu <[email protected]>
| * | Fix testuHOOCCOOHu2019-09-081-3/+0
| | |
| * | Rename `textual_macro` -> `legacy_macro`uHOOCCOOHu2019-09-084-29/+39
| | | | | | | | | | | | Add comments
| * | Revert "Replace with immutable map to avoid heavy cloning"uHOOCCOOHu2019-09-084-36/+2
| | | | | | | | | | | | | | | | | | This reverts commit 2c494eb803c88ef5d23607c3b156fce60c2b8076. See: https://github.com/rust-analyzer/rust-analyzer/pull/1784#issuecomment-529119924
| * | Replace with immutable map to avoid heavy cloninguHOOCCOOHu2019-09-084-2/+36
| | |
| * | Resolve textual scoped macros inside itemuHOOCCOOHu2019-09-084-9/+65
| | |
| * | Support textual scoped macrosuHOOCCOOHu2019-09-084-34/+158
| |/
* | Merge #1792bors[bot]2019-09-091-2/+3
|\ \ | |/ |/| | | | | | | | | | | 1792: Update README.md r=matklad a=fannheyward fixes base on #1755 reviews Co-authored-by: Heyward Fann <[email protected]>
| * Update README.mdHeyward Fann2019-09-091-1/+1
| |
| * Update README.mdHeyward Fann2019-09-091-2/+3
|/ | | fixes base on #1755 reviews
* Merge #1790bors[bot]2019-09-081-1/+1
|\ | | | | | | | | | | | | | | 1790: Minor typo fix for ra_assists code doc r=matklad a=nelsonjchen Co-authored-by: Nelson Chen <[email protected]>
| * Minor typo fix for ra_assists code docNelson Chen2019-09-081-1/+1
|/
* Merge #1788bors[bot]2019-09-0824-43/+65
|\ | | | | | | | | | | | | | | 1788: cleanup hir db imports r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * cleanup hir db importsAleksey Kladov2019-09-0824-43/+65
|/
* Merge #1787bors[bot]2019-09-072-2/+33
|\ | | | | | | | | | | | | | | 1787: don't cycle when processing macros from prelude in prelude r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * don't cycle when processing macros from prelude in preludeAleksey Kladov2019-09-072-2/+33
|/
* Merge #1786bors[bot]2019-09-0714-40/+394
|\ | | | | | | | | | | | | | | | | | | | | | | | | 1786: Various minor trait improvements r=matklad a=flodiebold - lower bounds on trait definition, i.e. super traits - use super traits for associated types - use traits from where clauses and their super traits for method resolution - lower fn-like paths (i.e. `Fn(X, Y) -> Z`) - pass the environment to Chalk in the correct way to make elaboration work, i.e. inferring things like `T: Clone` from `T: Copy`. The clauses need to be wrapped in `FromEnv` clauses for that to work, which I didn't do before. - add some tests for closure inference already Co-authored-by: Florian Diebold <[email protected]>
| * Fix crash for super trait cyclesFlorian Diebold2019-09-074-20/+39
| |
| * 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-074-21/+44
| | | | | | | | | | 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-074-13/+55
| |
| * Lower bounds on trait definition, and resolve assoc types from super traitsFlorian Diebold2019-09-0711-38/+102
| |
| * Add some more testsFlorian Diebold2019-09-071-0/+205
|/
* Merge #1783bors[bot]2019-09-061-38/+40
|\ | | | | | | | | | | | | | | 1783: simplify r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * simplifyAleksey Kladov2019-09-061-38/+40
| |
* | Merge #1781bors[bot]2019-09-063-4/+4
|\| | | | | | | | | | | | | | | 1781: don't deadlock on shutdown r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * don't deadlock on shutdownAleksey Kladov2019-09-063-4/+4
| | | | | | | | | | | | | | Specifically, when we tear down IO threads, we should take care to dispose connection. closes #1775
* | Merge #1755bors[bot]2019-09-061-27/+4
|\ \ | |/ |/| | | | | | | | | | | 1755: feat(docs): add coc-rust-analyzer r=JeanMertz a=fannheyward Co-authored-by: Heyward Fann <[email protected]>
| * feat(docs): add coc-rust-analyzerHeyward Fann2019-09-031-27/+4
| |
* | Merge #1780bors[bot]2019-09-0613-71/+151
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1780: add option to disable notify r=matklad a=matklad This should help if notify uses 100% of CPU. Put ``` { "rust-analyzer.useClientWatching": true, } ``` into `.vscode/settings.json` (or appropriate config of your editor) to use editor's file watching capabilites instead of notify Co-authored-by: Aleksey Kladov <[email protected]>
| * | add option to disable notifyAleksey Kladov2019-09-0613-71/+151
|/ /