aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* | | | | Merge #3748bors[bot]2020-04-106-56/+304
|\ \ \ \ \ | |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3748: Implement Chalk's debug methods using TLS r=matklad a=flodiebold Chalk now panics if we don't implement these methods and run with CHALK_DEBUG, so I thought I'd try to implement them 'properly'. Sadly, it seems impossible to do without transmuting lifetimes somewhere. The problem is that we need a `&dyn HirDatabase` to get names etc., which we can't just put into TLS. I thought I could just use `scoped-tls`, but that doesn't support references to unsized types. So I put the `&dyn` into another struct and put the reference to *that* into the TLS, but I have to transmute the lifetime to 'static for that to work. I think this is sound, but I still don't really want to do it this way... Having names in the Chalk debug output is very nice, but maybe IDs will have to suffice :disappointed: Co-authored-by: Florian Diebold <[email protected]>
| * | | | Implement Chalk's debug methods using TLSFlorian Diebold2020-04-106-56/+304
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Chalk now panics if we don't implement these methods and run with CHALK_DEBUG, so I thought I'd try to implement them 'properly'. Sadly, it seems impossible to do without transmuting lifetimes somewhere. The problem is that we need a `&dyn HirDatabase` to get names etc., which we can't just put into TLS. I thought I could just use `scoped-tls`, but that doesn't support references to unsized types. So I put the `&dyn` into another struct and put the reference to *that* into the TLS, but I have to transmute the lifetime to 'static for that to work.
* | | | Merge #3923bors[bot]2020-04-0916-1060/+151
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3923: Cleanup keyword accessors r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Simpler acessors for keywordsAleksey Kladov2020-04-0914-1025/+128
| | | | |
| * | | | use uniform accessorAleksey Kladov2020-04-092-5/+1
| | | | |
| * | | | use stdxAleksey Kladov2020-04-091-3/+3
| | | | |
| * | | | Drop needless traitAleksey Kladov2020-04-094-28/+20
| | | | |
* | | | | Merge #3922bors[bot]2020-04-095-60/+49
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3922: Remove code duplication r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Remove code duplicationAleksey Kladov2020-04-095-60/+49
|/ / / /
* | | | Merge #3918bors[bot]2020-04-095-45/+142
|\ \ \ \ | |_|/ / |/| | / | | |/ | |/| | | | | | | | | | | | | 3918: Add support for feature attributes in struct literal r=matklad a=bnjjj As promised here is the next PR to solve 2 different scenarios with feature flag on struct literal. close #3870 Co-authored-by: Benjamin Coenen <[email protected]>
| * | feat: add support for feature attributes in struct literalBenjamin Coenen2020-04-0928-8158/+7651
| |\ \ | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | feat: add support for feature attributes in struct literalBenjamin Coenen2020-04-096-45/+143
| | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | | | Merge #3901bors[bot]2020-04-091-6/+46
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3901: Add more heuristics for hiding obvious param hints r=matklad a=IceSentry This will now hide `value`, `pat`, `rhs` and `other`. These words were selected from the std because they are used in commonly used functions with only a single param and are obvious by their use. It will also hide the hint if the passed param **starts** or end with the param_name. Maybe we could also split on '_' and check if one of the string is the param_name. I think it would be good to also hide `bytes` if the type is `[u8; n]` but I'm not sure how to get the param type signature. Closes #3900 Co-authored-by: IceSentry <[email protected]>
| * | | use .expr() to remove refIceSentry2020-04-091-5/+10
| | | |
| * | | clean up param hint checkingIceSentry2020-04-091-18/+18
| | | |
| * | | better `&mut ` and `&` matchingIceSentry2020-04-091-6/+6
| | | |
| * | | ignore `&mut ` and `&` when checking paramsIceSentry2020-04-091-3/+13
| | | |
| * | | remove TODOIceSentry2020-04-081-1/+0
| | | |
| * | | Add more heuristics for hiding obvious param hintsIceSentry2020-04-081-4/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This will now hide "value", "pat", "rhs" and "other" These words were selected from the std because they are used in common functions with only a single param and are obvious by their use. I think it would be good to also hide "bytes" if the type is `[u8; n]` but I'm not sure how to get the param type signature It will also hide the hint if the passed param starts or end with the param_name
* | | | Merge #3919bors[bot]2020-04-0923-341/+247
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3919: Refactor tokena accessors r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Be consistent about token accesorsAleksey Kladov2020-04-0914-114/+36
| | | | |
| * | | | Add _token suffix to token accessorsAleksey Kladov2020-04-0912-213/+210
| | | | | | | | | | | | | | | | | | | | | | | | | I think this makes is more clear which things are : AstNode and which are : AstToken
| * | | | SimplifyAleksey Kladov2020-04-091-26/+13
| | | | |
* | | | | Merge #3917bors[bot]2020-04-093-2/+136
|\ \ \ \ \ | |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3917: Improve tt::Subtree debug print r=matklad a=edwin0cheng Co-authored-by: Edwin Cheng <[email protected]>
| * | | | Improve tt::Subtree debug printEdwin Cheng2020-04-093-2/+136
| | | | |
* | | | | Merge #3915bors[bot]2020-04-098-9746/+7154
|\ \ \ \ \ | |/ / / / |/| / / / | |/ / / | | | | | | | | | | | | | | | | | | | | 3915: Prettify generated code r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Put displays at the endAleksey Kladov2020-04-092-702/+706
| | | |
| * | | More compactAleksey Kladov2020-04-093-1438/+240
| | | |
| * | | More compact generated codeAleksey Kladov2020-04-094-2184/+731
| | | |
| * | | Move the rest of the tokens to generated/tokensAleksey Kladov2020-04-094-738/+751
| | | |
| * | | Move generated tokens to a separate fileAleksey Kladov2020-04-094-3092/+3121
| | | |
| * | | Start ast/generated/tokensAleksey Kladov2020-04-094-3/+10
| | | |
| * | | Prepare for spliting generated into tokens and nodesAleksey Kladov2020-04-095-9627/+9630
| | | |
| * | | Reduce visibilityAleksey Kladov2020-04-091-2/+2
| | | |
| * | | Cleanup importAleksey Kladov2020-04-091-2/+5
|/ / /
* | | Merge #3913bors[bot]2020-04-091-3/+13
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3913: Remove allocations from LCA r=matklad a=matklad I haven't actually profiled this, but not allocating a hash map (or anything, really) seems like a good idea bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Remove allocations from LCAAleksey Kladov2020-04-091-3/+13
|/ / / | | | | | | | | | | | | I haven't actually profiled this, but not allocating a hash map (or anything, really) seems like a good idea
* | | Merge #3912bors[bot]2020-04-093-1/+63
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3912: Parse correctly fn f<T>() where T: Fn() -> u8 + Send {} r=matklad a=matklad We used to parse it as T: Fn() -> (u8 + Send), which is different from the rustc behavior of T: (Fn() -> u8) + Send bors r+ 🤖 Co-authored-by: Luca Barbieri <[email protected]>
| * | | Parse correctly fn f<T>() where T: Fn() -> u8 + Send {}Luca Barbieri2020-04-093-1/+63
| | | | | | | | | | | | | | | | | | | | We used to parse it as T: Fn() -> (u8 + Send), which is different from the rustc behavior of T: (Fn() -> u8) + Send
* | | | Merge #3911bors[bot]2020-04-0920-398/+2412
|\| | | | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | 3911: Genrate token accessors r=matklad a=matklad bors r+ 🤖 Co-authored-by: Luca Barbieri <[email protected]> Co-authored-by: Aleksey Kladov <[email protected]>
| * | Scale back to only two traitsAleksey Kladov2020-04-098-227/+2019
| | |
| * | Provide more complete AST accessors to support usage in rustcLuca Barbieri2020-04-0918-214/+436
|/ /
* | Merge #3909bors[bot]2020-04-094-74/+3176
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 3909: Generate tokense r=matklad a=matklad bors r+ 🤖 Co-authored-by: Luca Barbieri <[email protected]> Co-authored-by: Aleksey Kladov <[email protected]>
| * | Scale back the traitsAleksey Kladov2020-04-093-245/+3061
| | |
| * | Add AstElement trait, generate tokens, support tokens in enumsLuca Barbieri2020-04-083-94/+380
| | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* | | Merge #3880bors[bot]2020-04-094-7/+58
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3880: Add support for attributes for struct fields r=matklad a=bnjjj Hello I try to solve this example: ```rust struct MyStruct { my_val: usize, #[cfg(feature = "foo")] bar: bool, } impl MyStruct { #[cfg(feature = "foo")] pub(crate) fn new(my_val: usize, bar: bool) -> Self { Self { my_val, bar } } #[cfg(not(feature = "foo"))] pub(crate) fn new(my_val: usize, _bar: bool) -> Self { Self { my_val } } } ``` Here is a draft PR to try to solve this issue. In fact for now when i have this kind of example, rust-analyzer tells me that my second Self {} miss the bar field. Which is a bug. I have some difficulties to add this features. Here in my draft I share my work about adding attributes support on struct field data. But I'm stuck when I have to fetch attributes from parent expressions. I don't really know how to do that. For the first iteration I just want to solve my issue without solving on all different expressions. And then after I will try to implement that on different kind of expression. I think I have to fetch my FunctionId and then I will be able to find attributes with myFunction.attrs() But I don't know if it's the right way. @matklad (or anyone else) if you can help me it would be great :D Co-authored-by: Benjamin Coenen <[email protected]>
| * \ \ feat: add attributes support on struct fields and method #3870Benjamin Coenen2020-04-0928-336/+522
| |\ \ \ | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | | feat: add attributes support on struct fields and method #3870Benjamin Coenen2020-04-084-43/+30
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | | Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-04-07322-160/+1823
| |\ \ \ \
| * | | | | feat: add attributes support on struct fields #3870Benjamin Coenen2020-04-074-7/+71
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>