-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pat_analysis: Don't rely on contiguous VariantId
s outside of rustc
#120039
Conversation
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me when green
Thank you! I think bors will wait for green by itself. @bors r=compiler-errors |
Huh? No it will definitely not. As soon as you r=me, it is in the queue. Please wait next time for CI to be green 😅 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are IDs elsewhere still contiguous in the common case, even if not starting at zero? Maybe the caller could offset all IDs being passed in? I've wanted a "IndexVec, but skip leading zeros" type before...
impl<T: Copy + PartialEq + Eq + std::hash::Hash> Idx for T {} | ||
|
||
#[derive(Debug)] | ||
pub struct IdxContainer<K, V>(pub rustc_hash::FxHashMap<K, V>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use the rustc_data_structures types here instead and avoid the extra crate dep? (It's still the same under the hood, but makes it easier to tweak globally).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use the rustc_data_structures types here instead [...]
rustc_data_structures
is not compatible with rust-analyzer due to its use of nightly features. I guess @Nadrieril could add a feature = "nightly"
to that crate, but it seems unnecessary.
Are IDs elsewhere still contiguous in the common case, even if not starting at zero?
I don't believe so. As Nadrieril said above, they're global interning IDs, so they're probably really sparse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No because rust_analyzer wants to avoid the rustc_data_structures
dependency (it's really big and has lots of unstable features)
EDIT: raced by errs
It's in the queue but bors won't try to merge it until it's green, will it? There's a "mergeable" column in the queue interface, I thought that's what it was for. |
I don't think so in rust-analyzer, they're newtypes around |
Yes, bors will try to merge it as soon as it gets to it in the queue. I'm pretty certain "mergeable" field is totally separate from CI, and has to do with bors's "this PR is out of date and needs to be rebased" message it'll spit out when a PR can't be merged with master. And someone can still throw it into a rollup PR. |
Oh, oops. @bors r- |
Wait it does take CI into account: I checked the queue before the r- and this PR didn't have "mergeable=yes" |
@Nadrieril: I'm pretty certain that mergeability is not a property of CI running. The homu code is incomprehensible, but from what I can tell, this is just a property of whether a PR can be merged with the tip of master. Also from what I can tell, this mergeable field may only be set after bors merges the next commit in the queue (at the same time it'll comment on other PRs "☔ The latest upstream changes made this pull request unmergeable". But whatever, CI is green now. @bors r+ rollup |
@Nadrieril The point wasn't that bors would merge a PR without the full test suite passing, but rather that we shouldn't even put the PR into the queue before the basic (PR) test suite passes. Since it could unnecessarily cause failed merges. |
Ah, I assumed it wouldn't even try to merge. Got this idea from some blogpost of matklad's I think. It seems I was overly optimistic, sorry x) EDIT: I understood this blog post as implying that bors doesn't have the double latency problem: https://matklad.github.io/2023/06/18/GitHub-merge-queue.html . Are y'all sure it doesn't do what I expect? |
…rrors pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc Today's pattern_analysis uses `BitSet` and `IndexVec` on the provided enum variant ids, which only makes sense if these ids count the variants from 0. In rust-analyzer, the variant ids are global interning ids, which would make `BitSet` and `IndexVec` ridiculously wasteful. In this PR I add some shims to use `FxHashSet`/`FxHashMap` instead outside of rustc. r? `@compiler-errors`
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#115291 (Save liveness results for DestinationPropagation) - rust-lang#119855 (Enable Static Builds for FreeBSD) - rust-lang#119975 (Don't ICE if TAIT-defining fn contains a closure with `_` in return type) - rust-lang#119984 (Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.) - rust-lang#120001 (Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120031 (Construct closure type eagerly) - rust-lang#120032 (Fix `rustc_abi` build on stable) - rust-lang#120039 (pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc) - rust-lang#120044 (Fix typo in comments (in_place_collect)) - rust-lang#120056 (Use FnOnceOutput instead of FnOnce where expected) r? `@ghost` `@rustbot` modify labels: rollup
…rrors pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc Today's pattern_analysis uses `BitSet` and `IndexVec` on the provided enum variant ids, which only makes sense if these ids count the variants from 0. In rust-analyzer, the variant ids are global interning ids, which would make `BitSet` and `IndexVec` ridiculously wasteful. In this PR I add some shims to use `FxHashSet`/`FxHashMap` instead outside of rustc. r? ``@compiler-errors``
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#115291 (Save liveness results for DestinationPropagation) - rust-lang#119855 (Enable Static Builds for FreeBSD) - rust-lang#119975 (Don't ICE if TAIT-defining fn contains a closure with `_` in return type) - rust-lang#120001 (Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120031 (Construct closure type eagerly) - rust-lang#120032 (Fix `rustc_abi` build on stable) - rust-lang#120039 (pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc) - rust-lang#120044 (Fix typo in comments (in_place_collect)) - rust-lang#120056 (Use FnOnceOutput instead of FnOnce where expected) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#115291 (Save liveness results for DestinationPropagation) - rust-lang#119855 (Enable Static Builds for FreeBSD) - rust-lang#119975 (Don't ICE if TAIT-defining fn contains a closure with `_` in return type) - rust-lang#120001 (Consistently unset RUSTC_BOOTSTRAP when compiling bootstrap) - rust-lang#120020 (Gracefully handle missing typeck information if typeck errored) - rust-lang#120031 (Construct closure type eagerly) - rust-lang#120032 (Fix `rustc_abi` build on stable) - rust-lang#120039 (pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc) - rust-lang#120044 (Fix typo in comments (in_place_collect)) - rust-lang#120056 (Use FnOnceOutput instead of FnOnce where expected) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#120039 - Nadrieril:remove-idx, r=compiler-errors pat_analysis: Don't rely on contiguous `VariantId`s outside of rustc Today's pattern_analysis uses `BitSet` and `IndexVec` on the provided enum variant ids, which only makes sense if these ids count the variants from 0. In rust-analyzer, the variant ids are global interning ids, which would make `BitSet` and `IndexVec` ridiculously wasteful. In this PR I add some shims to use `FxHashSet`/`FxHashMap` instead outside of rustc. r? ```@compiler-errors```
Today's pattern_analysis uses
BitSet
andIndexVec
on the provided enum variant ids, which only makes sense if these ids count the variants from 0. In rust-analyzer, the variant ids are global interning ids, which would makeBitSet
andIndexVec
ridiculously wasteful. In this PR I add some shims to useFxHashSet
/FxHashMap
instead outside of rustc.r? @compiler-errors