[S1] upstream 동기 — 컷 1f356ae (tracing 축, 충돌 2)

[Jun025]

티켓: rustjava-upstream-sync-s1-tracing-cut-1f356ae · 정본 계획 docs/upstream-sync-approach.md §4·§6

upstream 1f356ae(dlunch#173~dlunch#179 · 5커밋)를 origin/main 에 머지한다. 접근안이 정한 7회차 중 S1, 축은 tracing / PR #4.

착수 시 충돌 재측정 (필수0)

git fetch upstream 후 git merge-tree --write-tree --name-only origin/main 1f356ae (2026-08-17 13:11 KST):

• java_runtime/src/classes/java/lang.rs
• java_runtime/src/classes/java/lang/thread.rs

⇒ 2개 그대로. 계획서 예측과 일치. (origin/main 은 PR #10 착지로 85f294a → 03438b0 로 움직였고 rev-list 는 10 33 → 11 33 이 됐지만 충돌 집합은 불변.)

충돌 해소

lang.rs — 양쪽 병합

mod 목록은 자동으로 합집합이 됐고, pub use 블록만 rustfmt 재배치 때문에 충돌했다. 3-way 로 보면 의미 충돌이 아니라 양쪽이 서로 다른 항목을 추가한 것뿐이다.

• 우리(base→origin/main): class_format_error::ClassFormatError 1건 추가 (PR [rustjava-classfile-parse-error-propagation] fix: unreadable class files raise ClassFormatError instead of panicking #3)
• upstream(base→1f356ae): boolean·byte·character·double·float·long·number·short·class_not_found_exception 10건 추가 (PR Add Java primitive wrapper classes dlunch/RustJava#176)

⇒ 양쪽 전부 유지. 어느 쪽도 버리지 않았다.

thread.rs — upstream 뼈대 + PR #4 수동 span

upstream 시그니처 변경을 확인했다:

• self.jvm.attach_thread()? → self.jvm.attach_thread(self.this.instance.clone()).await? (인자 추가 + async 화)
• current_thread: 매번 새 Thread 생성 → jvm.current_java_thread() (PR Return the same Thread object from Thread.currentThread() dlunch/RustJava#175 «같은 객체 반환»)

⇒ 우리 본문은 쓸 수 없어 upstream 을 통째로 뼈대로 취한 뒤 #[tracing::instrument] 한 줄만 PR #4 의 수동 span(tracing::info_span! + .instrument(span))으로 치환하고 use tracing::Instrument; 를 복원했다.

• Cargo.toml(root)·java_runtime/Cargo.toml 무접촉 (git diff origin/main -- <두 파일> 빈 출력) ⇒ attributes 피처 꺼진 채 유지, tracing-attributes 핀 부활 없음
• 검증: git grep -n 'tracing::instrument\|tracing-attributes' -- '*.rs' '*.toml' '*.lock' → 히트 1건이고 그것은 왜 수동 span 인지 설명하는 주석 한 줄이다. 살아 있는 속성 매크로·의존은 0.

★충돌 목록 «밖»에서 깨진 것 — System.setProperty 서술자

머지 직후 cargo test --all 이 3 failed (test_boolean_property_and_primitive_value_of_exclusion · test_integer_rejects_invalid_forms_and_uses_property_defaults · test_long_api), 전부 NoSuchMethodError.

같은 컷을 순수 upstream 워크트리에서 돌리면 141 passed / 0 failed ⇒ 머지가 만든 파손이다.

원인:

	java/lang/System.setProperty 서술자
base 62cf0c6	(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Object;
upstream 1f356ae	…)Ljava/lang/Object; (불변)
우리 origin/main	…)Ljava/lang/String; (PR #5 7fd0ad8 가 변경)

upstream 이 이 파일을 안 건드려 충돌 0으로 우리 쪽이 머지되는데, upstream PR dlunch#176 이 새로 들여온 테스트 6개 호출부가 Object 서술자를 박아 두었다.

어느 쪽이 옳은가: 우리 쪽이다. JDK System.setProperty(String,String) 은 String 을 반환하고, 이 저장소의 실제 javac 산출물 test_data/UnsupportedCharset.class 상수풀에도 (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; 가 그대로 박혀 있다(상수풀 파싱으로 확인). 즉 upstream 서술자를 되살리면 실제 바이트코드가 못 부른다.

⇒ 우리 서술자를 유지하고 upstream 테스트 호출부 6곳(test_boolean 2 · test_integer 2 · test_long 2)을 String 으로 고쳤다. 그 6곳이 전부 java/lang/System 대상임을 확인했고, java/util/Properties.setProperty(JDK 상 Object 반환)는 손대지 않았다.

계획서가 이름 붙인 나머지 2위험 — S1 에서는 «안» 터진다

• tests/test_class_format.rs: 4/4 통과. upstream 의 classfile/src/error.rs 재작성은 S3 컷 822504b 에 오므로 S1 에서는 문구 단정이 그대로 성립한다.
• java_runtime/src/charset.rs: 호출자 2건(input_stream_reader.rs·string.rs) 생존 ⇒ dead code 아님, clippy -D warnings green.

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 — 169 passed / 0 failed / 1 ignored

기준선 149 passed → 169 (+20, upstream 신규분).

경계

• base 불변: 머지커밋 1st parent = 03438b0 = 착수 시점 origin/main
• upstream 발신 0 (git fetch 와 읽기 조회만) · PR [rustjava-claude-md-prune] docs: prune autonomous-sop, add self-report limits + Goal/Constraints/DoD #8 무접촉 · main 무접촉 · force-push 0 · 브랜치 삭제 0 · git gc 0 · --no-verify 0
• S2(charset)·S3(오류 분류) 축 미포함
• STATE ③-2/③-3 무접촉