aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * trigger garbage collection *after* requests, not beforeAleksey Kladov2019-05-291-2/+5
| |
| * more perf loggingAleksey Kladov2019-05-291-3/+8
|/
* Merge #1339bors[bot]2019-05-2947-297/+307
|\ | | | | | | | | | | | | | | 1339: flip Into to From r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * silnce profiling in testsAleksey Kladov2019-05-291-1/+2
| |
| * flip Into to FromAleksey Kladov2019-05-291-6/+6
| |
| * show error offsets in testsAleksey Kladov2019-05-2946-290/+299
|/
* Merge #1337bors[bot]2019-05-2989-687/+705
|\ | | | | | | | | | | | | | | 1337: Move syntax errors our of syntax tree r=matklad a=matklad I am not really sure if it's a good idea, but `SyntaxError` do not really belong to a `SyntaxTree`. So let's just store them on the side? Co-authored-by: Aleksey Kladov <[email protected]>
| * fix todoAleksey Kladov2019-05-281-3/+0
| |
| * fix typos in mbe testsAleksey Kladov2019-05-2829-91/+92
| |
| * fix syntax errors in testsAleksey Kladov2019-05-287-121/+137
| |
| * move mbe to the new APIAleksey Kladov2019-05-283-73/+73
| |
| * remove old parsing methodsAleksey Kladov2019-05-287-62/+54
| |
| * update test dataAleksey Kladov2019-05-2845-289/+290
| |
| * update testsAleksey Kladov2019-05-284-47/+36
| |
| * drop error from SOurceFile constructorAleksey Kladov2019-05-282-5/+5
| |
| * return errors from tree builderAleksey Kladov2019-05-282-5/+6
| |
| * drop errors from SyntaxNodeAleksey Kladov2019-05-282-9/+6
| |
| * add ParseAleksey Kladov2019-05-281-2/+26
| |
* | Merge #1338bors[bot]2019-05-292-3/+20
|\ \ | |/ |/| | | | | | | | | | | 1338: Highlight names correctly r=matklad a=lnicola Part of #1294. Co-authored-by: Laurențiu Nicola <[email protected]>
| * Highlight type names correctlyLaurențiu Nicola2019-05-292-3/+20
|/
* Merge #1336bors[bot]2019-05-284-156/+149
|\ | | | | | | | | | | | | | | 1336: Refactor SubtreeSource r=matklad a=edwin0cheng This PR simplify `SubtreeSource` by removing `SubtreeWalk` and `Querier` and only walk through the top level `TokenTree` when collecting token from source, by comparing two cursors directly. Co-authored-by: Edwin Cheng <[email protected]>
| * Use cfg(test) instead of allow(unused)Edwin Cheng2019-05-281-1/+1
| |
| * Minor use moduleEdwin Cheng2019-05-271-3/+2
| |
| * Simpliy how collecting token from srcEdwin Cheng2019-05-273-72/+39
| |
| * Add more helper func in CursorEdwin Cheng2019-05-271-0/+15
| |
| * Remove Queier and SubtreeWalkEdwin Cheng2019-05-272-92/+104
| |
* | Merge #1334bors[bot]2019-05-274-1/+87
|\ \ | |/ |/| | | | | | | | | | | 1334: check for cancellation during macro expansion r=matklad a=matklad closes #1331 Co-authored-by: Aleksey Kladov <[email protected]>
| * check cancellation when expanding macrosAleksey Kladov2019-05-272-3/+3
| |
| * specifically profile cancellationAleksey Kladov2019-05-271-0/+4
| |
| * enable profiling in testsAleksey Kladov2019-05-272-1/+83
| |
* | Merge #1319bors[bot]2019-05-2715-46/+242
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1319: Rainbow highlighting spike 🌈 r=killercup a=killercup Very simple approach: For each identifier, set the hash of the range where it's defined as its 'id' and use it in the VSCode extension to generate unique colors. Thus, the generated colors are per-file. They are also quite fragile, and I'm not entirely sure why. Looks like we need to make sure the same ranges aren't overwritten by a later request? Co-authored-by: Pascal Hertleif <[email protected]>
| * | Make rainbows optionalPascal Hertleif2019-05-275-6/+29
| | |
| * | rename stray id fieldPascal Hertleif2019-05-272-2/+2
| | |
| * | make it build againPascal Hertleif2019-05-273-14/+28
| | |
| * | Disable broken struct field rainbowingPascal Hertleif2019-05-273-23/+7
| | |
| * | More clever highlighting, incl draft for structsPascal Hertleif2019-05-2710-414/+159
| | |
| * | Hash based on binding name and shadow counterPascal Hertleif2019-05-274-21/+81
| | |
| * | Semantic highlighting spikePascal Hertleif2019-05-279-39/+409
|/ / | | | | | | | | | | | | | | | | | | Very simple approach: For each identifier, set the hash of the range where it's defined as its 'id' and use it in the VSCode extension to generate unique colors. Thus, the generated colors are per-file. They are also quite fragile, and I'm not entirely sure why. Looks like we need to make sure the same ranges aren't overwritten by a later request?
* | Merge #1333bors[bot]2019-05-271-0/+5
|\| | | | | | | | | | | | | | | 1333: add profile calls to real-time requests r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * add profile calls to real-time requestsAleksey Kladov2019-05-271-0/+5
|/
* Merge #1277bors[bot]2019-05-278-96/+273
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1277: Improve macro item resolution r=matklad a=edwin0cheng ~This PR add a new namespace `Macros` in `per_ns.rs` to allow following use case:~ This PR improve macro item resolution to allow following use case: ```rust //- /main.rs use foo::bar; bar!(); //- /lib.rs (crate foo) #[macro_export] macro_rules! bar{ () => { struct Foo { field: u32 } } ``` Co-authored-by: Edwin Cheng <[email protected]>
| * FormattingEdwin Cheng2019-05-271-1/+0
| |
| * Add Test for new item resolutionEdwin Cheng2019-05-262-2/+55
| |
| * Use ItemOrMacro in item resolutionEdwin Cheng2019-05-264-94/+214
| |
| * Add Either depEdwin Cheng2019-05-262-0/+2
| |
| * Put back unexpaned_macros after resolveEdwin Cheng2019-05-261-0/+3
| |
* | Merge #1328bors[bot]2019-05-278-126/+166
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1328: Change TokenSource to iteration based r=matklad a=edwin0cheng This PR change the `TokenSource` trait from random access to be an iteration based trait: ```rust /// `TokenSource` abstracts the source of the tokens parser operates one. /// /// Hopefully this will allow us to treat text and token trees in the same way! pub trait TokenSource { fn current(&self) -> Token; /// Lookahead n token fn lookahead_nth(&self, n: usize) -> Token; /// bump cursor to next token fn bump(&mut self); /// Is the current token a specified keyword? fn is_keyword(&self, kw: &str) -> bool; } /// `TokenCursor` abstracts the cursor of `TokenSource` operates one. #[derive(Debug, Copy, Clone, Eq, PartialEq)] pub struct Token { /// What is the current token? pub kind: SyntaxKind, /// Is the current token joined to the next one (`> >` vs `>>`). pub is_jointed_to_next: bool, } ``` Note that the refactoring based on this new trait will be separated to incoming PRs Co-authored-by: Edwin Cheng <[email protected]>
| * | Remove duplicated codeEdwin Cheng2019-05-251-4/+0
| | |
| * | Simplify token_tree_to_xxxEdwin Cheng2019-05-251-47/+20
| | |
| * | Change TokenSource to iteration basedEdwin Cheng2019-05-258-100/+171
| | |