| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1848: Parse `..` as a full pattern r=matklad a=ecstatic-morse
Resolves #1479.
This PR implements [RFC 2707](https://github.com/rust-lang/rfcs/pull/2707) in the parser. It introduces a new `DotDotPat` AST node modeled on `PlaceholderPat` and changes the parsing of tuple and slice patterns to conform to the RFC.
Notably, this PR does *not* change the resulting AST when `..` appears in a struct pattern (e.g. `Struct { a, b: c, .. }`). I *think* this is the behavior mandated by RFC 2707, but someone should confirm this.
Co-authored-by: Dylan MacKenzie <[email protected]>
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
This is modeled on `PlaceholderPat`.
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
| |
... and remove Ty::UnselectedProjection. It'll be handled differently.
|
| |
|
| |
|
|
|
|
| |
That way, we are able to get rid of a number of unreachable statements
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1821: Macro completion tweaks r=matklad a=SomeoneToIgnore
Thanks @uHOOCCOOHu for making the macro completion happen :)
I've added a few tweaks to the current completion to make it a bit more convenient:
* Automatically add braces and put the editor cursor inside of them:
<img width="159" alt="image" src="https://user-images.githubusercontent.com/2690773/64737220-022b9f00-d4f5-11e9-8088-76d4678921ab.png">
Currently I have to add the braces manually which is a bit cumbersome.
One further improvement can be to detect if macro accepts no parameters and place the cursor differently for this case.
* Add an exclamation mark to the macro completion label
This helps to distinguish macros from other completion items and also allows to show only macros in completion if you type `!`:
<img width="722" alt="image" src="https://user-images.githubusercontent.com/2690773/64736987-8b8ea180-d4f4-11e9-8355-2ce4f83b7aa8.png">
<img width="732" alt="image" src="https://user-images.githubusercontent.com/2690773/64737214-ffc94500-d4f4-11e9-946e-1ba2db1c7fb1.png">
Additionally, automatic formatting hooks had adjusted two `help.rs` files, I've added them as a last commit to the PR even though they are not really related.
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
due to macro expansion, the root node is not always a file
|
|/ /
| |
| |
| |
| |
| |
| | |
Parser has the invariant that `{}` are balanced.
Previous code tried (unsucesfuly) maintain the same invariant for
`$()` as well, but it was done in a rather ad-hoc manner: it's not at
all obvious that it is possible to maintain both invariants!
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1806: refactor(args): Switch to pico-args r=matklad a=Geobert
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/1768
Co-authored-by: Geobert Quach <[email protected]>
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
| |
| |
| | |
cc https://github.com/rust-lang/rust/issues/64242
|
| |
| |
| |
| | |
We regressed $i * 2 where $i = 1 + 1, need to fix that!
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|