You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit d9f45eb
Browse filesBrowse the repository at this point in the historyBrowse files
(코드 파일은 갈린다 ⇒ **기능 의존 0**). ⇒ ★**그 둘은 각자 base 당기기가 필요하다** — 해소는 그쪽 회차 몫이고 여기서 만지지 않았다.
7
40
-[rustjava-invokedynamic-bootstrapmethods-and-methodhandle] ★★**`BootstrapMethods` 를 «구조»로 읽는다 — ④-1 의 ⒜ 를 닫았다. ★콜사이트 링크 0줄.**
8
41
채택 제안 `2026-09-16-cp-tags-15-18-parse#p0`(worklog json `adoptedProposals` 에 기록).
9
42
★**`AttributeInfo::BootstrapMethods(Vec<u8>)` → `Vec<BootstrapMethod>`** · 신규 공개 타입 3종
@@ -867,7 +900,7 @@ green 전건 rc=0 · `cargo test --all` **261 passed / 0 failed / 1 ignored**(S3
867
900
★**안 되는 것(전부 이름으로)**: ⑴클래스 로드 0 ⑵멤버 조회 0(그 메서드가 실재하는지 아무도 안 본다) ⑶접근 검사 0(JVMS 5.4.3.5) ·
868
901
⑷★**`java.lang.invoke` 런타임 클래스가 «0개»다**(실측: `rustjava-runtime/src/classes/java/` 에 `invoke` 디렉터리 **부재** · 문자열 참조 **0건**) ⇒ **`MethodHandle` «객체»는 만들 수 없다** ·
869
902
⑸종류↔대상 짝짓기는 **`validation.rs` 가 진다**(파서는 일부러 중복하지 않는다 — 테스트로 잠갔다) ·
870
-
⑹`Dynamic`/`InvokeDynamic` 의 `bootstrap_method_attr_index` 는 **여전히 배열 크기로 «경계 검사되지 않는다»**(④-2 후속과 한 묶음) ·
903
+
⑹`Dynamic`/`InvokeDynamic` 의 `bootstrap_method_attr_index` 는 ★**[2026-09-16 닫힘 · `rustjava-bound-bootstrap-method-attr-index`]경계 검사된다**(부재 = 0항목 표로 함께 문다) ·
871
904
⑺★**부트스트랩 «정적 인자»는 «인덱스 그대로»** 둔다(아래 ★).
872
905
★★**⑺ 이 이 회차의 급소다 — 「인덱스를 `ConstantPoolReference` 로 풀어라」는 «회귀»다**(M3 로 측정):
873
906
`LambdaMetafactory.metafactory` 의 인자는 **MethodType·MethodHandle·MethodType** 이라 해석을 강제하면
"summary": "Bound bootstrap_method_attr_index against the BootstrapMethods table, and require that attribute when the pool needs it — one predicate, because an absent attribute is a zero-entry table.",
6
+
"changes": [
7
+
"classfile/src/validation.rs: new bootstrap_method_indices_resolve, called from validate_class; replaces the note that deferred this check",
"BootstrapMethods is still not rejected when declared more than once; JVMS 4.7.23 allows at most one, and find_map takes the first. Out of scope for this round, filed as a proposal below."
"title": "Reject a class declaring BootstrapMethods more than once",
30
+
"plainSummary": "A class file is only allowed one BootstrapMethods attribute. We currently read the first one and ignore any others.",
31
+
"userBenefit": "A hand-built or corrupted class file that carries two bootstrap tables is reported as broken instead of being silently read using whichever table came first.",
32
+
"why": "JVMS 4.7.23 says at most one BootstrapMethods attribute may appear in the attributes table of a ClassFile. bootstrap_method_indices_resolve uses find_map, which takes the first and never looks for a second, so the index is bounded against a table that may not be the only one.",
33
+
"tradeoff": "Another parse-time rejection of files that currently load, in a shape no compiler emits — so the benefit is narrow and the risk of surprising a real user is correspondingly small. It also needs a fixture the generator cannot currently build, since the attribute list is assembled per fixture.",
"title": "Bound the static-argument indices of each bootstrap method",
39
+
"plainSummary": "Each bootstrap method carries a list of constant pool indices for its arguments. Nothing checks those point at real pool entries.",
40
+
"userBenefit": "The same honesty this round bought for the bootstrap method index, applied to its arguments: a file naming an argument that does not exist is broken, not unsupported.",
41
+
"why": "BootstrapMethod.arguments is deliberately kept as raw u16 indices (see the doc comment in attribute.rs) because resolving them would turn every lambda-carrying class from unsupported back into corrupt. Bounding them is not resolving them: checking that an index is present in the pool costs nothing semantic and closes the same class of lie.",
42
+
"tradeoff": "Must not drift into resolution. The attribute.rs comment explains at length why resolving is a regression; a bounds check has to stay a bounds check, and a future reader may not see the difference.",
0 commit comments