| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
We regressed $i * 2 where $i = 1 + 1, need to fix that!
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1803: introduce bump as a better-checked alternative to bump_any r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
| |
| |
| |
| | |
Fix some details about module scoping
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
As discussed on Zulip, this actually matches the present behavior of
rustc.
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
1799: :arrow_up: chalk r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1789: Debug r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1794: tiny simplification r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | |
|
| | |
| | |
| | |
| | | |
Add comments
|
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 2c494eb803c88ef5d23607c3b156fce60c2b8076.
See: https://github.com/rust-analyzer/rust-analyzer/pull/1784#issuecomment-529119924
|
| | | |
|
| | | |
|
| |/ |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1792: Update README.md r=matklad a=fannheyward
fixes base on #1755 reviews
Co-authored-by: Heyward Fann <[email protected]>
|
| | |
|
|/
|
| |
fixes base on #1755 reviews
|
|\
| |
| |
| |
| |
| |
| |
| | |
1790: Minor typo fix for ra_assists code doc r=matklad a=nelsonjchen
Co-authored-by: Nelson Chen <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1788: cleanup hir db imports r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1787: don't cycle when processing macros from prelude in prelude r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
| |
| |
| |
| |
| | |
The clauses need to be wrapped in `FromEnv` clauses for elaboration (i.e.
things like inferring `T: Clone` from `T: Copy`) to work correctly.
|
| |
| |
| |
| |
| | |
E.g. if we have `T: some::Trait`, we can call methods from that trait without it
needing to be in scope.
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1783: simplify r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| | |
1781: don't deadlock on shutdown r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
Specifically, when we tear down IO threads, we should take care to
dispose connection.
closes #1775
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1755: feat(docs): add coc-rust-analyzer r=JeanMertz a=fannheyward
Co-authored-by: Heyward Fann <[email protected]>
|
| | |
|