summary refs log tree commit diff stats
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* generate symchoice for ambiguous types in templates & generics + handle ↵metagn2024-08-255-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | types in symchoices (#23997) fixes #23898, supersedes #23966 and #23990 Since #20631 ambiguous type symbols in templates are rejected outright, now we generate a symchoice for type nodes if they're ambiguous, a generalization of what was done in #22375. This is done for generics as well. Symchoices also handle type symbols better now, ensuring their type is a `typedesc` type; this probably isn't necessary for everything to work but it makes the logic more robust. Similar to #23989, we have to prepare for the fact that ambiguous type symbols behave differently than normal type symbols and either error normally or relegate to other routine symbols if the symbol is being called. Generating a symchoice emulates this behavior, `semExpr` will find the type symbol first, but since the symchoice has other symbols, it will count as an ambiguous type symbol. I know it seems spammy to carry around an ambiguity flag everywhere, but in the future when we have something like #23104 we could just always generate a symchoice, and the symchoice itself would carry the info of whether the first symbol was ambiguous. But this could harm compiler performance/memory use, it might be better to generate it only when we have to, which in the case of type symbols is only when they're ambiguous.
* fixes #23915; std/random produces different results on c/js (#24003)ringabout2024-08-251-5/+10
| | | fixes #23915
* fixes `cast` expressions introduces unnecessary copies (#24004)ringabout2024-08-232-43/+17
| | | | | | | | | | | | | | | | | It speeds up ```nim proc foo = let piece = cast[seq[char]](newSeqUninit[uint8](5220600386'i64)) foo() ``` Notes that `cast[ref](...)` is excluded because we need to keep the ref alive if the parameter is something with pointer types (e.g. `cast[ref](pointer)`or `cast[ref](makePointer(...))`) --------- Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* fix error messages for wrongly typed generic param default values (#24006)metagn2024-08-231-0/+25
| | | | | | | | | | | | | | | | | | fixes #21258 When a generic proc is instantiated, if one of the default values doesn't match the type of the parameter, `seminst` sets the default parameter node to an `nkEmpty` node with `tyError` type. `sigmatch` checks for this to give an error message if the default param is actually used, but only while actively matching the proc signature, before the proc is even instantiated. The error message also gives very little information. Now, we check for this in `updateDefaultParams` at the end of `semResolvedCall`, after the proc has been instantiated. The `nkEmpty` node also is given the original mismatching type instead rather than `tyError`, only setting `tyError` after erroring to prevent cascading errors. The error message is changed to the standard type mismatch error also giving the instantiation info of the routine.
* fixes #23454; IndexDefect thrown when destructuring a lent tuple (#23993)ringabout2024-08-221-0/+36
| | | fixes #23454
* fix subscript magic giving unresolved generic param type (#23988)metagn2024-08-222-0/+25
| | | | | | | | | | | | | | | | | | | | | | fixes #19737 As in the diff, `semResolvedCall` sets the return type of a call to a proc to the type of the call. But in the case of the [subscript magic](https://nim-lang.org/docs/system.html#%5B%5D%2CT%2CI), this type is the first generic param which is also supposed to be the type of the first argument, but this is invalid, the correct type is the element type eventually given by `semSubscript`. Some lines above also [prevent the subscript magics from instantiating their params](https://github.com/nim-lang/Nim/blob/dda638c1ba985a77eac3c7518138992521884172/compiler/semcall.nim#L699) so this type ends up being an unresolved generic param. Since the type of the node is not `nil`, `prepareOperand` doesn't try to type it again, and this unresolved generic param type ends up being the final type of the node. To prevent this, we just never set the type of the node if we encountered a subscript magic. Maybe we could also rename the generic parameters of the subscript magics to stuff like `DummyT`, `DummyI` if we want this to be easier to debug in the future.
* fixes #23943; simple default value for range (#23996)ringabout2024-08-221-0/+5
| | | | | | | fixes #23943 --------- Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* don't require symbol with enum type to be constant in fitNode (#23999)metagn2024-08-221-0/+7
| | | | | | | | | | | | | | | | fixes #23998 In `fitNode` the first symbol of a symchoice that expects an enum type with the same enum type is given as the result of the `fitNode`. But `getConstExpr` is also called on it, which will return a `nil` node for nodes that aren't constant but have the enum type, like variables or proc parameters. Instead we just return the node directly since it's already typed. Normally, this `if` branch in `fitNode` shouldn't exist since `paramTypesMatch` handles it, but the way pure enum symbols work makes it really impractical to check their ambiguity, which `paramTypesMatch` won't like. If it causes problems for regular enums we can restrict this branch to just pure enums until they are hopefully eventually removed.
* Revert "Fixed an issue where `errorCode` was always 0 when `startProcess` ↵ringabout2024-08-211-18/+0
| | | | | did…" (#23995) Reverts nim-lang/Nim#23992
* Fixed an issue where `errorCode` was always 0 when `startProcess` did… ↵握猫猫2024-08-211-0/+18
| | | | | | | | | (#23992) …n't use the `poEvalCommand` flag https://forum.nim-lang.org/t/12310 Added a test case, tested on my fedora system.
* consider ambiguity for qualified symbols (#23989)metagn2024-08-203-0/+9
| | | | | | | | | | | | | fixes #23893 When type symbols are ambiguous, calls to them aren't allowed to be type conversions and only routine symbols are considered instead. But the compiler doesn't acknowledge that qualified symbols can be ambiguous, `qualifiedLookUp` directly tries to access the identifier from the module string table. Now it checks the relevant symbol iterators for any symbol after the first received symbol, in which case the symbol is considered ambiguous. `nkDotExpr` is also included in the whitelist of node kinds for ambiguous type symbols (not entirely sure why this exists, it's missing `nkAccQuoted` as well).
* sem all call nodes in generic type bodies + many required fixes (#23983)metagn2024-08-206-13/+254
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes #23406, closes #23854, closes #23855 (test code of both compiles but separate issue exists), refs #23432, follows #23411 In generic bodies, previously all regular `nkCall` nodes like `foo(a, b)` were directly treated as generic statements and delayed immediately, but other call kinds like `a.foo(b)`, `foo a, b` etc underwent typechecking before making sure they have to be delayed, as implemented in #22029. Since the behavior for `nkCall` was slightly buggy (as in #23406), the behavior for all call kinds is now to call `semTypeExpr`. However the vast majority of calls in generic bodies out there are `nkCall`, and while there isn't a difference in the expected behavior, this exposes many issues with the implementation started in #22029 given how much more code uses it now. The portion of these issues that CI has caught are fixed in this PR but it's possible there are more. 1. Deref expressions, dot expressions and calls to dot expressions now handle and propagate `tyFromExpr`. This is most of the changes in `semexprs`. 2. For deref expressions to work in `typeof`, a new type flag `tfNonConstExpr` is added for `tyFromExpr` that calls `semExprWithType` with `efInTypeof` on the expression instead of `semConstExpr`. This type flag is set for every `tyFromExpr` type of a node that `prepareNode` encounters, so that the node itself isn't evaluated at compile time when just trying to get the type of the node. 3. Unresolved `static` types matching `static` parameters is now treated the same as unresolved generic types matching `typedesc` parameters in generic type bodies, it causes a failed match which delays the call instantiation. 4. `typedesc` parameters now reject all types containing unresolved generic types like `seq[T]`, not just generic param types by themselves. (using `containsGenericType`) 5. `semgnrc` now doesn't leave generic param symbols it encounters in generic type contexts as just identifiers, and instead turns them into symbol nodes. Normally in generic procs, this isn't a problem since the generic param symbols will be provided again at instantiation time (and in fact creating symbol nodes causes issues since `seminst` doesn't actually instantiate proc body node types). But generic types can try to be instantiated early in `sigmatch` which will give an undeclared identifier error when the param is not provided. Nodes in generic types (specifically in `tyFromExpr` which should be the only use for `semGenericStmt`) undergo full generic type instantiation with `prepareNode`, so there is no issue of these symbols remaining as uninstantiated generic types. 6. `prepareNode` now has more logic for which nodes to avoid instantiating. Subscripts and subscripts turned into calls to `[]` by `semgnrc` need to avoid instantiating the first operand, since it may be a generic body type like `Generic` in an expression like `Generic[int]`. Dot expressions cannot instantiate their RHS as it may be a generic proc symbol or even an undeclared identifier for generic param fields, but have to instantiate their LHS, so calls and subscripts need to still instantiate their first node if it's a dot expression. This logic still isn't perfect and needs the same level of detail as in `semexprs` for which nodes can be left as "untyped" for overloading/dot exprs/subscripts to handle, but should handle the majority of cases. Also the `efDetermineType` requirement for which calls become `tyFromExpr` is removed and as a result `efDetermineType` is entirely unused again.
* allow qualifying macro pragmas (#23985)metagn2024-08-202-0/+24
| | | fixes #12696
* include generic bodies in allowMetaTypes (#23968)metagn2024-08-201-0/+16
| | | | | | | | fixes #19848 Not sure why this wasn't the case already. The `if cl.allowMetaTypes: return` line below for `tyFromExpr` [was added 10 years ago](https://github.com/nim-lang/Nim/commit/d5798b43dec547f372eb49d5a8848a9970b12260). Hopefully it was just negligence?
* adds a ubuntu 24.04 matrix with gcc 14 for tests (#23673)ringabout2024-08-203-3/+11
| | | ref https://forum.nim-lang.org/t/11587
* fixes #23982; codegen regression passing pointer expressions to inline ↵ringabout2024-08-201-0/+11
| | | | | iterators (#23986) fixes #23982
* fixes #23973; fixes #23974; Memory corruption with lent and ORC (#23981)ringabout2024-08-201-0/+31
| | | | fixes #23973; fixes #23974
* allow `untyped` arguments to fail to compile in overload mismatch error (#23984)metagn2024-08-201-0/+37
| | | | | | | | | | | | | | | | fixes #8697, fixes #9620, fixes #23265 When matching a `template` with an `untyped` argument fails because of a mismatching typed argument, `presentFailedCandidates` tries to sem every single argument to show their types, but trying to type the `untyped` argument can fail if it's supposed to use an injected symbol, so we get an unrelated error message like "undeclared identifier". Instead we use `tryExpr` as the comment suggests, setting the type to `untyped` if it fails to compile. We could also maybe check if an `untyped` argument is expected in its place and not try to compile the expression if it is but this would require a bit of reorganizing the code here and IMO it's better to have the information of what type it would be if it can be typed.
* fix infinite recursion in term rewriting macros tests (#23979)metagn2024-08-202-3/+7
| | | Noticed Hint [Pattern] spam in CI
* make all generic aliases tyAlias (#23978)metagn2024-08-202-1/+9
| | | | | | | | | | | | | fixes #23977 The problem is that for *any* body of a generic declaration, [semstmts](https://github.com/nim-lang/Nim/blob/2e4d344b43b040a4dce2c478ca13e49979e491fc/compiler/semstmts.nim#L1610-L1611) sets the sym of its value to the generic type name, and [semtypes](https://github.com/nim-lang/Nim/blob/2e4d344b43b040a4dce2c478ca13e49979e491fc/compiler/semtypes.nim#L2143) just directly gives the referenced type *specifically* when the expression is a generic body. I'm blaming `semtypes` here because it's responsible for the type given but the exact opposite behavior specifically written in makes me think generating an alias type here maybe breaks something.
* Fixes #23962 `resetLoc`doenst produce any cgen code in `importcpp` types ↵Juan M Gómez2024-08-182-0/+49
| | | | (#23964)
* allow generic compileTime proc folding (#22022)metagn2024-08-181-0/+29
| | | | | | | | | | | | | | fixes #10753, fixes #22021, refs #19365 (was fixed by #22029, but more faithful test added) For whatever reason `compileTime` proc calls did not fold if the proc was generic ([since this folding was introduced](https://github.com/nim-lang/Nim/commit/c25ffbf2622a197c15a4a3bd790b1bc788db2c7f#diff-539da3a63df08fa987f1b0c67d26cdc690753843d110b6bf0805a685eeaffd40)). I'm guessing the intention was for *unresolved* generic procs to not fold, which is now the logic. Non-magic `compileTime` procs also now don't fold at compile time in `typeof` contexts to avoid possible runtime errors (only the important) and prevent double/needless evaluation.
* always lookup pure enum symbols if expected type is enum (#23976)metagn2024-08-171-0/+13
| | | | | | | | | | | | | | | | | | | | fixes #23689 Normally pure enum symbols only "exist" in lookup if nothing else with the same name is in scope. But if an expression is expected to be an enum type, we know that ambiguity can be resolved between different symbols based on their type, so we can include the normally inaccessible pure enum fields in the ambiguity resolution in the case that the expected enum type is actually a pure enum. This handles the use case in the issue of the type inference for enums reverted in #23588. I know pure enums are supposed to be on their way out so this might seem excessive, but the `pure` pragma can't be removed in the code in the issue due to a redefinition error, they have to be separated into different modules. Normal enums can still resolve the ambiguity here though. I always think about making a list of all the remaining use cases for pure enums and I always forget. Will close #23694 if CI passes
* fixes docgen regression: don't add newLine for code if it's the first line ↵ringabout2024-08-172-11/+6
| | | | | | | | | | | | | | | (#23154) Before (devel) ![image](https://github.com/nim-lang/Nim/assets/43030857/cde37109-027a-46c1-a37e-1d6062e6c609) After (this PR and stable) ![image](https://github.com/nim-lang/Nim/assets/43030857/3366877c-7223-4749-a584-fe93f731281f) It now keeps the same behavior as before
* fixes default float ranges (#23957)ringabout2024-08-161-0/+12
|
* fix `is` with `type`/`typedesc` crashing the compiler (#23967)metagn2024-08-161-0/+4
| | | | | | | | | | fixes #22850 The `is` operator checks the type of the left hand side, and if it's generic or if it's a `typedesc` type with no base type, it leaves it to be evaluated later. But `typedesc` types with no base type precisely describe the default typeclass `type`/`typeclass`, so this condition is removed. Maybe at some point this represented an unresolved generic type?
* remove nontoplevel type hack + consider symbol disamb in type hash (#23969)metagn2024-08-161-0/+9
| | | | | | | | | | | | | | fixes #22571 Removes the hack added in #13589 which made non-top-level object type symbols `gensym` because they couldn't be mangled into different names for codegen vs. top-level types. Now we consider the new `disamb` field (added in #21667) of the type symbols in the type hash (which is used for the mangled name) to differentiate between the types. In other parts of the compiler, specifically the [proc mangling](https://github.com/nim-lang/Nim/blob/298ada3412c9cf5971abc2b3b891b9bb8612e170/compiler/mangleutils.nim#L59), `itemId.item` is used instead of the `disamb` field, but I didn't use it in case it's the outdated method.
* fixes #23954; uint8 > 8 bit at compile-time (#23955)ringabout2024-08-151-0/+5
| | | fixes #23954
* supports `default` for range types using `firstOrd` with ↵ringabout2024-08-131-2/+16
| | | | | `nimPreviewRangeDefault` (#23950) ref https://github.com/nim-lang/Nim/issues/23943
* fixes #23947; .uint8 compile-time error (#23948)ringabout2024-08-131-0/+10
| | | fixes #23947
* Adds `SEQ_DECL_SIZE 1` back under `clang` and a test (#23942)Juan M Gómez2024-08-122-0/+11
|
* opensym as node kind + fixed experimental switch (#23892)metagn2024-08-124-0/+60
| | | | | | | | | | | | | | | refs https://github.com/nim-lang/Nim/pull/23873#discussion_r1687995060, fixes #23386, fixes #23385, supersedes #23572 Turns the `nfOpenSym` node flag implemented in #23091 and extended in #23102 and #23873, into a node kind `nkOpenSym` that forms a unary node containing either `nkSym` or `nkOpenSymChoice`. Since this affects macros working on generic proc AST, the node kind is now only generated when the experimental switch `genericsOpenSym` is enabled, and a new node flag `nfDisabledOpenSym` is set to the `nkSym` or `nkOpenSymChoice` when the switch is not enabled so that we can give a warning. Now that the experimental switch has more reasonable semantics, we define `nimHasGenericsOpenSym2`.
* Implemented `compileOption` for `experimental` to test if a feature i… ↵Don-Duong Quach2024-08-122-0/+39
| | | | | | | | (#23933) …s enabled at compile time. #8644 This doesn't handle the case if `{.push experimental.}` is used, but at least we can test if a feature was enabled globally.
* fixes #23936; opcParseFloat accepts the wrong register as the first param ↵ringabout2024-08-121-0/+11
| | | | | | [backport] (#23941) fixes #23936 follow up https://github.com/nim-lang/Nim/pull/20527
* fixes jsbigint64 regression; keeps convs to `Number` in danger mode (#23926)ringabout2024-08-111-0/+17
| | | fixes jsbigint64 regression
* fixes #23932; vmopsDanger for os.getCurrentDir errors (#23934)ringabout2024-08-111-2/+5
| | | | fixes #23932 ref https://github.com/jmgomez/NimForUE/issues/36
* don't treat template/macro/module as overloaded for opensym (#23939)metagn2024-08-111-1/+1
| | | | | | | | | | | | | | actually fixes #23865 following up #23873 In the handling of `nkIdent` in `semExpr`, the compiler looks for the closest symbol with the name and [checks the symbol kind](https://github.com/nim-lang/Nim/blob/6126a0bf46f4e29a368b8baefea69a2bcae54e93/compiler/semexprs.nim#L3171) to also consider the overloads if the symbol kind is overloadable. But it treats the normally overloadable template/macro/module sym kinds the same as non-overloadable symbols, just calling `semSym` on it. We need to mirror this behavior in `semOpenSym`; we treat the captured symchoice as a fresh identifier, so if the symbol we find is a template/macro/module, we use that symbol immediately as opposed to waiting for overloads.
* fixes #14522 #22085 #12700 #23132; no range check for uints (#23930)ringabout2024-08-112-2/+27
| | | | | | | | | | fixes #14522 fixes #22085 fixes #12700 fixes #23132 closes https://github.com/nim-lang/Nim/pull/22343 (succeeded by this PR) completes https://github.com/nim-lang/RFCs/issues/175 follow up https://github.com/nim-lang/Nim/pull/12688
* fixes #23914; jsondoc broken in devel (#23916)ringabout2024-08-112-2/+7
| | | | | follows up https://github.com/nim-lang/Nim/pull/23064 fixes #23914
* fixes #23907; Double destroy using proc type alias with a sink (#23909)ringabout2024-08-111-0/+23
| | | fixes #23907
* fixes #23902; Compiler infers sink in return type from auto (#23904)ringabout2024-08-111-0/+8
| | | fixes #23902
* closes #6549; adds a test case (#23929)ringabout2024-08-091-1/+17
| | | closes #6549
* closes #21347; adds a test case (#23917)ringabout2024-08-041-0/+8
| | | closes #21347
* fixes #23894; succ/pred shouldn't raise OverflowDefect for unsigned integers ↵ringabout2024-07-261-0/+6
| | | | | | | (#23895) fixes #23894 keeps it consistent with `inc`
* implement genericsOpenSym for symchoices (#23873)metagn2024-07-253-1/+65
| | | | | | | | | | fixes #23865 The node flag `nfOpenSym` implemented in #23091 for sym nodes is now also implemented for open symchoices. This means the intended behavior is still achieved when multiple overloads are in scope to be captured, so the issue is fixed. The code for the flag is documented and moved into a helper proc and the experimental switch is now enabled for the compiler test suite.
* Overload resultion with generic variables an inheritance (#23870)Ryan McConnell2024-07-242-21/+84
| | | The test case diff is self explanatory
* fixes #19171; have `openArray` converted from `ptr UncheckedArray` be ↵Buldram2024-07-241-0/+19
| | | | | | mutable (#23882) Makes `toOpenArray(x: ptr UncheckedArray)` always return a `var openArray` regardless of if `x` is mutable.
* doc,test(times): followup #23861 (#23881)lit2024-07-231-1/+13
| | | followup #23861
* fixes #23869; sink generic typeclass (#23874)Ryan McConnell2024-07-221-0/+26
| | | | | | | Still have to look this over some. We'll see. I put sink in this branch simply because I saw `tyVar` there and for no other reason. In any case the problem appears to be coming from `liftParamType` as it removes the `sink` type from the formals. #23869
* Fix out-of-bounds slicing in std/varints (#23868)Buldram2024-07-221-1/+1
| | | | | | Corrects a slicing mistake in the `std/varints` implementation which caused it to fail when writing large numbers into buffers smaller than 10..13-bytes, now 9-byte buffers are sufficient as the documentation states.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-04-23 06:38:11 +0000