| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |/
|/|
| |
| |
| | |
I think this makes is more clear which things are : AstNode and which
are : AstToken
|
|/ |
|
|\
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|\| |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Fixes #3865. Basically I forgot to shift 'back' when we got `dyn Trait`s back
from Chalk, so after going through Chalk a few times, the panic happened.
|
| | |
|
|/
|
|
| |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
3744: Upgrade Chalk r=matklad a=flodiebold
Co-authored-by: Florian Diebold <[email protected]>
Co-authored-by: Florian Diebold <[email protected]>
|
| |
| |
| |
| |
| |
| |
| | |
The big change here is counting binders, not
variables (https://github.com/rust-lang/chalk/pull/360). We have to adapt to the
same scheme for our `Ty::Bound`. It's mostly fine though, even makes some things
more clear.
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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!() }`.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
3679: Some miniscule refactorings r=matklad a=Veetaha
Co-authored-by: veetaha <[email protected]>
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
It improves compile time in `--release` mode quite a bit, it doesn't
really slow things down and, conceptually, it seems closer to what we
want the physical architecture to look like (we don't want to
monomorphise EVERYTHING in a single leaf crate).
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3549: Implement env! macro r=matklad a=edwin0cheng
This PR implements `env!` macro by adding following things:
1. Added `additional_outdirs` settings in vscode. (naming to be bikeshed)
2. Added `ExternSourceId` which is a wrapping for SourceRootId but only used in extern sources. It is because `OUT_DIR` is not belonged to any crate and we have to access it behind an `AstDatabase`.
3. This PR does not implement the `OUT_DIR` parsing from `cargo check`. I don't have general design about this, @kiljacken could we reuse some cargo watch code for that ?
~~Block on [#3536]~~
PS: After this PR , we (kind of) completed the `include!(concat!(env!('OUT_DIR'), "foo.rs")` macro call combo. [Exodia Obliterate!](https://www.youtube.com/watch?v=RfqNH3FoGi0)
Co-authored-by: Edwin Cheng <[email protected]>
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
To test whether the receiver type matches for the impl, we unify the given self
type (in this case `HashSet<{unknown}>`) with the self type of the
impl (`HashSet<?0>`), but if the given self type contains Unknowns, they won't
be unified with the variables in those places. So we got a receiver type that
was different from the expected one, and concluded the impl doesn't match.
The fix is slightly hacky; if after the unification, our variables are still
there, we make them fall back to Unknown. This does make some sense though,
since we don't want to 'leak' the variables.
Fixes #3547.
|