| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes #7626.
|
|
|
|
| |
Fixes #8604.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
8813: Get some more array lengths! r=lf- a=lf-
This is built on #8799 and thus contains its changes. I'll rebase it onto master when that one gets merged. It adds support for r-a understanding the length of:
* `let a: [u8; 2] = ...`
* `let a = b"aaa"`
* `let a = [0u8; 4]`
I have added support for getting the values of byte strings, which was not previously there. I am least confident in the correctness of this part and it probably needs some more tests, as we currently have only one test that exercised that part (!).
Fixes #2922.
Co-authored-by: Jade <[email protected]>
|
| |
| |
| |
| |
| | |
* rename ConstExtension->ConstExt
* refactor a manual construction of a Const
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix #2922: add unknown length as a condition for a type having unknown.
Incorporate reviews:
* Extract some of the const evaluation workings into functions
* Add fixmes on the hacks
* Add tests for impls on specific array lengths (these work!!! 😁)
* Add tests for const generics (indeed we don't support it yet)
|
| |
| |
| |
| | |
Now we will get the type of `[0u8; 4]`.
|
| |
| |
| |
| | |
I am not confident that my added byte string parsing is right.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now e.g.
```rust
fn a(b: [u8; 2]) {
}
```
will know about the length of b.
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
8799: Add basic support for array lengths in types r=flodiebold a=lf-
This recognizes `let a = [1u8, 2, 3]` as having type `[u8; 3]` instead
of the previous `[u8; _]`. Byte strings and `[0u8; 2]` kinds of range
array declarations are unsupported as before.
I don't know why a bunch of our rustc tests had single quotes inside
strings un-escaped by `UPDATE_EXPECT=1 cargo t`, but I don't think it's
bad? Maybe something in a nightly?
Co-authored-by: Jade <[email protected]>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This recognizes `let a = [1u8, 2, 3]` as having type `[u8; 3]` instead
of the previous `[u8; _]`. Byte strings and `[0u8; 2]` kinds of range
array declarations are unsupported as before.
I don't know why a bunch of our rustc tests had single quotes inside
strings un-escaped by `UPDATE_EXPECT=1 cargo t`, but I don't think it's
bad? Maybe something in a nightly?
|
|/
|
|
| |
Fixes #8378
|
|
|
|
| |
closes #8604
|
| |
|
|
|
|
|
| |
Chalk isn't really a 'traits' thing anymore, so it doesn't make sense to
have all the Chalk-related stuff in submodules of `traits`.
|
| |
|
|
|
|
| |
(Costs a bit of performance, reduces memory usage on RA by ~10%.)
|
| |
|
|
|
|
|
|
| |
Now that we're using Chalk's `substitute` which actually knows about
lifetimes, the hack doesn't work anymore, but we can put in a proper
lifetime.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
8409: Various remaining fixes for Chalk IR move r=flodiebold a=flodiebold
CC #8313
Co-authored-by: Florian Diebold <[email protected]>
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
| |
I'd prefer getting rid of it, but it's used in the impl search and not
super easy to replace there (I think ideally the impl search would do
proper unification, but that's a bit more complicated).
|
|
|
|
|
|
| |
Almost all uses actually only care about ADT substs, so it's better to
be explicit. The methods were a bad abstraction anyway since they
already didn't include the inner types of e.g. `TyKind::Ref` anymore.
|
|
|
|
| |
... just missing the constraints.
|
| |
|
|
|
|
|
| |
Same as https://github.com/rust-analyzer/rust-analyzer/pull/8376, this
can be computed from other data
|
|
|
|
|
| |
It stores no useful data, since we can derive all fields from
`variant_resolutions`
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
8364: Memory usage improvements r=jonas-schievink a=alexmaco
These are mostly focused on splitting up enum variants with large size differences between variants by `Box`-ing things up.
In my testing this reduces the memory usage somewhere in the low percentages, even though the measurements are quite noisy.
Co-authored-by: Alexandru Macovei <[email protected]>
|
| |
| |
| |
| | |
64bit
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
64bit systems)
Rationale: only a minority of variants used almost half the size.
By keeping large members (especially in Option) behind a box
the memory cost is only payed when the large variants are needed.
This reduces the size Vec<Expr> needs to allocate.
|
| | |
|
| | |
|
| | |
|