summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* + show the effectsOf pragma (if present) of procs in nimsuggest hints… ↵Nikolay Nikolov2024-09-091-0/+10
| | | | | (#23305) … and compiler messages
* open new scope for const values (#24084)metagn2024-09-095-0/+31
| | | | | | | | | | | | | fixes #5395 Previously values of `const` statements used the same scope as the `const` statement itself, meaning variables could be declared inside them and referred to in other statements in the same block. Now each `const` value opens its own scope, so any variable declared in the value of a constant can only be accessed for that constant. We could change this to open a new scope for the `const` *section* rather than each constant, so the variables can be used in other constants, but I'm not sure if this is sound.
* fixes #21353; fixes default closure in the VM (#24070)ringabout2024-09-093-23/+27
| | | | | | | | | | | | | fixes #21353 ```nim result = newNodeIT(nkTupleConstr, info, t) result.add(newNodeIT(nkNilLit, info, t)) result.add(newNodeIT(nkNilLit, info, t)) ``` The old implementation uses `t` which is the type of the closure function as its type. It is not correct and generates ((nil, nil), (nil, nil)) for `default(closures)`. This PR creates `(tyPointer, tyPointer)` for fake closure types just like what cctypes do.
* fix regression with generic params in static type (#24075)metagn2024-09-092-0/+13
| | | | | | | | | | | | | | | | | | | | | | | Caught in https://github.com/metagn/applicates, I'm not sure which commit causes this but it's also in the 2.0 branch (but not 2.0.2), so it's not any recent PRs. If a proc has a static parameter with type `static Foo[T]`, then another parameter with type `static Bar[T, U]`, the generic instantiation for `Bar` doesn't match `U` which has type `tyGenericParam`, but matches `T` since it has type `tyTypeDesc`. The reason is that `concreteType` returns the type itself for `tyTypeDesc` if `c.isNoCall` (i.e. matching a generic invocation), but returns `nil` for `tyGenericParam`. I'm guessing `tyGenericParam` is received here because of #22618, but that doesn't explain why `T` is still `tyTypeDesc`. I'm not sure. Regardless, we can just copy the behavior for `tyTypeDesc` to `tyGenericParam` and also return the type itself when `c.isNoCall`. This feels like it defeats the purpose of `concreteType` but the way it's used doesn't make sense without it (generic param can't match another generic param?). Alternatively we could loosen the `if concrete == nil: return isNone` checks in some places for specific conditions, whether `c.isNoCall` or `c.inGenericContext == 0` (though this would need #24005).
* show symchoices as ambiguous in overload type mismatches (#24077)metagn2024-09-099-13/+97
| | | | | | | | fixes #23397 All ambiguous symbols generate symchoices for call arguments since #23123. So, if a type mismatch receives a symchoice node for an argument, we now treat it as an ambiguous identifier and list the ambiguous symbols in the error message.
* fix int32's that should be uint32 on BSD & OSX (#24078)metagn2024-09-093-10/+18
| | | | | | | | | fixes #24076 As described in #24076, misannotating these types causes codegen errors. Sources for the types are https://github.com/openbsd/src/blob/master/sys for BSD and https://opensource.apple.com/source/Libinfo/Libinfo-391/ and [_types.h](https://opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/_types.h.auto.html) for OSX.
* Fix CSS for `number-lines` code blocks (#24081)Jake Leahy2024-09-093-8/+14
| | | | | | | | | generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-02-05 08:47:47 +0000 when its a line number table - With dochack.nim, don't add a clipboard copy button for the line numbers at the side [Example page showing the changes](https://66dcde6e4a655efb70771d9a--dazzling-kitten-6c3419.netlify.app/)
* fix CI, sem whole `when` stmts as generic stmt (#24072)metagn2024-09-082-3/+17
| | | | | | | | | | | | | | fixes CI, refs #24066, refs #24065 The combination of #24065 and #24066 caused a CI failure where a `when` branch that was never compiled gave an undeclared identifier error. This is because the `when` branch was being semchecked with `semGenericStmt` without `withinMixin`, which is the flag `semgnrc` normally gives to `when` branch bodies. To fix this, just pass the whole `when` stmt to `semGenericStmt` rather than the individual blocks. The alternative would be to just replace the calls to `semGenericStmt` with a new proc that does the same thing, just with the flags `{withinMixin}`.
* Fix ioselectors_kqueue raising wrong exceptions (#24079)bptato2024-09-082-3/+26
| | | | | | | | | | | | | | | | | kqueue will remove pipes automatically if their read end is closed. Unfortunately this means that trying to unregister it (which is necessary to clean up resources & for consistency with other ioselectors implementations) will set an ENOENT error, which currently raises an exception. (ETA: in other words, it is currently impossible to call unregister on a pipe fd without potentially getting the selector into an invalid state on platforms with kqueue.) Avoid this issue by ignoring ENOENT errors returned from kqueue. (Tested on FreeBSD. I added a test case to the tioselectors file; the seemingly unrelated change is to fix a race condition that doesn't appear on Linux, so that it would run my code too.)
* fix subscript in generics, typeof, `lent` with bracket (#24067)metagn2024-09-083-0/+41
| | | | | | | | | fixes #15959 Another followup of #22029 and #24005, subscript expressions now recognize when their parameters are generic types, then generating tyFromExpr. `typeof` also now properly sets `tfNonConstExpr` to make it usable in proc signatures. `lent` with brackets like `lent[T]` is also now allowed.
* improve compiler performance on dot fields after #24005 (#24074)metagn2024-09-081-6/+3
| | | | | | | | | | | | | | | | | | | | | | | I noticed after #24005 the auto-reported boot time in PRs increased from around 8 seconds to 8.8 seconds, but I wasn't sure what could cause a performance problem that made the compiler itself compile slower, most of the changes were related to `static` which the compiler code doesn't use too often. So I figured it was unrelated. However there is still a performance problem with the changes to `tryReadingGenericParam`. If an expression like `a.b` doesn't match any of the default dot field behavior (for example, is actually a call `b(a)`), the compiler does a final check to see if `b` is a generic parameter of `a`. Since #24005, if the type of `a` is not `tyGenericInst` or an old concept type, the compiler does a full traversal of the type of `a` to see if it contains a generic type, only then checking for `c.inGenericContext > 0` to not return `nil`. This happens on *every* dot call. Instead, we now check for `c.inGenericContext > 0` first, only then checking if it contains a generic type, saving performance by virtue of `c.inGenericContext > 0` being both cheap and less commonly true. The `containsGenericType` could also be swapped out for more generic type kind checks, but I think this is incorrect even if it might pass CI.
* fix string literal assignment with different lengths on ARC (#24083)metagn2024-09-082-1/+18
| | | fixes #24080
* generate tyFromExpr for `when` in generics (#24066)metagn2024-09-064-4/+65
| | | | | | | | fixes #22342, fixes #22607 Another followup of #22029, `when` expressions in general in generic type bodies now behave like `nkRecWhen` does since #24042, leaving them as `tyFromExpr` if a condition is uncertain. The tests for the issues were originally added but left disabled in #24005.
* adapt generic default parameters to recent generics changes (#24065)metagn2024-09-069-28/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes #16700, fixes #20916, refs #24010 Fixes the instantiation issues for proc param default values encountered in #24010 by: 1. semchecking generic default param values with `inGenericContext` for #22029 and followups to apply (the bigger change in semtypes), 2. rejecting explicit generic instantiations with unresolved generic types inside `inGenericContext` (sigmatch change), 3. instantiating the default param values using `prepareNode` rather than an insufficient manual method (the bigger change in seminst). This had an important side effect of references to other parameters not working since they would be resolved as a symbol belonging to the uninstantiated original generic proc rather than the later instantiated proc. There is a more radical way to fix this which is generating ident nodes with `tyFromExpr` in specifically this context, but instead we just count them as belonging to the same proc in `hoistParamsUsedInDefault`. Other minor bugfixes: * To make the error message in t20883 make sense, we now give a "cannot instantiate" error when trying to instantiate a proc generic param with `tyFromExpr`. * Object constructors as default param values generated default values of private fields going through `evalConstExpr` more than once, but the VM doesn't mark the object fields as `nfSkipFieldChecking` which gives a "cannot access field" error. So the VM now marks object fields it generates as `nfSkipFieldChecking`. Not sure if this affects VM performance, don't see why it would. * The nkRecWhen changes in #24042 didn't cover the case where all conditions are constantly false correctly, this is fixed with a minor change. This isn't needed for this PR now but I encountered it after forgetting to `dec c.inGenericContext`.
* fixes #24053; fixes #18288; relax reorder with push/pop pragmas ↵ringabout2024-09-062-11/+19
| | | | | | | | | restrictions; no crossing push/pop barriers (#24061) fixes #24053; fixes #18288 makes push pragmas depend on each node before it and nodes after it depend on it
* proper errors for subscript overloads (#24068)metagn2024-09-067-52/+128
| | | | | | | | | | The magic `mArrGet`/`mArrPut` subscript overloads always match, so if a subscript doesn't match any other subscript overloads and isn't a regular language-handled subscript, it creates a fake overload mismatch error in `semArrGet` that doesn't have any information (gives stuff like "first mismatch at index: 0" for every single mismatch). Instead of generating the fake mismatches, we only generate the fake mismatch for `mArrGet`/`mArrPut`, and process every overload except them as a real call and get the errors from there.
* expose `rangeBase` typetrait, fix enum conversion warning (#24056)metagn2024-09-066-3/+74
| | | | | | | | | | | | | | | | refs #21682, refs #24038 The `rangeBase` typetrait added in #21682 which gives the base type of a range type is now added publicly to `typetraits`. Previously it was only privately used in `repr_v2` and in `enumutils` since #24052 (coincidentally I didn't see this until now). This is part of an effort to make range types easier to work with in generics, as mentioned in #24038. Its use combined with #24037 is also tested. The condition for the "enum to enum conversion" warning is now also restricted to conversions between different enum base types, i.e. conversion between an enum type and a range type of itself doesn't give a warning. I put this in this PR since the test gave the warning and so works as a regression test.
* fix undeclared identifier in templates in generics (#24069)metagn2024-09-062-1/+11
| | | | | | | fixes #13979 Fixes templates in generics that use identifiers that aren't defined yet, giving an early `undeclared identifier` error, by just marking template bodies as in a mixin context in `semgnrc`.
* remove unused config field: keepComments (#24063)ringabout2024-09-051-2/+0
|
* fixes #23897; Useless empty C files with arc/orc (#24064)ringabout2024-09-051-3/+0
| | | | | | | | | fixes #23897 follow up https://github.com/nim-lang/Nim/pull/21288 follow up https://github.com/nim-lang/Nim/pull/22472 Since #22472 triggers `nimTestErrorFlag` in every module that isn't empty, this PR removes unnecessary logic
* Make math.isNaN,copySign,etc available on objc (#24025)lit2024-09-051-1/+1
| | | | | | | fixes #23922 --------- Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
* remove unused nimStdlibVersion (#24060)ringabout2024-09-042-19/+1
|
* Make `$` on 0-length `MemSlice` produce Nim "" as per DMisener idea (#24015)c-blake2024-09-041-1/+1
| | | | | | | | in https://forum.nim-lang.org/t/12463 which seems reasonable enough to me. stdlib has several dozens of places doing result.setLen now, but if `experimental:strictDefs` move sot on by default and there is no easy way to locally suppress the warning we can revisit this.
* streams: implement readStr for VM, document VM limitations (#24058)metagn2024-09-043-4/+17
| | | | | | | | | | | fixes #24054 `readData` is not implemented for the VM as mentioned in the issue, but `readDataStr` is, so that is used for `readStr` instead on the VM. We could also just use it in general since it falls back to `readData` anyway but it's kept the same otherwise for now. Also where and why streams in general don't work in VM is now documented on the top level `streams` module documentation.
* document partial generics breaking changes (#24055)metagn2024-09-041-0/+13
| | | refs #24010, split from #24051
* proper error for calling nil closure in VM (#24059)metagn2024-09-043-0/+35
| | | | | | fixes #24057 Instead of crashing the compiler, the VM now gives a stacktrace if a nil closure is attempted to be called.
* fixes symbolName for range enums (#24052)ringabout2024-09-032-1/+17
|
* fixes push warnings for sempass2 (#23603)ringabout2024-09-039-37/+87
| | | ref https://forum.nim-lang.org/t/11590
* allow conversions between `var` types of range types and base types (#24037)metagn2024-09-035-22/+81
| | | | | | | | | | | | | | | | | | | | | | | refs #24032, split from #24036 Conversion from variables of range types or base types of range types to the other are now considered mutable for `var` params, similar to how distinct types are mutable when converted to their base type or vice versa. There are 2 main differences: 1. Conversions from base types to range types need to emit `nkChckRange`, which is not generated for things like tuple/object fields. 2. Range types can still correspond to different types in the backend when nested in other types, such as `set[range[3..5]]` vs `set[range[0..5]]`. Since the convertibility check for `var` params and a check whether to emit a no-op for `nkConv` (and now also `nkChckRange`) so that the output is still addressable both use `sameType`, we accomplish this by adding a new flag to `sameType` that ignores range types, but only when they're not nested in other types. The implementation for this might be flawed, I didn't include children of some metatypes as "nested in other types", but stuff like `tyGenericInst` params are respected.
* fully disable static paramTypesMatch for tyFromExpr in generics (#24049)metagn2024-09-032-5/+12
| | | | | | | | | | | | fixes #24044 When matching a `tyFromExpr` against a `static` generic parameter, `paramTypesMatch` tries to evaluate it as a constant expression, which causes a segfault in the case of #24044. In #24005 a consequence of the same behavior was an issue where `nkStaticExpr` was created for `tyFromExpr` which made it not instantiate, so only the generation of `nkStaticExpr` was disabled. Instead we now just completely ignore `tyFromExpr` matching a `static` generic parameter in generic contexts and keep it untouched.
* fix segfault with gensym node instantiation (#24050)metagn2024-09-032-1/+31
| | | | | | | | | | | fixes #24048 Generic lambdas get instantiated via `replaceTypesInBody` which calls `replaceTypeVarsN` on the body of the lambda. This body can contain sym nodes of gensym symbols generated by macros, which have `nil` type. But a piece of code in `replaceTypeVarsN` checks whether the type of a symbol is equal to `void` without checking if it's `nil` first, which causes a segfault. Now it also checks that the type of the symbol isn't `nil` for it to be `void`.
* handle explicit generic routine instantiations in sigmatch (#24010)metagn2024-09-0222-118/+436
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes #16376 The way the compiler handled generic proc instantiations in calls (like `foo[int](...)`) up to this point was to instantiate `foo[int]`, create a symbol for the instantiated proc (or a symchoice for multiple procs excluding ones with mismatching generic param counts), then perform overload resolution on this symbol/symchoice. The exception to this was when the called symbol was already a symchoice node, in which case it wasn't instantiated and overloading was called directly ([these lines](https://github.com/nim-lang/Nim/blob/b7b1313d21deb687adab2b4a162e716ba561a26b/compiler/semexprs.nim#L3366-L3371)). This has several problems: * Templates and macros can't create instantiated symbols, so they couldn't participate in overloaded explicit generic instantiations, causing the issue #16376. * Every single proc that can be instantiated with the given generic params is fully instantiated including the body. #9997 is about this but isn't fixed here since the instantiation isn't in a call. The way overload resolution handles explicit instantiations by itself is also buggy: * It doesn't check constraints. * It allows only partially providing the generic parameters, which makes sense for implicit generics, but can cause ambiguity in overloading. Here is how this PR deals with these problems: * Overload resolution now always handles explicit generic instantiations in calls, in `initCandidate`, as long as the symbol resolves to a routine symbol. * Overload resolution now checks the generic params for constraints and correct parameter count (ignoring implicit params). If these don't match, the entire overload is considered as not matching and not instantiated. * Special error messages are added for mismatching/missing/extra generic params. This is almost all of the diff in `semcall`. * Procs with matching generic parameters now instantiate only the type of the signature in overload resolution, not the proc itself, which also works for templates and macros. Unfortunately we can't entirely remove instantiations because overload resolution can't handle some cases with uninstantiated types even though it's resolved in the binding (see the last 2 blocks in `texplicitgenerics`). There are also some instantiation issues with default params that #24005 didn't fix but I didn't want this to become the 3rd huge generics PR in a row so I didn't dive too deep into trying to fix them. There is still a minor instantiation fix in `semtypinst` though for subscripts in calls. Additional changes: * Overloading of `[]` wasn't documented properly, it somewhat is now because we need to mention the limitation that it can't be done for generic procs/types. * Tests can now enable the new type mismatch errors with just `-d:testsConciseTypeMismatch` in the command. Package PRs: - using fork for now: [combparser](https://github.com/PMunch/combparser/pull/7) (partial generic instantiation) - merged: [cligen](https://github.com/c-blake/cligen/pull/233) (partial generic instantiation but non-overloaded + template) - merged: [neo](https://github.com/andreaferretti/neo/pull/56) (trying to instantiate template with no generic param)
* fixes #24033; Yielding from var fails with pairs and destructuring (#24046)ringabout2024-09-022-3/+25
| | | fixes #24033
* check constant conditions in generic `when` in objects (#24042)metagn2024-09-022-5/+58
| | | | | | | | | fixes #24041 `when` statements in generic object types normally just leave their conditions as expressions and still typecheck their branch bodies. Instead of this, when the condition can be evaluated as a constant as well as the ones before it and it resolves to `true`, it now uses the body of that branch without typechecking the remaining ones.
* fixes #24031; js codegen bug for case statement with just else branch (#24047)ringabout2024-09-022-2/+14
| | | fixes #24031
* generic issues test cases (#24028)metagn2024-08-305-0/+221
| | | | | | | | | | | | | closes #1969, closes #7547, closes #7737, closes #11838, closes #12283, closes #12714, closes #12720, closes #14053, closes #16118, closes #19670, closes #22645 I was going to wait on these but regression tests even for recent PRs are turning out to be important in wide reaching PRs like #24010. The other issues with the working label felt either finnicky (#7385, #9156, #12732, #15247), excessive to test (#12405, #12424, #17527), or I just don't know what fixed them/what the issue was (#16128: the PR link gives a server error by Github, #12457, #12487).
* fixes #24034; fixes lent types after taking implicit address (#24035)ringabout2024-08-302-0/+21
| | | fixes #24034
* remove noise from bug report issue form (#24030)metagn2024-08-291-19/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removes some noise from the bug report issue template so people who aren't familiar can submit issues with less friction. Some of these might be a bit subjective, feel free to call out any nitpicky parts, I didn't want to rewrite entirely. Mostly fixed typos & language issues, other than that: * Just "detailed information", no need to say "descriptive", and changed "reproducible code and detailed information" to "or detailed information" because code is good enough * Simplified description label, mention code example can go there * Changed "Possible Solution" to "Known Workarounds" because it's what issue authors are more likely to know (and usually write anyway) and is more useful to most readers. * Doc link for "rebuilding the compiler" was broken, replaced it with mentioning choosenim, nightlies and building a temp compiler which is hopefully less offputting Weird looking preview [here](https://github.com/metagn/Nim/blob/issue-templates/.github/ISSUE_TEMPLATE/bug_report.yml) Just to complain: Github issue forms have some problems themselves, there's no option to disable the "No response" text when an optional area is unfilled, and the textboxes are really small at least on Firefox (though you can expand them). The alternative, issue templates, isn't much better. Github also hides the ability to open a blank issue in a text link in a small line after all the issue form buttons, I'm guessing this is intentional for repositories which don't want blank issues but we don't have such a problem. Worst comes to worst we can add a button for a minimal/empty issue template.
* proper error message for out-of-range enum sets (#24027)metagn2024-08-293-3/+74
| | | fixes #17848
* fix `include` in templates, with prefix operators (#24029)metagn2024-08-295-12/+25
| | | | | | | | | | | fixes #12539, refs #21636 `evalInclude` now uses `getPIdent` to check if a symbol isn't `/` anymore instead of assuming it's an ident, which it's not when used in templates. Also it just checks if the symbol is `as` now, because there are other infix operators that could be used like `/../`. It also works with prefix operators now by copying what was done in #21636.
* fixes typo (#24026)ringabout2024-08-291-1/+1
|
* fixes #23923; type-aliased seq[T] get different backend C/C++ pointer type ↵ringabout2024-08-282-2/+14
| | | | | | | names causing invalid codegen (#23924) … type names causing invalid codegen fixes #23923
* Fix linux start process errorCode always 0 (#24001)握猫猫2024-08-283-14/+49
| | | | | | | | | | | | #23992 The test case provided does not cover the Windows situation, I fixed it in this new PR. Fixed an issue where errorCode was always 0 when startProcess didn't use the poEvalCommand flag. Tthe sleep command might not be available in all Windows installations, so I skipped the relevant test. Added a test case, tested on my fedora and windows systems.
* opensym for templates + move behavior of opensymchoice to itself (#24007)metagn2024-08-2818-120/+468
| | | | | | | | | | | | | | | | | | | | | | | fixes #15314, fixes #24002 The OpenSym behavior first added to generics in #23091 now also applies to templates, since templates can also capture symbols that are meant to be replaced by local symbols if the context imports symbols with the same name, as in the issue #24002. The experimental switch `templateOpenSym` is added to enable this behavior for templates only, and the experimental switch `openSym` is added to enable it for both templates and generics, and the documentation now mainly mentions this switch. Additionally the logic for `nkOpenSymChoice` nodes that were previously wrapped in `nkOpenSym` now apply to all `nkOpenSymChoice` nodes, and so these nodes aren't wrapped in `nkOpenSym` anymore. This means `nkOpenSym` can only have children of kind `nkSym` again, so it is more in line with the structure of symchoice nodes. As for why they aren't merged with `nkOpenSymChoice` nodes yet, we need some way to signal that the node shouldn't become ambiguous if other options exist at instantiation time, we already captured a symbol at the beginning and another symbol can only replace it if it's closer in scope and unambiguous.
* remove fauxMatch for tyFromExpr, remove tyProxy and tyUnknown aliases (#24018)metagn2024-08-2815-39/+31
| | | | | | | | | | | | | | | | | | | | | updated version of #22193 After #22029 and the followups #23983 and #24005 which fixed issues with it, `tyFromExpr` no longer match any proc params in generic type bodies but delay all non-matching calls until the type is instantiated. Previously the mechanism `fauxMatch` was used to pretend that any failing match against `tyFromExpr` actually matched, but prevented the instantiation of the type until later. Since this mechanism is not needed anymore for `tyFromExpr`, it is now only used for `tyError` to prevent cascading errors and changed to a bool field for simplicity. A change in `semtypes` was also needed to prevent calling `fitNode` on default param values resolving to type `tyFromExpr` in generic procs for params with non-generic types, as this would try to coerce the expression into a concrete type when it can't be instantiated yet. The aliases `tyProxy` and `tyUnknown` for `tyError` and `tyFromExpr` are also removed for uniformity.
* fixes #14623; Top-level volatileLoad/volatileStore leads to invalid codegen ↵ringabout2024-08-282-7/+20
| | | | | (#24020) fixes #14623
* use the official URL of neo (#24019)ringabout2024-08-281-1/+1
| | | ref https://github.com/andreaferretti/neo/pull/55
* fixes #23925; VM generates wrong cast for negative enum values (#23951)autumngray2024-08-272-6/+36
| | | | | | | | | | Follow up of #23927 which solves the build error. This is still only a partial fix as it doesn't take into account unordered enums. I'll make a separate issue for those. --------- Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
* make int literals with range type match their base type better than other ↵metagn2024-08-271-3/+10
| | | | | | | | | | | | | | | | int types (#24017) This is a very niche case encountered in #24012, where an int literal got a `range` type as a result of a generic instantiation (in `tgenericcomputedrange`), I can't think of another test case. The base type of the range being `int` made it match `int` with `isSubrange` as in the first `if` branch, but other int types like `int32` matched with `isFromIntLit` which is a better match. Instead, int literals with range type now: 1. match their base type with `isFromIntLit`, 2. don't match other int types with `isFromIntLit`, instead giving `isConvertible` as in the last `if` branch in `handleRange`.
* fixes #22553; regression of offsetof(T, anFieldOfUncheckedArray) (#24014)ringabout2024-08-273-3/+17
| | | | | | fixes #22553 follow up https://github.com/nim-lang/Nim/pull/21979 which introduced a char dummy member prepended to objs only containing an UncheckedArray
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-02-05 08:47:47 +0000