| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1499: processing attribute #[path] of module r=matklad a=andreevlex
support two cases
- simple name file `foo.rs`
- declaration in mod.rs
#1211
Co-authored-by: Alexander Andreev <[email protected]>
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
#1211
|
| |/
|/| |
|
| | |
|
|/
|
|
|
| |
E.g. if we call `foo<T: Into<u32>>(x)`, that adds an obligation that `x:
Into<u32>`, etc.
|
|\
| |
| |
| |
| |
| |
| |
| | |
1495: use correct file for diagnostics r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| | |
closes #1475
|
|\|
| |
| |
| |
| |
| |
| |
| | |
1494: properly restrict diagnostics to a single file r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1491: More clippy r=matklad a=kjeremy
A few more clippy changes.
I'm a little unsure of the second commit. It's the trivially_copy_pass_by_ref lint and there are a number of places in the code we could use it if it makes sense.
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
| |
| |
| |
| | |
https://rust-lang.github.io/rust-clippy/master/index.html#trivially_copy_pass_by_ref
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1485: rand 0.7.0 r=matklad a=kjeremy
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1486: allow rustfmt to reorder imports r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| |
| |
| | |
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
1478: [WIP] Added resolve submodules with raw name r=matklad a=andreevlex
#1211
Co-authored-by: Alexander Andreev <[email protected]>
|
| | |
|
| |
| |
| |
| | |
Added test for check module resolution with raw name
|
| |
| |
| |
| | |
#1211
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is actually allowed by the `rustc` parser but most attributes will
fail later due to attributes on expressions being experimental.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Array members are allow to have attributes such as `#[cfg]`.
This is a bit tricky as we don't know if the first expression is an
initializer or a member until we encounter a `;`. This reuses a trick
from `stmt` where we remember if we saw an attribute and then raise an
error if the first expression ends up being an initializer.
This isn't perfect as the error isn't correctly located on the attribute
or initializer; it ends up immediately after the `;`.
|
|\
| |
| |
| |
| |
| |
| |
| | |
1456: Deduplicate method candidates r=matklad a=flodiebold
With trait method completion + autoderef, we were getting a lot of duplicates, which was really annoying...
Co-authored-by: Florian Diebold <[email protected]>
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
1440: fixed #1384 r=matklad a=zbelial
This PR fixed #1384 .
Co-authored-by: zjy <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
My workflow in Visual Studio Code + Rust Analyzer has become:
1. Make a change to Rust source code using all the analysis magic
2. Save the file to trigger `cargo watch`. I have format on save enabled
for all file types so this also runs `rustfmt`
3. Fix any diagnostics that `cargo watch` finds
Unfortunately if the Rust source has any syntax errors the act of saving
will pop up a scary "command has failed" message and will switch to the
"Output" tab to show the `rustfmt` error and exit code.
I did a quick survey of what other Language Servers do in this case.
Both the JSON and TypeScript servers will swallow the error and return
success. This is consistent with how I remember my workflow in those
languages. The syntax error will show up as a diagnostic so it should
be clear why the file isn't formatting.
I checked the `rustfmt` source code and while it does distinguish "parse
errors" from "operational errors" internally they both result in exit
status of 1. However, more catastrophic errors (missing `rustfmt`,
SIGSEGV, etc) will return 127+ error codes which we can distinguish from
a normal failure.
This changes our handler to log an info message and feign success if
`rustfmt` exits with status 1.
Another option I considered was only swallowing the error if the
formatting request came from format-on-save. However, the Language
Server Protocol doesn't seem to distinguish those cases.
|
| | |
|