| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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?
|
| |\|
| |
| |
| |
| |
| |
| |
| | |
1333: add profile calls to real-time requests r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
1330: Add Vim and NeoVim setup section r=oblitum a=oblitum
Co-authored-by: Francisco Lopes <[email protected]>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1327: Colorize Rust code as HTML r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1318: cargo update r=matklad a=kjeremy
Nothing interesting
Co-authored-by: kjeremy <[email protected]>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1321: Rustc r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
1317: profile highlighting r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
1316: Simplify code model r=matklad a=matklad
* remove references from types which are now id-based
* remove api/impl separation, as the impl is a tiny fraction of API anyway
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\| |
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1290: Add Union to code_model r=matklad a=matklad
@flodiebold I am conflicted about two possible implementation approaches:
* we can add a separate `struct Union` to code model
* we can add `fn is_union(&self)` to existing `Struct`
This PR goes with the former approach, because it seems like Unions are sufficiently different in semantics to warrant a separate types. Which is in contrast to Syntax Tree, where both structs and unions share the same node kind, because their syntax is the same.
What would be the right thing to do here?
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1312: Introduce TokenBuffer r=matklad a=edwin0cheng
As discussed in Zulip, this PR Introduce `TokenBuffer` , a safe version of `syn` crate `TokenBuffer` which support cursor based traversal of `tt::TokenTree`. This is the basis of incoming refactoring of `TokenSource` iterator based API.
This PR do the following things:
* Add TokenBuffer in `ra_tt` crate.
* Try to use this new API to refactor the `SubtreeSource` to prove it usage.
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1315: Use Xenial image and fix find call r=matklad a=lnicola
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1305: Try to resolve name refs during highlighting r=matklad a=lnicola
Preview:
This is probably not the cleanest implementation, but it's not clear to me what parts of `reference_definition` we don't want to run at this point. Also, is the `SourceAnalyzer` cheap enough to construct for each `NameRef`? Not like there's any alternative at this point, though.
Co-authored-by: Laurențiu Nicola <[email protected]>
|
