aboutsummaryrefslogtreecommitdiff
path: root/xtask
Commit message (Collapse)AuthorAgeFilesLines
* Validate uses of self and superJohn Renner2020-05-011-1/+1
|
* Fix a bunch of false-positives in join-linesAleksey Kladov2020-04-301-1/+1
|
* Allow to set env vars and pipe stdin via not_bashAleksey Kladov2020-04-302-92/+79
|
* Merge #4219bors[bot]2020-04-301-33/+67
|\ | | | | | | | | | | | | | | | | | | 4219: Avoid `rustup` invocation for non-rustup rust installation r=matklad a=oxalica Fix #4218 and #3243. Co-authored-by: oxalica <[email protected]>
| * Avoid `rustup` invocation for non-rustup rust installationoxalica2020-04-301-33/+67
| |
* | Merge #4178bors[bot]2020-04-301-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4178: Validate the location of `crate` in paths r=matklad a=djrenren **This solution does not fully handle `use` statements. See below** This pull requests implements simple validation of usages of the `crate` keyword in `Path`s. Specifically it validates that: - If a `PathSegment` is starts with the `crate` keyword, it is also the first segment of the `Path` - All other usages of `crate` in `Path`s are considered errors. This aligns with `rustc`'s rules. Unlike rustc this implementation does not issue a special error message in the case of `::crate` but it does catch the error. Furthermore, this change does not cover all error cases. Specifically the following is not caught: ```rust use foo::{crate} ``` This is because this check is context sensitive. From an AST perspective, `crate` is the root of the `Path`. Only by inspecting the full `UseItem` do we see that it is not in fact the root. This problem becomes worse because `UseTree`s are allowed to be arbitrarily nested: ```rust use {crate, {{crate, foo::{crate}}} ``` So this is a hard problem to solve without essentially a breadth-first search. In a traditional compiler, I'd say this error is most easily found during the AST -> HIR conversion pass but within rust-analyzer I'm not sure where it belongs. Under the implementation in this PR, such errors are ignored so we're *more correct* just not *entirely correct*. Co-authored-by: John Renner <[email protected]>
| * Validate the location of `crate` in pathsJohn Renner2020-04-291-1/+1
| |
* | Use x86_64-unknown-linux-gnu for releasesLaurențiu Nicola2020-04-281-5/+3
|/
* Bump required rust to 1.43kjeremy2020-04-231-1/+1
|
* Group generated ast boilerplate apart from the interesting partveetaha2020-04-181-120/+130
|
* Refucktor codegenveetaha2020-04-181-6/+6
|
* tests: add more info about what failed in tidy testsBenjamin Coenen2020-04-171-3/+3
| | | | Signed-off-by: Benjamin Coenen <[email protected]>
* Change add_function assist to use todo!()Timo Freiberg2020-04-131-0/+1
|
* Align grammar for record patterns and literalsAleksey Kladov2020-04-111-1/+1
| | | | | | The grammar now looks like this [name_ref :] pat
* Change missing impl assist to use todo!() instead of unimplemented()Chris Hopman2020-04-101-1/+10
| | | | | | | | | | | | todo!() "Indicates unfinished code" (https://doc.rust-lang.org/std/macro.todo.html) Rust documentation provides further clarification: > The difference between unimplemented! and todo! is that while todo! > conveys an intent of implementing the functionality later and the > message is "not yet implemented", unimplemented! makes no such claims. todo!() seems more appropriate for assists that insert missing impls.
* SimplifyAleksey Kladov2020-04-101-1/+1
|
* Rename some tokensAleksey Kladov2020-04-102-13/+13
|
* Better readabilityAleksey Kladov2020-04-101-2/+3
|
* Remove dead codeAleksey Kladov2020-04-101-11/+4
|
* Generate only minimal set of ineresting tokensAleksey Kladov2020-04-103-0/+38
|
* Scale token generation backAleksey Kladov2020-04-103-238/+59
|
* Convert more tokensAleksey Kladov2020-04-102-49/+19
|
* Other delimitersAleksey Kladov2020-04-102-18/+22
|
* Curley tokensAleksey Kladov2020-04-101-17/+15
|
* Start replacing tokensAleksey Kladov2020-04-102-1/+5
|
* Semicolon tokenAleksey Kladov2020-04-102-13/+19
|
* More readable ast_src for keywordsAleksey Kladov2020-04-102-104/+133
|
* SimplifyAleksey Kladov2020-04-101-4/+4
|
* Simpler acessors for keywordsAleksey Kladov2020-04-092-10/+27
|
* Drop needless traitAleksey Kladov2020-04-091-4/+4
|
* Be consistent about token accesorsAleksey Kladov2020-04-091-2/+3
|
* Add _token suffix to token accessorsAleksey Kladov2020-04-091-0/+1
| | | | | I think this makes is more clear which things are : AstNode and which are : AstToken
* Put displays at the endAleksey Kladov2020-04-091-12/+16
|
* More compactAleksey Kladov2020-04-091-10/+2
|
* More compact generated codeAleksey Kladov2020-04-091-0/+1
|
* Move the rest of the tokens to generated/tokensAleksey Kladov2020-04-092-85/+98
|
* Move generated tokens to a separate fileAleksey Kladov2020-04-091-37/+61
|
* Start ast/generated/tokensAleksey Kladov2020-04-092-3/+8
|
* Prepare for spliting generated into tokens and nodesAleksey Kladov2020-04-092-2/+2
|
* Reduce visibilityAleksey Kladov2020-04-091-2/+2
|
* Cleanup importAleksey Kladov2020-04-091-2/+5
|
* Scale back to only two traitsAleksey Kladov2020-04-092-37/+58
|
* Provide more complete AST accessors to support usage in rustcLuca Barbieri2020-04-091-91/+292
|
* Scale back the traitsAleksey Kladov2020-04-091-140/+28
|
* Add AstElement trait, generate tokens, support tokens in enumsLuca Barbieri2020-04-081-29/+269
| | | | | | | | | - Adds a new AstElement trait that is implemented by all generated node, token and enum structs - Overhauls the code generators to code-generate all tokens, and also enhances enums to support including tokens, node, and nested enums
* fmtAleksey Kladov2020-04-081-1/+0
|
* Don't strip nightly releasesAleksey Kladov2020-04-084-22/+19
|
* When making a release, just promote the latest nightlyAleksey Kladov2020-04-071-2/+2
|
* Macro patterns are not confused with expressions.Aleksey Kladov2020-04-031-0/+3
| | | | | | | | | | | We treat macro calls as expressions (there's appropriate Into impl), which causes problem if there's expresison and non-expression macro in the same node (like in the match arm). We fix this problem by nesting macor patterns into another node (the same way we nest path into PathExpr or PathPat). Ideally, we probably should add a similar nesting for macro expressions, but that needs some careful thinking about macros in blocks: `{ am_i_expression!() }`.
* Get rid of ItemOrMacroAleksey Kladov2020-03-261-0/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 18:43:14 +0000