[S2] upstream 동기 — 컷 af4f6f8 (charset 축, 충돌 5)

[Jun025]

upstream 컷 af4f6f8(dlunch#177 CLDC 1.1 core API) 머지. 티켓 rustjava-upstream-sync-s2.

급소 — 조상이 끊겨 있었다

PR #11(S1)이 스쿼시 머지돼 origin/main 에 1f356ae 가 조상으로 남지 않았다.
코드 트리는 S1 머지 결과와 바이트 동일한데(git diff 0bd4f80 origin/main -- '*.rs' '*.toml' '*.lock' 빈 출력)
merge-base 는 여전히 62cf0c6 라, merge-tree 가 6커밋을 통째로 재생하며 충돌 15건을 냈다 —
전부 S1 이 이미 해소한 자리다.

git merge -s ours 1f356ae(트리 무변경, 부모만 기록)로 base 를 복원 → 충돌 5건,
S1 이 예고한 파일 5개와 정확히 일치.

충돌 5건 — 무엇을 골랐고 왜

파일	처분
java/io.rs	upstream(상위집합). 우리 UnsupportedEncodingException export 유지 확인
java/io/unsupported_encoding_exception.rs	upstream. 의미 동일, 본문만 더 짧다
java/loader.rs	upstream + 우리 ClassFormatError::as_proto() 등록 1줄 복원(--theirs 가 지웠다)
java/io/input_stream_reader.rs	우리 Charset 유지(4종 vs upstream 인라인 2종) + upstream 의 멀티바이트 경계 처리(decode_length·end_of_input) 채택
tests/.../test_input_stream_reader.rs	합집합(우리 3 + upstream 4 = 7건 전부 통과)

충돌 목록 «밖» 파손 2건

1. Throwable::getMessage 조용한 중복 — 양쪽이 바이트 동일한 메서드를 다른 위치에 추가해
   git 이 둘 다 머지, E0592 duplicate definitions 로 빌드 실패. 충돌 마커도 clippy 도 못 잡고
   컴파일만이 잡는다. upstream 위치를 남기고 우리 사본을 제거.
2. loader.rs 등록 1줄 유실 — --theirs 통째 해소의 부작용. test_class_format 3건이
   NoClassDefFoundError 로 죽어서 발견. 이후 「base 이후 우리가 추가한 260줄이 머지 트리에
   살아 있는가」를 기계로 전수 대조(부재 2건은 의도한 해소임을 확인).

판단 1건 — 생성자별 charset 검사 시점

upstream 은 1인자 생성자를 2인자에 위임시켜 양쪽 다 생성 시점에 미지원 charset 을 던지게 만들었다.
그러면 PR #5 의 종단 픽스처(test_data/UnsupportedCharset)가 깨진다 — 그 Java 소스는 생성자를
try 밖에 두어 read() 시점 throw 를 잠갔기 때문이다(이 맥에 JDK 부재라 재컴파일 불가).

JDK 규격이 답을 준다: 1인자 생성자는 UnsupportedEncodingException 을 선언하지 않고, 2인자는 한다.
⇒ 필드 초기화를 init_fields 로 빼고 2인자만 즉시 검증, 1인자는 기존대로 read() 시점.
upstream 의 신규 테스트 test_input_stream_reader_rejects_unknown_encoding(2인자 사용)과
우리 test_isr_unsupported_charset_throws(1인자 사용)가 둘 다 산다.

green (CI .github/workflows/rust.yml 4단계 그대로)

명령	rc
cargo fmt --all -- --check	0
cargo clippy --all -- -D warnings	0
cargo clippy --workspace --exclude test_utils --target wasm32-unknown-unknown -- -D warnings	0
cargo test --all	0 — 191 passed / 0 failed / 1 ignored (S1 169 → +22, 우리 테스트 유실 0)

upstream 신규 테스트가 실제로 돌았음 확인(이름으로): test_input_stream_reader_* 3건 ·
test_reader_default_contract_and_lifecycle · test_output_stream_writer_* 3건 · test_print_stream_* 2건 ·
test_cldc11_* 2건 · test_date_*/test_random_*/test_calendar_*.

charset.rs dead-code 예측 — ★발동하지 않았다

S1 은 「S2 가 input_stream_reader.rs 를 건드리므로 charset.rs 가 dead code 가 돼 clippy red」를
예고했다. 실측: 호출자가 5 → 7건으로 늘었다(git grep Charset::). 예측의 전제였던
「upstream 판본을 통째로 취한다」가 성립하지 않았기 때문이다. clippy rc=0.

경계

머지 0(이 PR 은 OPEN 유지) · force-push 0 · --no-verify 0 · upstream 발신 0(읽기 조회만) ·
main 무접촉 · ~/orchestrator 무접촉 · 로컬 브랜치 위생 미실시(별건).

[Jun025]

★CI red 고지 — 선재다. 실측으로 갈랐다.

gh pr checks 13 은 rust_ci 6잡 전부 fail 로 보이지만, ★실제 실패는 1잡뿐이다:
ubuntu-latest, beta = failure · 나머지 5잡 = cancelled(matrix fail-fast 기본값).

내용: clippy::double_must_use 13건, 전건 #[async_trait]/#[async_recursion] 매크로 전개분
(jvm/src/jvm.rs·class_definition.rs·class_loader.rs).

선재 판정 — 주장이 아니라 대조: 로컬에 beta(1.99.0-beta.1)를 설치해 같은 명령을 두 트리에 돌렸다.

트리	cargo +beta clippy --all -- -D warnings	건수
origin/main(내 변경 0)	rc=101	13
본 PR	rc=101	13

같은 수, 같은 파일 ⇒ 이 PR 이 만든 red 가 아니다.

교차 근거:

• 지목 파일 class_definition.rs·class_loader.rs 는 이 머지가 건드리지 않았다
  (git diff --stat origin/main HEAD -- <두 파일> → 빈 출력). jvm/ 변경은 jvm.rs 1개뿐.
• 의존 동일 — async-trait 0.1.89 · async-recursion 1.1.1(af4f6f8 은 이들을 올리지 않는다).
• 근인 = 부동 툴체인 드리프트. main 의 마지막 CI(2026-08-18)는 beta 포함 6/6 success 였다.
  그 사이 새 beta 가 집혔고 그 clippy 가 이 lint 를 새로 문다.

★stable 은 초록: 로컬 rustc 1.98.0(CI stable 과 동일)로 origin/main·본 PR 둘 다 clippy rc=0.
⇒ 이 red 는 미래 툴체인 예고이지 현재 결함이 아니다. coverage 는 이번에 pass.

고치지 않은 이유: main 이 똑같이 red 라 이 회차 귀속이 아니고, 처방이 CI 정책 결정이라 총괄 판단 사항이다.
별건 발권 추천(rustjava-ci-beta-clippy-double-must-use-red) — 처방 후보 ⒜jvm/src/lib.rs 에
#![allow(clippy::double_must_use)] 1줄 ⒝async-trait 상류 수정 대기 ⒞matrix fail-fast: false
(★이번에 「6잡 전부 fail」로 보인 것이 정확히 그 부작용이다).

로컬 green 재확인(stable 1.98.0, CI 4단계 그대로): fmt ✅ · clippy ✅ · wasm32 clippy ✅ ·
cargo test --all ✅ 191 passed / 0 failed / 1 ignored.