[S6] upstream 동기 — 컷 95ebc5c (regex·Formatter·Locale · 충돌 1) [rustjava-upstream-sync-s6-cut-95ebc5c] - #22
Merged
Merged
Conversation
* Share char array buffers in java.lang.String Switch String to the JDK 1.x representation of value/offset/count so substring can share its parent's char array instead of copying, which also removes the lossy UTF-16 -> Rust String -> UTF-16 round trip the old substring went through. - add a package-private String(int, int, char[]) for trusted callers that pass a freshly allocated array; public entry points keep copying defensively - toCharArray() now returns a copy; it previously handed out the backing array, which let callers mutate a String in place - charAt()/getChars() gained bounds checks: with a shared array an out of range index would otherwise quietly read a neighbouring string - equals()/endsWith() compare code units instead of lossy conversions, so distinct unpaired surrogates no longer compare equal - String(String) shares only when the source spans its whole array, so new String(huge.substring(..)) still detaches the large buffer - route StringBuffer, StringTokenizer and Properties through JavaLangString::to_utf16 rather than reading String.value directly Cuts string construction from two array copies to one and makes substring allocation free. * Match the JDK on regionMatches and drop leftover io copies regionMatches returned false for a negative len, but the JDK's bounds test widens to long and its comparison loop simply never runs, so an otherwise in-range region reports a match. Widening the check here too keeps a len near i32::MAX from overflowing the offset arithmetic. BufferedReader.readLine() and DataInputStream.readUTF() built an exactly sized char array and then handed it to a copying constructor. They now go through JavaLangString::from_utf16, which takes the sharing constructor, so each line and each UTF entry costs one array copy instead of two. * Reject a corrupt String range instead of panicking The sharing constructor took offset and count on trust, but the runtime does not enforce access flags, so any bytecode can call it. A negative offset widened to a huge usize and overflowed the addition in the array bounds check, killing the VM instead of raising a Java exception: thread panicked at jvm/src/jvm.rs:440: attempt to add with overflow The constructor now validates its range, and the two places that read the fields back reject a negative one, since a putfield can plant it just as easily. load_array and store_array saturate when computing the end of the requested region so no caller can overflow the check, which also covers the 32-bit targets where a valid-looking pair of i32 values can sum past usize. Reported by Copilot on dlunch#191. * Name the sharing constructor after its char array init_shared said nothing about what it takes, and the file names every other constructor after its arguments.
Bumps [event-listener](https://github.com/smol-rs/event-listener) from 5.4.1 to 5.4.2. - [Release notes](https://github.com/smol-rs/event-listener/releases) - [Changelog](https://github.com/smol-rs/event-listener/blob/master/CHANGELOG.md) - [Commits](smol-rs/event-listener@v5.4.1...v5.4.2) --- updated-dependencies: - dependency-name: event-listener dependency-version: 5.4.2 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Implement Java 5 formatter support * Address Formatter review feedback
* Implement CDC 1.1 LinkedHashMap * Fix LinkedHashMap review findings * Defer virtual dispatch rework
* Add java.util.logging core APIs * Address logging formatter review feedback
Bumps [async-trait](https://github.com/dtolnay/async-trait) from 0.1.91 to 0.1.92. - [Release notes](https://github.com/dtolnay/async-trait/releases) - [Commits](dtolnay/async-trait@0.1.91...0.1.92) --- updated-dependencies: - dependency-name: async-trait dependency-version: 0.1.92 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Fix Cloneable and Serializable class metadata * Remove cross-package marker metadata test
착수 시 재측정(★§5 상시 규칙 — base 병기): base = origin/main a0b5d3c · merge-base c4665b0 ⇒ 충돌 «1건»(java/lang/string.rs). ★예측 「S6 새 충돌 0」과 어긋난 것이 아니다 — 축이 다르다. 그 0 은 옛 base 8c1238b 에서 잰 «델타»(누적 3 → 3, 새로 «나타난» 파일 0)이고, 지금 값은 새 base 에서 잰 «누적 1»이다. ⇒ ★「델타 0」이 「풀 것이 없다」가 아니다. string.rs 는 S5 의 설계 판단으로 우리 쪽 분기가 남아 있어(+8/−28) upstream 이 그 파일을 만질 때마다(이 구간 +402/−121) 계속 충돌한다. 해소: import 블록 «합집합» — 우리 charset::Charset + upstream 의 재구조화된 classes::java::{lang, util::{Formatter, Locale, regex::{Matcher, Pattern}}}. Charset 라우팅 4곳 생존 · upstream 이 되살렸던 decode_str/encode_str 재유입 0. ★계약4⒝ 정독이 «충돌 0으로 들어온» 파손 1건을 잡았다: upstream 이 이 구간에 새로 넣은 java/util/regex/test_pattern_syntax_exception.rs 가 System.setProperty 를 )Ljava/lang/Object; 로 3곳 부른다(우리는 PR #5 에서 JDK 규격대로 String). 서술자만 맞췄다 — S5 가 5곳에 적용한 확립된 처분과 같다. ★이 형태는 이번이 세 번째다(S3 · S5 · S6). ★계약4⒞ Cargo.lock: 내려간 크레이트 0(async-trait 0.1.92 유지 — S5 를 문 자리) · 올라간 3(event-listener·regex-automata·regex-syntax) · 추가 regex · 제거 2. green: stable 4종 rc=0 · ★beta 2종 rc=0 · cargo test --all 554 passed / 0 failed / 1 ignored (baseline 427 → +127 · 새 red 0) · beta 도 554 동수 · 95ebc5c 대비 삭제 파일 0.
§5 재측정 표는 재작성하지 않고 「[2026-09-04] S6 착지 기록」 절을 신설했다(델타/누적 구별 · 합집합 해소 · 신규 파일 파손 3회째 · Cargo.lock · S7 참고값). STATE·REPORT 갱신 + 워크로그 쌍 신설 (adoptedProposals = 2026-09-04-upstream-sync-s5#p0).
…-cut-95ebc5c] STATE.md 진행중 → 완료(게이트③ PR #22 · --merge) + 「S7 수는 다시 재야 한다」 + 검수자 지적 ⒝ (§5 정본 서식에 델타/누적 축이 아직 없다 — 다음 회차 몫) + worklog .json 2줄. 코드 변경 0.
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
upstream
95ebc5c(11커밋 · 142파일 +17,593/−483)을--merge로 흡수하고 충돌 1건을 해소했다.채택 제안
2026-09-04-upstream-sync-s5#p0.계보
merge-base origin/main upstream/mainc4665b095ebc5c**a0b5d3c+95ebc5c)★★게이트③이
--squash면 이 전진이 통째로 사라진다 —<id>-merge에merge_strategy: merge필수.★착수 시 재측정 — 「새 충돌 0」을 «전제»로 쓰지 않았다
base =
origin/maina0b5d3c·merge-basec4665b0⇒ 충돌 ★1건(string.rs).★**「재서 0 이었다」가 아니라 「재서 1 이었다」.** 그 차이가 이 회차의 첫 산출이다.
★★예측과 실측은 «둘 다 참»이고 축이 다르다
8c1238b(mb3296139c)a0b5d3c(mbc4665b0)string.rs는 S5 에서 이미 집합 안에 있어 «새로» 나타나지 않았고(델타 0), S5 의 설계 판단으로우리 분기(+8/−28)가 남아 upstream 이 만지는 한(이 구간 +402/−121) 계속 열린다.
⇒ ★**§5 에 한 줄 보탰다: base 와 «함께» «델타/누적»도 밝혀라.** base 만 병기하면 「0」이 「풀 것이 없다」로 읽힌다.
해소 — import 블록 «합집합»
충돌면은 import 한 곳(hunk 1개). 우리
charset::Charset유지 + upstream 재구조화classes::java::{lang, util::{Formatter, Locale, regex::{Matcher, Pattern}}}채택.★
--theirs였으면charset::Charset이 사라져 호출부 4곳이 컴파일 실패한다.검증:
Charset라우팅 4곳 생존 · ★S5 가 버린decode_str/encode_str재유입 0.★★계약4⒝ — 「충돌 0으로 들어온」 파손 1건을 «테스트 전에» 잡았다 (이 형태 «세 번째»)
정독 대상을 좁혔다:
comm -12로 양쪽이 둘 다 만진 9건만 읽었다(우리 49 ∩ upstream 142) —AGENTS.md+56/−0 ·Cargo.toml핀 부재 유지 ·jvm.rs서술자 + allow 6곳 · 테스트 3건 ·test_string+41/−0 전건 생존.★그런데 파손은 «교집합 밖»에 있었다: upstream 이 이 구간에 새로 넣은
java/util/regex/test_pattern_syntax_exception.rs가System.setProperty를)Ljava/lang/Object;로 3곳 부른다(우리는 PR #5 에서 JDK 규격대로
String). ★신규 파일이라 충돌이 «날 수가 없다» —merge-tree도 교집합 대조도 못 본다.⇒ 서술자만 맞췄다(S5 가 5곳에 적용한 확립된 처분 ·
Properties.setProperty7곳은 JDK 규격상Object라 무접촉).★전례: S3 3건 → S5 5곳 → S6 3곳 — 매 회차 «새 파일»로 재유입된다.
★
Cargo.lock— S5 를 문 자리를 «먼저» 쟀다★내려간 크레이트 0건(
async-trait0.1.92 유지 · upstream95ebc5clock 도 이미 0.1.92) ·올라간 3 · 추가
regex· 제거 2. ★beta 축도 push 전에 직접 돌렸다(S5 는 CI 가 알려 줬다).green
fmt --checkclippy --all -D warningsclippy wasm32 -D warningstest --allcheck-worklog-json.py★새 red 0: baseline 427/0/1 → 554/0/1(+127). S1 169 → … → S5 427 → ★S6 554.
「해소분 0」:
95ebc5c대비 삭제 파일 0 · 다른 파일 50건 전수가 우리 fork 고유 자산 ·tracing::instrument실사용 0(주석 1) · 수동 span 2곳 ·charset.rs실재 · 픽스처 4 ·test_class_format4/4.★정직 고지: 티켓 계약5 의 예시 「
test_timer.rs의 500→2000ms 여백이 살아 있는가」는 낡았다 —S5 가 그 파일을 upstream 결정성 스위트 12건으로 대체했으므로 ★여백 0곳이 정상이다(회귀 아님 · 근거는 §5 에 보존).
경계
머지 0 · 새 PR 1(base
main· 스택 아님) · force-push 0 · 리베이스 0 ·main직접 push 0 ·★S7 흡수 0(
merge-base가95ebc5c에서 멈춘 것이 증거) · upstream 코드 «개선» 0 ·★S8 신설 지시는 집행하지 않았다(총괄 보류분) · §5 재측정 표 재작성 0 · upstream 발신 0.