| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
fix: When displaying a projection into a type parameter that has bounds as `impl Trait`, collect only the bounds of this projection
|
|
Trait`, collect only the bounds of this projection
It used to collect the bounds of them all.
|
|
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 733dab558992d902d6d17576de1da768094e2cf3
Filtered ref: 8f0faf94fb41d4e2a85ef2d23e5495f6bea1f31d
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
|
|
We lost the following comment during refactorings:
The current code for niche-filling relies on variant indices instead of actual discriminants, so enums with explicit discriminants (RFC 2363) would misbehave.
|
|
|
|
|
|
|
|
We should not only in type position.
|
|
fix: Normalize projection types before calculating memory maps
|
|
|
|
perf: Put the expression stuff in the expression store behind an `Option<Box>`
|
|
|
|
fix: Fix display of `use<>` syntax
|
|
|
|
fix: Inline asm fixes
|
|
And leave only the type stuff without it.
This is because most expression stores don't have anything but types (e.g. generics, fields, signatures) so this saves a lot of memory.
This saves 58mb on `analysis-stats .`.
|
|
only `asm!()` unsafe
|
|
`rustc_pattern_analysis`: always check that deref patterns don't match on the same place as normal constructors
In rust-lang/rust#140106, deref pattern validation was tied to the `deref_patterns` feature to temporarily avoid affecting perf. However:
- As of rust-lang/rust#143414, box patterns are represented as deref patterns in `rustc_pattern_analysis`. Since they can be used by enabling `box_patterns` instead of `deref_patterns`, it was possible for them to skip validation, resulting in an ICE. This fixes that and adds a regression test.
- External tooling (e.g. rust-analyzer) will also need to validate matches containing deref patterns, which was not possible. This fixes that by making `compute_match_usefulness` validate deref patterns by default.
In order to avoid doing an extra pass for anything with patterns, the second commit makes `RustcPatCtxt` keep track of whether it encounters a deref pattern, so that it only does the check if so. This is purely for performance. If the perf impact of the first commit is negligible and the complexity cost introduced by the second commit is significant, it may be worth dropping the latter.
r? `@Nadrieril`
|
|
|
|
Allow custom default address spaces and parse `p-` specifications in the datalayout string
Some targets, such as CHERI, use as default an address space different from the "normal" default address space `0` (in the case of CHERI, [200 is used](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-877.pdf)). Currently, `rustc` does not allow to specify custom address spaces and does not take into consideration [`p-` specifications in the datalayout string](https://llvm.org/docs/LangRef.html#langref-datalayout).
This patch tries to mitigate these problems by allowing targets to define a custom default address space (while keeping the default value to address space `0`) and adding the code to parse the `p-` specifications in `rustc_abi`. The main changes are that `TargetDataLayout` now uses functions to refer to pointer-related informations, instead of having specific fields for the size and alignment of pointers in the default address space; furthermore, the two `pointer_size` and `pointer_align` fields in `TargetDataLayout` are replaced with an `FxHashMap` that holds info for all the possible address spaces, as parsed by the `p-` specifications.
The potential performance drawbacks of not having ad-hoc fields for the default address space will be tested in this PR's CI run.
r? workingjubilee
|
|
default data address space
|
|
chore: Remove dead field from `InferenceContext`
|
|
|
|
fix: Fix diverging destructuring assignments
|
|
They need to return `!`, unlike diverging ordinary assignments. See the comment in the code.
|
|
This makes it work for box patterns and in rust-analyzer.
|
|
|
|
|
|
fix: Improve diagnostic ranges for `macro_calls!`
|
|
We used to point to the entire macro call including its token tree if we couldn't upmap the diagnostic to the input
This generally makes things very noisy as the entire macro call will turn red on errors.
Instead, we now macro the path and `!` (bang) token as the error source range which is a lot nicer on the eyes.
|
|
|
|
|
|
It's not necessary anymore due to Rust 2024 lifetime capture rules.
|
|
|
|
Backport new sized-hierarchy trait bounds in old ways
|
|
|
|
|
|
|
|
De-arc trait items query
|
|
|
|
|
|
Do not default to 'static for trait object lifetimes
|
|
We lack trait object default lifetime elision, so `'static` can be wrong at times, confusing the user
|
|
minor: Don't run doctests
|
|
|
|
|