From 9adc017cf5b8cf87ffe07497737c3409e452ba47 Mon Sep 17 00:00:00 2001 From: ASDAlexander77 Date: Sun, 26 Jul 2026 14:36:15 +0100 Subject: [PATCH] =?UTF-8?q?Close=20out=20=C2=A75.3=20(RTTI)=20and=20=C2=A7?= =?UTF-8?q?5.4's=20remaining=20stray=20lines=20of=20the=20not-implemented?= =?UTF-8?q?=20audit?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes a real, reachable crash in extendsType() for conditional-type extends checks against an unnamed tuple element (e.g. `T extends [number, string]`), using a positional field-lookup fallback instead of the previous by-name-only stub. Traces and closes the RTTI TypeSwitch fallbacks (§5.3): the Windows-side sites are confirmed dead by caller trace (only 2 ThrowOp creation sites in the whole codebase, both already gated by a graceful MLIRGen-time check) and hardened for consistency. The Linux side has one genuine bug - an int64-width asymmetry between two setType() overloads that would let `catch (e: i64)` pass the frontend gate and crash at lowering - fixed, though not execution-verified since no Linux/WSL build exists in this environment. Also hardens the remaining §5.4 stray lines in MLIRTypeHelper.h (getFields, getAttributeType, getFieldIndexByFieldName, getFieldInfoByIndex) to fail gracefully instead of crashing, matching the rest of this audit's convention. Verified: ctest -C Debug -j8 -> 829/829, no regressions. Co-Authored-By: Claude Sonnet 5 --- tslang/docs/not-implemented-audit.md | 227 +++++++++++++++--- .../LowerToLLVM/LLVMRTTIHelperVCLinux.h | 6 +- .../LowerToLLVM/LLVMRTTIHelperVCWin32.h | 10 +- .../TypeScript/MLIRLogic/MLIRRTTIHelperVC.h | 4 +- .../MLIRLogic/MLIRRTTIHelperVCLinux.h | 41 +++- .../MLIRLogic/MLIRRTTIHelperVCWin32.h | 11 +- .../TypeScript/MLIRLogic/MLIRTypeHelper.h | 75 +++--- 7 files changed, 280 insertions(+), 94 deletions(-) diff --git a/tslang/docs/not-implemented-audit.md b/tslang/docs/not-implemented-audit.md index c828c3111..82642be7c 100644 --- a/tslang/docs/not-implemented-audit.md +++ b/tslang/docs/not-implemented-audit.md @@ -1,23 +1,27 @@ # `llvm_unreachable("not implemented")` audit -Status: **§5.1 and §5.2 are now both fully closed; only §5.3 (RTTI, ~19 -sites, lowest priority) and a handful of stray `MLIRTypeHelper.h` lines -(§5.4) remain uninvestigated** — written as a roadmap for continuing this -audit, not a claim that the sweep is complete (§5.2's generic fallbacks -were themselves only a guess at what's left; more may turn up by re-grepping -after this many edits). Triggered by a user request to review every "not -implemented" marker in the codebase and see which ones can be implemented. -Second pass (§4.3-4.5) worked through this document's own §6 priority list -while waiting on the first pass's PR to merge. Third pass (§4.6-4.8) closed -out §5.4's `MLIRTypeHelper.h` `funcRef` family after that PR merged. Fourth -pass (§4.9) closed out `MLIRGenCast.cpp`'s two `TypeOf` sites, the last item -left from the original §5.1 named/specific list. Fifth pass (§4.10) started -the `MLIRGenImpl.h` cluster (§5.1's last remaining block), closing 4 of its -sites. Sixth pass (§4.11) closed 3 more sites in the same cluster, including -two real, easily-reachable `import X = ...` crashes. Seventh pass (§4.12) -closed the rest of §5.1: `MLIRGenImpl.h`'s last 2 sites, -`MLIRGenInterfaces.cpp`'s remaining 2, the entire `MLIRGenTypes.cpp` cluster -(10 sites), and `LLVMCodeHelper.h:452` - plus 2 bonus fixes found along the +Status: **§5.1, §5.2, §5.3, and §5.4 are all now fully closed.** What +remains: `MLIRTypeHelper.h:410/420` (the only genuinely un-investigated +site with a known location left in this document), the Linux RTTI +execution-verification gap (fixes applied and compile-verified, not +run-verified - no Linux/WSL build stood up this session), and 2 bugs +found-but-out-of-scope (§6 item 9). This is not a claim that the sweep is +100% exhaustive (§5.2's generic fallbacks were themselves only a guess at +what's left; a fresh repo-wide grep might turn up more than this document's +own inventory ever included - see §7). Triggered by a user request to +review every "not implemented" marker in the codebase and see which ones +can be implemented. Second pass (§4.3-4.5) worked through this document's +own §6 priority list while waiting on the first pass's PR to merge. Third +pass (§4.6-4.8) closed out §5.4's `MLIRTypeHelper.h` `funcRef` family after +that PR merged. Fourth pass (§4.9) closed out `MLIRGenCast.cpp`'s two +`TypeOf` sites, the last item left from the original §5.1 named/specific +list. Fifth pass (§4.10) started the `MLIRGenImpl.h` cluster (§5.1's last +remaining block), closing 4 of its sites. Sixth pass (§4.11) closed 3 more +sites in the same cluster, including two real, easily-reachable +`import X = ...` crashes. Seventh pass (§4.12) closed the rest of §5.1: +`MLIRGenImpl.h`'s last 2 sites, `MLIRGenInterfaces.cpp`'s remaining 2, the +entire `MLIRGenTypes.cpp` cluster (10 sites), and `LLVMCodeHelper.h:452` - +plus 2 bonus fixes found along the way that weren't in the original grep (a `return nullptr;`-as-`std::string` UB crash, and the `MLIRGenImpl.h:7907` object-literal twin this doc had left un-patched after calling it dead). Eighth pass (§4.13) closed all of §5.2 - @@ -34,7 +38,11 @@ scope - both turned out to share one root cause in `TupleFieldName()` by tracing code after a live debugger proved unable to catch either crash (a plain `assert()`/`abort()` raises no Win32 exception for ProcDump to see, and live-attaching WinDbg made the same assert pop a blocking GUI -dialog instead, since `IsDebuggerPresent()` becomes true). +dialog instead, since `IsDebuggerPresent()` becomes true). Tenth pass +(§4.15) closed §5.3 (RTTI) and the remaining §5.4 stray lines - see §4.15 +for the full writeup, including the one real bug found (a Linux-only +int64-width asymmetry between two `setType` overloads) and the honest +caveat about it not being execution-verified. ## 1. Scope and method @@ -1021,6 +1029,142 @@ Verified: both original repros give a clean diagnostic instead of crashing `"a binding pattern cannot be used as a field name"` for fix 2), plus the full suite: `ctest -C Debug -j8` → **829/829, no regressions**. +### 4.15 Tenth pass — closes §5.3 (RTTI) and §5.4's remaining stray `MLIRTypeHelper.h` lines + +Started with the stray lines first (cheap, same file already open from prior +passes), then moved to §5.3 (RTTI), the doc's own last untriaged pool. + +**`MLIRTypeHelper.h` strays**: + +- `getAttributeType` (was :2109) - `Default` for a field-id attribute that's + neither `StringAttr`/`FloatAttr`/`IntegerAttr`/`TypedAttr`. Two `.ts`-level + repro attempts (numeric interface keys `interface X { 1: string }` used via + `keyof`; a computed boolean property key) both resolved cleanly without + reaching this branch - field ids in this compiler are apparently always one + of the four handled kinds. Left **unconfirmed** (not proven dead, no + reachable trigger found either) but hardened anyway: returns + `UnknownType` instead of crashing, mirroring the function's own `!attr` + branch immediately above it. +- `getFields`'s final `Default` (was :2258) - every real caller (`grep`'d + across the whole tree) already calls it via `mlir::succeeded`/`mlir::failed`, + so the function's contract already assumes failure is a normal, handled + outcome; the `noError=true` parameter already returns `failure()` for this + exact branch, so making the `noError=false` path do the same (instead of + crashing) is a zero-risk consistency fix, not a behavior change for any + caller that checks the result. +- `getFieldIndexByFieldName`/`getFieldInfoByIndex` (was :2291/:2308) - + **confirmed dead**: their only callers anywhere in the tree + (`MLIRGenInterfaces.cpp`, vtable-patching logic) always construct the + argument as `mlir_ts::TupleType` first (via `TupleType::get(...)` or a + `cast(...).getElementType()` that's itself always a `TupleType`), + never any other shape. Hardened anyway (return `-1` / default `FieldInfo`) + for consistency with sibling functions in the same file. +- `extendsType`'s two `// TODO: get it by function` sites (was :2685/:2709, + the `TupleType`/`ConstTupleType` branches of a tuple-shaped `extends` + target with an **unnamed** field, e.g. `T extends [number, string]`) - + **confirmed real, reachable crash**, via: + + ```ts + type IsPair = T extends [number, string] ? true : false; + let a: IsPair<{ 0: number, 1: string }> = true; + ``` + + `UNREACHABLE executed at MLIRTypeHelper.h:2686!`. Root cause: the + field-matching loop only knew how to look up `srcType`'s corresponding + field **by name** (`item.id`); a plain positional tuple element (`number`, + `string` with no `x:`/`y:` label) has `item.id == nullptr`, and the branch + for that case was still a stub. Fixed by falling back to a **positional** + lookup: collect `srcType`'s fields once via the existing `getFields()` + dispatcher (which already supports far more shapes than just + tuple/const-tuple - interfaces, classes, arrays, strings, optionals - so + this also generalizes past the tuple-vs-tuple case in the original repro), + then index into that list by the unnamed field's position. Applied + identically to both the `TupleType` and `ConstTupleType` branches (same + TODO, same bug, same fix - the const-tuple sibling wasn't independently + reproduced but is structurally identical code). + +**§5.3 (RTTI)**: the doc flagged this as hardest-to-reach ("deep in a code +path that's hard to reach without a specific class-hierarchy-plus-exception +scenario") and lowest priority. Traced instead of guessed-and-reproed, since +the whole cluster is generic `TypeSwitch::Default`/width-mismatch fallbacks +with no named trigger: + +- **Windows side** (`LLVMRTTIHelperVCWin32.h:141,156,169`, + `MLIRRTTIHelperVCWin32.h:216,226,241`, plus `MLIRRTTIHelperVC.h:108`'s + `getLandingPadType` fallback) - **confirmed dead** by caller trace. There + are exactly **two** places in the entire codebase that ever create a + `mlir_ts::ThrowOp`: the user-facing `throw` statement + (`MLIRGenStatements.cpp`) and a mismatch-rethrow synthesized during + `TryOp` lowering (`LowerToAffineLoops.cpp:1766`) - and that second one is + gated to `!compileOptions.isWindows` (Windows's own `__CxxFrameHandler3` + matches catch types at the OS level, so this compiler only needs the + synthetic rethrow on non-Windows targets). Both the `throw` and + `catch (e: T)` code paths already call a **graceful** twin of these + functions at MLIRGen time (`setType(type, resolveClassInfo)` / + `setRTTIForType`, which cleanly rejects unsupported types with + `"Not supported type in throw"`/`"...in catch"` instead of crashing) before + any TS-dialect value carrying that type can reach the lowering-stage + `llvm_unreachable` versions - and the two versions accept exactly the same + type set. Verified empirically too, not just by reading: `throw true`, + `throw` a 64-bit int, `throw`/`catch` a class with inheritance, and + `throw` an enum value all either get the clean MLIRGen-time error or + compile+run successfully; none reach the crash sites. Hardened anyway + (graceful `false`/no-op fallback instead of crash) for consistency and to + fully close the item rather than leave it an asterisk. +- **Linux side** (`LLVMRTTIHelperVCLinux.h:113,128,142`, + `MLIRRTTIHelperVCLinux.h:146,161,182,202,217,230`) - same dead-by-caller- + trace reasoning applies to the `Default` branches (the synthetic-rethrow + path here is real, since it isn't Windows-gated, but it already produces + `mlir_ts::NullType`, which this file's `LLVMRTTIHelperVCLinux::setType` was + already explicitly handling via a dedicated `.Case` + before this pass touched it - not a crash). **But** found one genuine, + well-evidenced real bug via a different route - not a repro, since no + Linux/WSL build exists in this session to execute one (see below): the + file has **two** `setType` overloads, one taking a `resolveClassInfo` + callback (used by the MLIRGen-time graceful gate) and one without (used by + `LowerToAffineLoops.cpp`'s catch-arg-type lowering). The + `resolveClassInfo` overload already special-cased 64-bit integers + (`setI64AsCatchType()`) alongside 32-bit; the other overload only had the + 32-bit case, falling through to `llvm_unreachable` for 64-bit ints. Since + MLIRGen's graceful gate (which uses the `resolveClassInfo` overload) + already accepts a `catch (e: i64)`/`throw` of a 64-bit int on Linux, that + construct would reach the *other* overload during lowering and crash - + a genuine asymmetry between two copies of what should be the same type + list. Fixed by adding the matching `else if (width == 64)` case; also + hardened the remaining `Default`/width-mismatch branches in both + overloads for consistency. **`MLIRRTTIHelperVCLinux.h`'s + `getClassInfoName` `default:` case (the doc's stray `:399`, actually at + :418 by the time this pass reached it - the file had drifted since the + doc was last updated)** - confirmed dead the same way: its 4th enum value + (`TypeInfo::Value`) is filtered out by every caller's own switch before + ever reaching this function (routed to `typeInfoValue()` instead of + `typeInfoClass()`/`getClassInfoName()`); hardened anyway. + **Honesty note**: none of the Linux-side code was execution-verified in + this session - WSL Ubuntu *is* available in this environment (confirmed + via `wsl --list`), but no Linux build of this project exists yet, and + standing one up (LLVM/MLIR from scratch) was judged out of proportion for + 4 lines whose trigger condition is already well-understood via static + trace and cross-checked against the file's own graceful-gate sibling. The + Windows build **does** compile both the Win32 and Linux RTTI classes + unconditionally (selected at runtime via `compileOptions.isWindows`, not + `#ifdef`), so all of these edits at least compile cleanly and were + exercised by the full Windows test suite - just not through an actual + Linux/`__gxx_personality_v0` exception unwind. + One incidental fix along the way: `LLVMRTTIHelperVCWin32.h` needed a + local `#define DEBUG_TYPE "llvm"` / `#undef` bracket added (matching the + pattern already used by `LLVMRTTIHelperVCLinux.h` and `MLIRTypeHelper.h`) + since it had never used `LLVM_DEBUG` before this pass and several of its + including `.cpp` files don't define `DEBUG_TYPE` themselves. + +Verified: the `extendsType` repro above now compiles and runs cleanly +instead of crashing (plus a const-tuple variant of the same repro, which +resolves - to `false`, arguably a separate correctness question about +const-tuple-vs-tuple structural matching, out of this audit's crash-fixing +scope, same as other precedents in §7); `throw`/`catch` repros across bool, +64-bit int, enum, and class-with-inheritance all still compile+run +correctly on Windows with no behavior change; full suite +`ctest -C Debug -j8` → **829/829, no regressions**. + ## 5. Inventory of remaining markers (untested this pass) Grouped by file. "Shape" is a guess from reading the surrounding code, not a @@ -1074,11 +1218,17 @@ This was this doc's own inventory of §5.2, not an exhaustive repo grep run fresh - a new sweep might turn up more generic fallbacks this list never included (see §7's caveat). -### 5.3 RTTI type-switch fallbacks (Windows/Linux variants — the Linux ones can't be exercised from this Windows dev box without a Linux/WSL build) +### 5.3 RTTI type-switch fallbacks — CLOSED this pass (tenth), see §4.15 `LLVMRTTIHelperVCWin32.h:141,156,169` · `LLVMRTTIHelperVCLinux.h:113,128,142` · `MLIRRTTIHelperVC.h:108` · `MLIRRTTIHelperVCWin32.h:216,226,241` · -`MLIRRTTIHelperVCLinux.h:146,161,182,202,217,230,399`. +`MLIRRTTIHelperVCLinux.h:146,161,182,202,217,230,399` (the `:399` had drifted +to `:418` by the time this pass reached it). Windows side confirmed dead by +caller trace (only 2 `ThrowOp` creation sites in the whole codebase, both +already gated by a graceful MLIRGen-time twin check); Linux side mostly the +same, plus one genuine real bug (an int64-width asymmetry between two +`setType` overloads) fixed but not execution-verified - no Linux/WSL build +exists in this session. See §4.15 for the full writeup. ### 5.4 `MLIRTypeHelper.h`'s `funcRef` family — CLOSED this pass, see §4.6-4.8 @@ -1095,10 +1245,10 @@ non-function `T`; all six are now fixed. See §4.6-4.8 for the full writeup. Note `:410` and `:420`, also swept up in this line-number cluster originally, turned out to be an unrelated numeric-attribute-conversion helper (constant folding between int/float attrs), not part of the `funcRef` family - still -unread, left in the general backlog. `:2108, :2256-2257, :2290, :2307, -:2685, :2709` are likewise still unread and not confirmed to be `funcRef`- -family sites; worth a fresh grep + read next time this file comes up rather -than assuming they're covered by this pass's fix. +unread, left in the general backlog (a fresh repro/trace attempt would be +needed to triage it, same as any other never-investigated site in this +doc). `:2108, :2256-2257, :2290, :2307, :2685, :2709` (also confirmed not +`funcRef`-family) are now all resolved too - see §4.15 (tenth pass). **Attempted this pass** (before switching to the call-site-trace approach that actually worked): two plausible `.ts`-level triggers — a callback @@ -1146,14 +1296,21 @@ bug (the built-in utility types); tracing real callers is what worked. destructuring-assignment gaps) plus one genuine missing `Case` (`MLIRTypeIterator.h`'s `NamespaceType`) found by type-list diffing rather than a repro. 829/829, no regressions, checked after every file. -7. **Next up**: §5.3 (RTTI) — the only remaining untriaged pool, and the - lowest priority in this document from the start: the Linux variants need - a WSL/Linux build to exercise at all, and even the Windows ones are deep - in a code path (RTTI/exception typeinfo generation) that's hard to reach - without a specific class-hierarchy-plus-exception scenario. -8. The stray `MLIRTypeHelper.h:410/420/2108/2256-2257/2290/2307/2685/2709` - sites (§5.4) — confirmed not part of the `funcRef` family but never - actually read; cheap to fold into whichever pass next touches this file. +7. ~~§5.3 (RTTI)~~ — **done, §5.3 is now fully closed** (§4.15, tenth pass): + Windows side confirmed dead by caller trace (verified empirically too); + Linux side fixed a real int64-width asymmetry bug between two `setType` + overloads, plus hardened the rest for consistency - not + execution-verified (no Linux/WSL build stood up this session, judged out + of proportion for 4 lines already well-understood via static trace). +8. ~~The stray `MLIRTypeHelper.h:2108/2256-2257/2290/2307/2685/2709` + sites~~ — **done this pass** (§4.15): one confirmed real crash + (`extendsType`'s unnamed-tuple-field lookup, fixed with a positional + fallback), two confirmed dead (`getFieldIndexByFieldName`/ + `getFieldInfoByIndex`, hardened for consistency), one left unconfirmed + but hardened (`getAttributeType`), one zero-risk consistency fix + (`getFields`). `MLIRTypeHelper.h:410/420` remain unread (confirmed + unrelated to the `funcRef` family, still not triaged - the only item + left in this whole document with a known, un-investigated location). 9. Two bugs discovered but *not* fixed this pass, out of this document's "not implemented" scope but worth a dedicated look: (a) an LLVM `Casting.h` `dyn_cast on a non-existent value` assertion, reachable via @@ -1162,6 +1319,10 @@ bug (the built-in utility types); tracing real callers is what worked. delete-crash reproduced exactly once and then never again across several retries with the identical source - if it resurfaces, start from §4.13's honest note about it rather than assuming it's fixed. +10. `MLIRTypeHelper.h:410/420` (see item 8) - the last genuinely + un-investigated site with a known location in this entire document. + Everything else remaining is either the Linux RTTI execution- + verification gap (item 7) or the two out-of-scope bugs (item 9). ## 7. Non-goals / out of scope diff --git a/tslang/include/TypeScript/LowerToLLVM/LLVMRTTIHelperVCLinux.h b/tslang/include/TypeScript/LowerToLLVM/LLVMRTTIHelperVCLinux.h index 8948b554b..a5820ff42 100644 --- a/tslang/include/TypeScript/LowerToLLVM/LLVMRTTIHelperVCLinux.h +++ b/tslang/include/TypeScript/LowerToLLVM/LLVMRTTIHelperVCLinux.h @@ -110,7 +110,7 @@ class LLVMRTTIHelperVCLinux } else { - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch integer width: " << intType << "\n";); } }) .Case([&](auto floatType) { @@ -125,7 +125,7 @@ class LLVMRTTIHelperVCLinux } else { - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch float width: " << floatType << "\n";); } }) .Case([&](auto numberType) { @@ -139,7 +139,7 @@ class LLVMRTTIHelperVCLinux .Case([&](auto classType) { setClassTypeAsCatchType(classType.getName().getValue()); }) .Case([&](auto anyType) { setI8PtrAsCatchType(); }) .Case([&](auto nullType) { rethrow = true; }) - .Default([&](auto type) { llvm_unreachable("not implemented"); }); + .Default([&](auto type) { LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch type: " << type << "\n";); }); } bool hasType() diff --git a/tslang/include/TypeScript/LowerToLLVM/LLVMRTTIHelperVCWin32.h b/tslang/include/TypeScript/LowerToLLVM/LLVMRTTIHelperVCWin32.h index e116dd355..82035e0aa 100644 --- a/tslang/include/TypeScript/LowerToLLVM/LLVMRTTIHelperVCWin32.h +++ b/tslang/include/TypeScript/LowerToLLVM/LLVMRTTIHelperVCWin32.h @@ -16,6 +16,8 @@ #include +#define DEBUG_TYPE "llvm" + using namespace mlir; namespace mlir_ts = mlir::typescript; @@ -138,7 +140,7 @@ class LLVMRTTIHelperVCWin32 } else { - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch integer width: " << intType << "\n";); } }) .Case([&](auto floatType) { @@ -153,7 +155,7 @@ class LLVMRTTIHelperVCWin32 } else { - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch float width: " << floatType << "\n";); } }) .Case([&](auto numberType) { @@ -166,7 +168,7 @@ class LLVMRTTIHelperVCWin32 .Case([&](auto stringType) { setStringTypeAsCatchType(); }) .Case([&](auto classType) { setClassTypeAsCatchType(classType.getName().getValue()); }) .Case([&](auto anyType) { setI8PtrAsCatchType(); }) - .Default([&](auto type) { llvm_unreachable("not implemented"); }); + .Default([&](auto type) { LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch type: " << type << "\n";); }); } void setRTTIForType(mlir::Location loc, mlir::Type type) @@ -510,4 +512,6 @@ class LLVMRTTIHelperVCWin32 }; } // namespace typescript +#undef DEBUG_TYPE + #endif // MLIR_TYPESCRIPT_LOWERTOLLVMLOGIC_LLVMRTTIHELPERVCWIN32_H_ diff --git a/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVC.h b/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVC.h index ab70de8a1..2db3332c8 100644 --- a/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVC.h +++ b/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVC.h @@ -105,8 +105,8 @@ class MLIRRTTIHelperVC return rttiLinux.getLandingPadType(); } - llvm_unreachable("not implemented"); - } + return mlir_ts::TupleType(); + } }; } // namespace typescript diff --git a/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVCLinux.h b/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVCLinux.h index 03c8bb53a..b16c997e6 100644 --- a/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVCLinux.h +++ b/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVCLinux.h @@ -130,6 +130,7 @@ class MLIRRTTIHelperVCLinux return false; } + auto result = true; llvm::TypeSwitch(mth.stripLiteralType(type)) .Case([&](auto intType) { auto width = intType.getIntOrFloatBitWidth(); @@ -143,7 +144,8 @@ class MLIRRTTIHelperVCLinux } else { - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch integer width: " << intType << "\n";); + result = false; } }) .Case([&](auto floatType) { @@ -158,7 +160,8 @@ class MLIRRTTIHelperVCLinux } else { - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch float width: " << floatType << "\n";); + result = false; } }) .Case([&](auto numberType) { @@ -179,9 +182,12 @@ class MLIRRTTIHelperVCLinux setClassTypeAsCatchType(classAndBases); }) .Case([&](auto anyType) { setI8PtrAsCatchType(); }) - .Default([&](auto type) { llvm_unreachable("not implemented"); }); + .Default([&](auto type) { + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch type: " << type << "\n";); + result = false; + }); - return true; + return result; } bool setType(mlir::Type type) @@ -191,15 +197,24 @@ class MLIRRTTIHelperVCLinux return false; } + auto result = true; llvm::TypeSwitch(mth.stripLiteralType(type)) .Case([&](auto intType) { - if (intType.getIntOrFloatBitWidth() == 32) + auto width = intType.getIntOrFloatBitWidth(); + if (width == 32) { setI32AsCatchType(); } + else if (width == 64) + { + // keep in sync with the resolveClassInfo overload above, which + // already supports this width. + setI64AsCatchType(); + } else { - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch integer width: " << intType << "\n";); + result = false; } }) .Case([&](auto floatType) { @@ -214,7 +229,8 @@ class MLIRRTTIHelperVCLinux } else { - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch float width: " << floatType << "\n";); + result = false; } }) .Case([&](auto numberType) { @@ -227,9 +243,12 @@ class MLIRRTTIHelperVCLinux .Case([&](auto stringType) { setStringTypeAsCatchType(); }) .Case([&](auto classType) { setClassTypeAsCatchType(classType.getName().getValue()); }) .Case([&](auto anyType) { setI8PtrAsCatchType(); }) - .Default([&](auto type) { llvm_unreachable("not implemented"); }); + .Default([&](auto type) { + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch type: " << type << "\n";); + result = false; + }); - return true; + return result; } void seekLast(mlir::Block *block) @@ -396,7 +415,9 @@ class MLIRRTTIHelperVCLinux case TypeInfo::ClassTypeInfo: return linux::ClassType::classTypeInfoName; default: - llvm_unreachable("not implemented"); + // only reached for TypeInfo::Value, which every caller's own switch + // already routes to typeInfoValue() instead of typeInfoClass()/here. + return linux::ClassType::classTypeInfoName; } } diff --git a/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVCWin32.h b/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVCWin32.h index 8168b7a81..aeecb7973 100644 --- a/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVCWin32.h +++ b/tslang/include/TypeScript/MLIRLogic/MLIRRTTIHelperVCWin32.h @@ -205,6 +205,7 @@ class MLIRRTTIHelperVCWin32 return false; } + auto result = true; llvm::TypeSwitch(mth.stripLiteralType(type)) .Case([&](auto intType) { if (intType.getIntOrFloatBitWidth() == 32) @@ -213,7 +214,7 @@ class MLIRRTTIHelperVCWin32 } else { - llvm_unreachable("not implemented"); + result = false; } }) .Case([&](auto floatType) { @@ -223,7 +224,7 @@ class MLIRRTTIHelperVCWin32 } else { - llvm_unreachable("not implemented"); + result = false; } }) .Case([&](auto numberType) { @@ -237,11 +238,11 @@ class MLIRRTTIHelperVCWin32 .Case([&](auto classType) { setClassTypeAsCatchType(classType.getName().getValue()); }) .Case([&](auto anyType) { setI8PtrAsCatchType(); }) .Default([&](auto type) { - LLVM_DEBUG(llvm::dbgs() << "...throw type: " << type << "\n";); - llvm_unreachable("not implemented"); + LLVM_DEBUG(llvm::dbgs() << "...unsupported throw/catch type: " << type << "\n";); + result = false; }); - return true; + return result; } template diff --git a/tslang/include/TypeScript/MLIRLogic/MLIRTypeHelper.h b/tslang/include/TypeScript/MLIRLogic/MLIRTypeHelper.h index 79d228e2a..00c00036a 100644 --- a/tslang/include/TypeScript/MLIRLogic/MLIRTypeHelper.h +++ b/tslang/include/TypeScript/MLIRLogic/MLIRTypeHelper.h @@ -2106,7 +2106,7 @@ class MLIRTypeHelper return typedAttr.getType(); } - llvm_unreachable("not implemented"); + return mlir_ts::UnknownType::get(context); } mlir::Type getFieldNames(mlir::Type srcType) @@ -2255,7 +2255,7 @@ class MLIRTypeHelper } LLVM_DEBUG(llvm::dbgs() << "!! getFields is not implemented for type [" << srcType << "]\n";); - llvm_unreachable("not implemented"); + return mlir::failure(); } mlir::LogicalResult getFieldTypes(mlir::Type srcType, llvm::SmallVector &destTupleTypes) @@ -2286,9 +2286,9 @@ class MLIRTypeHelper if (auto tupleType = dyn_cast(srcType)) { return tupleType.getIndex(fieldName); - } + } - llvm_unreachable("not implemented"); + return -1; } mlir::typescript::FieldInfo getFieldInfoByIndex(mlir::Type srcType, int index) @@ -2298,14 +2298,14 @@ class MLIRTypeHelper if (auto constTupleType = dyn_cast(srcType)) { return constTupleType.getFieldInfo(index); - } - + } + if (auto tupleType = dyn_cast(srcType)) { return tupleType.getFieldInfo(index); - } + } - llvm_unreachable("not implemented"); + return mlir::typescript::FieldInfo(); } mlir::Type getFieldTypeByFieldName(mlir::Type srcType, mlir::Attribute fieldName) @@ -2668,23 +2668,23 @@ class MLIRTypeHelper if (auto tupleType = dyn_cast(extendType)) { auto falseResult = ExtendsResult::False; - auto pred = [&](auto &item) { - if (item.id) - { - auto fieldType = getFieldTypeByFieldName(srcType, item.id); - auto fieldExtResult = extendsType(location, fieldType, item.type, typeParamsWithArgs); - if (fieldExtResult == ExtendsResult::Never) - { - falseResult = fieldExtResult; - } - - return isTrue(fieldExtResult); - } - else + llvm::SmallVector srcFields; + auto hasSrcFields = mlir::succeeded(getFields(srcType, srcFields, true)); + auto index = -1; + auto pred = [&](auto &item) { + index++; + // unnamed (positional) tuple element - e.g. `T extends [number, string]` - + // match srcType's field at the same position rather than by name. + auto fieldType = item.id + ? getFieldTypeByFieldName(srcType, item.id) + : (hasSrcFields && (size_t)index < srcFields.size() ? srcFields[index].type : mlir::Type()); + auto fieldExtResult = extendsType(location, fieldType, item.type, typeParamsWithArgs); + if (fieldExtResult == ExtendsResult::Never) { - // TODO: get it by function - llvm_unreachable("not implemented"); + falseResult = fieldExtResult; } + + return isTrue(fieldExtResult); }; return std::all_of(tupleType.getFields().begin(), tupleType.getFields().end(), pred) ? ExtendsResult::True : falseResult; } @@ -2692,23 +2692,22 @@ class MLIRTypeHelper if (auto constTupleType = dyn_cast(extendType)) { auto falseResult = ExtendsResult::False; - auto pred = [&](auto &item) { - if (item.id) + llvm::SmallVector srcFields; + auto hasSrcFields = mlir::succeeded(getFields(srcType, srcFields, true)); + auto index = -1; + auto pred = [&](auto &item) { + index++; + // unnamed (positional) tuple element - same as the TupleType case above. + auto fieldType = item.id + ? getFieldTypeByFieldName(srcType, item.id) + : (hasSrcFields && (size_t)index < srcFields.size() ? srcFields[index].type : mlir::Type()); + auto fieldExtResult = extendsType(location, fieldType, item.type, typeParamsWithArgs); + if (fieldExtResult == ExtendsResult::Never) { - auto fieldType = getFieldTypeByFieldName(srcType, item.id); - auto fieldExtResult = extendsType(location, fieldType, item.type, typeParamsWithArgs); - if (fieldExtResult == ExtendsResult::Never) - { - falseResult = fieldExtResult; - } - - return isTrue(fieldExtResult); - } - else - { - // TODO: get it by function - llvm_unreachable("not implemented"); + falseResult = fieldExtResult; } + + return isTrue(fieldExtResult); }; return std::all_of(constTupleType.getFields().begin(), constTupleType.getFields().end(), pred) ? ExtendsResult::True : falseResult; }