| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
closes #3927
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
3905: add ellipsis field to hir pat record r=matklad a=JoshMcguigan
This PR corrects a `fixme`, adding an `ellipsis` field to the hir `Pat::Record` type. It will also be unlock some useful follow on work for #3894.
Additionally it adds a diagnostic for missing fields in record patterns.
~~Marking as a draft because I don't have any tests, and a small amount of manual testing on my branch from #3894 suggests it might *not* be working. Any thoughts on how I can best test this, or else pointers on where I might be going wrong?~~
Co-authored-by: Josh Mcguigan <[email protected]>
|
| | |_|/ /
| |/| | | |
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | /
| | |/
| |/|
| | |
| | |
| | |
| | | |
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]>
|
| |\ \
| | | |
| | | |
| | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
3919: Refactor tokena accessors r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I think this makes is more clear which things are : AstNode and which
are : AstToken
|
| | |_|/
| |/| | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
3917: Improve tt::Subtree debug print r=matklad a=edwin0cheng
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|/ / / |
|
| | |
| | |
| | |
| | |
| | | |
I haven't actually profiled this, but not allocating a hash map (or
anything, really) seems like a good idea
|
| | |
| | |
| | |
| | |
| | | |
We used to parse it as T: Fn() -> (u8 + Send), which is different from
the rustc behavior of T: (Fn() -> u8) + Send
|
| | | |
|
| |/
|/| |
|