Skip to content

fix: avoid array len type mismatch with string panic - #23019

Merged
ChayimFriedman2 merged 1 commit into
rust-lang:masterfrom
edragain2nd:fix/array_len_string_literal_mismatch
Aug 5, 2026
Merged

fix: avoid array len type mismatch with string panic#23019
ChayimFriedman2 merged 1 commit into
rust-lang:masterfrom
edragain2nd:fix/array_len_string_literal_mismatch

Conversation

@edragain2nd

@edragain2nd edragain2nd commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

fixes #22955
the root cause is that in function intern_const_ref when value is Literal::String, it builds ValTreeKind::Branch without checking the typekind (like TyKind::Uint),
and in function render_const_scalar_from_valtree_inner it calls function to_leaf.
to_leaf panics on the ValTreeKind::Branch.

I modify the condition so we only build ValTreeKind::Branch when the type is compatible.
but now it can reach the never! stmtment which cause panic again.
I remove the stmtent and I wonder the remove is suitable or not.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 3, 2026

@ChayimFriedman2 ChayimFriedman2 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a possible way.

View changes since this review

}

#[test]
fn invalid_array_len_string_literal_does_not_panic() {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test should not be here, or in any ide- crate.

@edragain2nd

Copy link
Copy Markdown
Contributor Author

@rustbot ready

@ChayimFriedman2 ChayimFriedman2 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please squash.

},
traits::StoredParamEnvAndCrate,
};
use base_db::Crate;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why all these changed position? Please revert that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems that after I remove the never stmt and ran the command cargo fmt, the imports are reordered.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably have different rustfmt settings.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that's because you also removed the newline after.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh thanks for pointing out! i add the newline back, and it'is fine now.

@edragain2nd
edragain2nd force-pushed the fix/array_len_string_literal_mismatch branch from f8a6f61 to 7ee9a18 Compare August 4, 2026 17:37
@edragain2nd
edragain2nd force-pushed the fix/array_len_string_literal_mismatch branch from 7ee9a18 to d9d4b1a Compare August 4, 2026 23:39

@ChayimFriedman2 ChayimFriedman2 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ChayimFriedman2
ChayimFriedman2 added this pull request to the merge queue Aug 4, 2026
Merged via the queue into rust-lang:master with commit 185894d Aug 5, 2026
18 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 5, 2026
glslang added a commit to glslang/agent-skills that referenced this pull request Aug 6, 2026
Three self-contradictions in address-pr-comments (#7), each a rule in one
section silently overridden by a rule in another.

The judge/advisory split had no effect: section 9's first gate rejected any
`open` row, and an advisory nit the stop policy declined to fix stayed
`open` forever. Ledger rows now carry `weight`, and `noted` is a terminal
status for an advisory ask deliberately left — legal only on an advisory
row, so a judge's finding still cannot leave the gate unaddressed.

"Just the blocking ones" filtered on `pullRequestReview.state`, which is
frozen when the review is submitted. A reviewer who requests changes and
later approves leaves those comments joined to a CHANGES_REQUESTED object
permanently (confirmed on rust-lang/rust-analyzer#23019, where the current
verdict is APPROVED). Section 2 now folds the review history to one current
verdict per author, dropping COMMENTED since GitHub does not treat it as a
verdict; the filter and section 9's gate both read that instead.

The no-gh fork fallback produced a checkout with no upstream, so section 5's
push died on "no upstream branch" after the fixes were already written.
Section 0 now establishes the push target at checkout time and names the
case where there is none — a fork without "allow edits from maintainers",
where the sweep must be replies-only rather than commits nobody can deliver.

Also swept the file for the same pattern: judge weight keyed to the reviewer
rather than their current verdict, "every judge is satisfied" not read as
"must have approved", GitHub's resolved flag separated from ledger status,
and sections 6 and 8 taught the new status.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

panic: union with malformed array; expected leaf, got Branch

3 participants