| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4445: Correctly fill default type parameters r=flodiebold a=montekki
Fixes #3877
So, basically even if the parameters are omitted from the `impl` block, check the parameters in `trait` if they have a default type, and if they do go from `hir` to `ast::TypeArg`. I've added a helper for that but I am not sure that it's a proper way to go from `hir` to `ast` here.
Co-authored-by: Fedor Sakharov <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
4405: Make some stuff public so that they can be reused by other tools r=pksunkara a=pksunkara
So, my little experiment of building a code analysis tool using rust-analyzer is successful. I am going to proceed to build the tool now. This PR makes the needed things public.
I know there were some things about trying to change stuff regarding loading workspaces, which would make it more easier for other tools to reuse. But, until then, it should be okay using this `load_cargo` fn.
Btw, if I were publish my tool, I would need the `ra` crates to be released. Since @matklad told me that he doesn't want to care about breaking stuff, I would propose the following.
Every monday, during the weekly release, we release a new pre v1 minor version of all the crates. That way, we don't need to care about breaking stuff but still have rust-analyzer on crates.io.
I made https://github.com/pksunkara/cargo-workspaces to help release workspace crates easily.
So, coming week, we start with `0.1.0`, then week after that, we release `0.2.0` and then `0.3.0` etc.. until we decide on `1.0.0` which is probably when the compiler team also starts using the crates. There is no limit to the minor versions (we can even have `0.150.0` or `0.1500.0`), so I don't see anything wrong with this strategy.
Co-authored-by: Pavan Kumar Sunkara <[email protected]>
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4432: Update features.md r=matklad a=bnjjj
Co-authored-by: Coenen Benjamin <[email protected]>
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4452: Use back ticks instead of single quotes around code r=matklad a=tspiteri
Also, use back ticks instead of single quotes in `rustc_unescape_error_to_string` for `EE:UnclosedUnicodeEscape`.
Co-authored-by: Trevor Spiteri <[email protected]>
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4447: Remove VARIATION SELECTOR-16 in Run arrow r=matklad a=lnicola
Closes #4446, cc @Veetaha.
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | | | |
|
|\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4400: Enhanced coloring r=georgewfraser a=georgewfraser
This PR builds on #4397 to enhance the existing syntax coloring.
## Underline mutable variables
The textmate scope `markup.underline` underlines identifiers, which is a nice way to make mutable vars stand out:
<img width="327" alt="Screen Shot 2020-05-09 at 1 18 55 PM" src="https://user-images.githubusercontent.com/1369240/81484179-8bb47d80-91f8-11ea-997d-1dcffbe44aa7.png">
## Italicize static variables
The textmate scope `markup.italic` italicizes identifiers. Italic = static is a common convention in IDEs like IntelliJ:
<img width="288" alt="Screen Shot 2020-05-09 at 1 19 14 PM" src="https://user-images.githubusercontent.com/1369240/81484236-cd452880-91f8-11ea-8478-505ee49bc8b3.png">
Co-authored-by: George Fraser <[email protected]>
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
4444: Update crates r=kjeremy a=kjeremy
Documentation improvements
Co-authored-by: kjeremy <[email protected]>
|
| | |/ /
| |/| |
| | | |
| | | | |
Documentation improvements
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4440: Update packages r=kjeremy a=kjeremy
Co-authored-by: kjeremy <[email protected]>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
latest stable
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
4434: add more specific match postfix for Result and Option r=matklad a=bnjjj
In order to have the same behavior than `if let` and `while let`
Co-authored-by: Benjamin Coenen <[email protected]>
|
| | |_|/
| |/| |
| | | |
| | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
4083: Smol documentation for ast nodes r=matklad a=Veetaha
There is a tremendous amount of TODOs to clarify the topics I am not certain about.
Please @matklad, @edwin0cheng review carefully, I even left some mentions of your names in todos to put your attention where you most probably can give comments.
In order to simplify the review, I separated the codegen (i.e. changes in `ast/generated/nodes.rs`) from `ast_src` changes (they in fact just duplicate one another) into two commits.
Also, I had to hack a little bit to let the docs be generated as doc comments and not as doc attributes because it's easier to read them this way and IIRC we don't support hints for `#[doc = ""]` attributes for now...
Closes #3682
Co-authored-by: veetaha <[email protected]>
|
| | | | |
| | | | |
| | | | |
| | | | | |
cc @matklad (you didn't comment on this one)
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
ConstParam)
(As per matklad)
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
fixme to document it.
This reverts commit 7a49165f5d5c8186edd04f874eae8a98e39d3df6.
MacroStmts ast node is not used by itself, but it pertains
to SyntaxNodeKind MACRO_STMTS that is used by ra_paser, so
even tho the node itself is not used, it is better to keep it
with a FIXME to actually add a doc comment when it becomes useful.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
@matlkad please don't forget to keep it up-to-date!
|
| | | | | |
|
| | | | | |
|
| | | | | |
|