[S3] upstream 동기 — 컷 822504b (오류 분류 축, 충돌 11) - #16
Merged
Conversation
Bumps [bytemuck](https://github.com/Lokathor/bytemuck) from 1.25.0 to 1.25.1. - [Changelog](https://github.com/Lokathor/bytemuck/blob/main/changelog.md) - [Commits](Lokathor/bytemuck@v1.25.0...v1.25.1) --- updated-dependencies: - dependency-name: bytemuck dependency-version: 1.25.1 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>
* Replace runtime panics with the matching Java exceptions An unwrap audit found panics reachable from ordinary Java code: - File.length() returns 0 for a missing file; isDirectory/isFile lose their guard-then-unwrap shape - FileImpl (native runtime) maps open/read/write/seek failures to IOError instead of panicking, so FileInputStream and RandomAccessFile guards actually produce FileNotFoundException; FileOutputStream gains the same guard - File I/O operations (read/write/seek/available/length/setLength) throw java.io.IOException on failure via a shared helper - Class.forName resolves the class and throws ClassNotFoundException (new runtime class) instead of panicking on any not-yet-loaded name - StringBuffer.append(char)/append(char[]) keep exact UTF-16 units so unpaired surrogates no longer panic and pairs built char by char survive; String.valueOf(char) builds through [C for the same reason - PrintStream.println(char) replaces an unpaired surrogate with '?' like the JDK charset encoder - ZipFile validates the archive in its constructor and throws java.util.zip.ZipException (new runtime class) for a malformed archive; getInputStream returns null for a missing entry Expected outputs for the new fixtures are generated by a real JVM. Remaining unwraps are invariants (interpreter stack discipline, thread attach), guarded lookups, or documented gaps (lenient calendar normalization, ClassFormatError plumbing). * Inline the IOException conversion at each I/O call site
Every attached thread now owns its java/lang/Thread instance: attach takes the instance for threads started via Thread.start (so currentThread() inside run() is the started Thread object) and creates one otherwise (bootstrap, external attachers). currentThread() returns the stored instance, and the GC roots it per thread. Also parse unrecognized classfile attributes as an opaque Unknown variant instead of failing — JVMS 4.7.1 requires silently ignoring them, and the anonymous-class fixture carries EnclosingMethod and Signature attributes the parser rejected. Expected output for the fixture is generated by a real JVM.
* Add Java primitive wrapper classes * Use Character digit semantics for numeric parsing
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.52.3 to 1.52.4. - [Release notes](https://github.com/tokio-rs/tokio/releases) - [Commits](tokio-rs/tokio@tokio-1.52.3...tokio-1.52.4) --- updated-dependencies: - dependency-name: tokio dependency-version: 1.52.4 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>
* Add CLDC 1.1 core API compatibility * Fix CI lint and improve CLDC coverage * Fix array assignability and reader progress
* Harden JVM runtime correctness * Address classfile review findings * Move class initialization tests to Java fixture * Separate classfile validation from JVM verification * Remove ClassFileError re-export
PR #11 was squash-merged, so upstream ancestry was lost: origin/main carries 1f356ae's content byte-for-byte (git diff 0bd4f80 origin/main -- '*.rs' '*.toml' '*.lock' is empty) but git still resolved the merge base to 62cf0c6, replaying all six upstream commits and re-conflicting 15 files instead of the predicted 5. This -s ours merge changes no tree bytes; it only records the parent so that S2..S7 merge against 1f356ae as base.
… API, PR dlunch#177) Conflicts (5, exactly as S1 predicted): - java/io.rs, java/io/unsupported_encoding_exception.rs, loader.rs: upstream side is a superset; took it, then restored our ClassFormatError registration that --theirs had dropped from loader.rs. - java/io/input_stream_reader.rs: kept our Charset abstraction (4 charsets vs upstream's inline 2) and adopted upstream's decode_length/end_of_input multibyte-boundary handling on top of it. - tests/.../test_input_stream_reader.rs: union of both sides' tests. Also fixed a silent auto-merge duplicate: both sides added a byte-identical Throwable::getMessage at different positions, so git merged both and the build failed with E0592. Kept upstream's placement. InputStreamReader's single-argument ctor stays lazy about the default charset (JDK does not declare it to throw UnsupportedEncodingException); only the (InputStream, String) ctor validates eagerly, as upstream added. cargo fmt/clippy/clippy-wasm32/test all rc=0; 191 passed / 0 failed.
…flicts 5, ancestry restore)
…m-sync-s3 # Conflicts: # REPORT.md # STATE.md
…ication, PR dlunch#180) conflicts 11 resolved: classfile/{class,constant_pool,error,lib}.rs + jvm_rust/class_definition.rs + src/runtime.rs + test_utils/lib.rs -> upstream (ClassFileError/ClassDefinitionError, 4 Java exception kinds vs our 1); java/lang/string.rs -> upstream structure routed through our charset::Charset (default path falls back, explicit path throws, duplicate table dropped); test_string.rs -> union of both test sets; thread.rs -> upstream body under PR #4's manual span; AGENTS.md -> union. tests/test_class_format.rs: message assertions relaxed, ClassFormatError kind assertions kept (upstream flattens parse causes into "Invalid class file").
…flicts 11) + refresh STATE 「다음」 STATE.md ③-0 pointed at rustjava-pr8-claude-md-prune-disposition as top priority on the grounds that its review.md was missing and gate 2 had stalled. Both are false now: PR #8 is MERGED (2026-08-18T19:26:08Z -> 00bddf3) and the review reports exist. Item closed, list renumbered, ⑤ operating notes re-measured (open PRs 2 -> 1, dead branch row dropped).
added 2 commits
August 27, 2026 06:59
… (tree unchanged)
…rect the ancestry-axis prediction
This was referenced Aug 26, 2026
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 free
to 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.
티켓
rustjava-upstream-sync-s3· 정본docs/upstream-sync-approach.md§5(한 티켓 = 한 컷).★base 가
main이 아니라feat/rustjava-upstream-sync-s2다. S2(PR #13)가 아직 열려 있어main을 base 로 잡으면 S2 의 충돌 5건을 다시 만난다. #13 이 착지하면 이 PR 은 자동으로main으로 리타깃된다.무엇을
upstream
822504b(dlunch#180 Harden JVM runtime correctness) 1커밋 머지 · 충돌 11 해소.classfile/src/{class,constant_pool,error,lib}.rs·jvm_rust/class_definition.rs·src/runtime.rs·test_utils/src/lib.rsParseError(Java 예외 1종) → upstreamClassFileError+ClassDefinitionError(4종:ClassFormatError·UnsupportedClassVersionError·VerifyError·UnsupportedOperationException). 계획서 §3-B 판정 그대로java/lang/string.rscharset::Charset라우팅. upstream 의decode_str/encode_str중복 표 삭제tests/.../test_string.rsjava/lang/thread.rs#[tracing::instrument]재유입 0AGENTS.md★계획서 §4-A 가 예고한 «충돌 0 파손»이 실제로 났다
tests/test_class_format.rs는 우리 전용이라 충돌 마커가 한 줄도 안 뜨는데, upstream 이 원인별문구를
"Invalid class file"로 평탄화해 3건이 깨진다. ⇒ 문구 단정만 삭제("Truncated"·"tag 18"·"magic"),ClassFormatError종류 단정은 유지. 4/4 통과.검증 (CI
rust.yml4종 · 전건 로컬 rc=0)cargo fmt --all -- --check·cargo clippy --all -- -D warningscargo clippy --workspace --exclude test_utils --target wasm32-unknown-unknown -- -D warningscargo test --all→ 216 passed / 0 failed / 1 ignored (S1 169 → S2 191 → S3 216)tests/test_class_format.rs4/4 ·git grep 'tracing::instrument\|tracing-attributes'0건af4f6f8이후 우리가 추가한.rs321줄 중 부재 81줄, 전건 의도한 해소★충돌은 계획서 예측(+9)보다 2건 많았다
⑴
AGENTS.md— 계획서 작성 이후 PR #15 가 만든 파일이라 표에 있을 수 없었다.⑵★
thread.rs— S1 이 이미 닫은 파일이 다시 충돌했다(822504b가 같은 함수를 재작성).⇒ 「새 충돌 = 그 컷에서 «처음» 충돌하는 파일 수」라는 계획서 정의는 한 번 닫히면 다시 안 열린다를
암묵 전제하는데, 그 전제가 깨졌다. 예측은 하한으로 읽어라.
조상
git merge-base HEAD upstream/main=af4f6f8⇒ S2 가 했던-s ours복원은 불필요했고 하지 않았다.★단 #13 이 스쿼시로 착지하면 다시 끊긴다 — 이 PR 이
main으로 리타깃된 뒤merge-base를 다시 재라.머지 0 · force-push 0 · 리베이스 0 · upstream 발신 0.