summary refs log tree commit diff stats
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* fixes refc with non-var destructor; cancel warnings (#23156)ringabout2024-02-131-2/+6
| | | fixes https://forum.nim-lang.org/t/10807
* fixes #18104; tranform one liner var decl before templates expansion (#23294)ringabout2024-02-131-0/+7
| | | fixes #18104
* MangleProcs following the Itanium spec so they are demangled in the debugger ↵Juan M Gómez2024-02-091-0/+192
| | | | | | | | | call stack (#23260) ![image](https://github.com/nim-lang/Nim/assets/1496571/0d796c5b-0bbf-4bb4-8c95-c3e3cce22f15) --------- Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* fixes #23275; Add `==` for Deque (#23276)Tomohiro2024-02-081-0/+49
|
* fixes regression #23280; Operations on inline toOpenArray len return a wrong ↵ringabout2024-02-061-0/+10
| | | | | result (#23285) fixes #23280
* closes #14710; adds a test case (#23277)ringabout2024-02-051-0/+10
| | | closes #14710
* fixes regression #22909; don't optimize result init if statements can raise ↵ringabout2024-02-011-1/+12
| | | | | | | | | | | | | | | | which corrupts the compiler (#23271) fixes #22909 required by https://github.com/nim-lang/Nim/pull/23267 ```nim proc foo: string = assert false result = "" ``` In the function `foo`, `assert false` raises an exception, which can cause `result` to be uninitialized if the default result initialization is optimized out
* fixes #19977; rework inlining of 'var openarray' iterators for C++ (#23258)ringabout2024-01-261-1/+1
| | | fixes #19977
* fixes #23247; don't destroy openarray since it doesn't own the data (#23254)ringabout2024-01-261-0/+52
| | | | | | | | | | | | | | | | | | | | | | | fixes #23247 closes #23251 (which accounts for why the openarray type is lifted because ops are lifted for openarray conversions) related: https://github.com/nim-lang/Nim/pull/18713 It seems to me that openarray doesn't own the data, so it cannot destroy itself. The same case should be applied to https://github.com/nim-lang/Nim/issues/19435. It shouldn't be destroyed even openarray can have a destructor. A cleanup will be followed for https://github.com/nim-lang/Nim/pull/19723 if it makes sense. According to https://github.com/nim-lang/Nim/pull/12073, it lifts destructor for openarray when openarray is sunk into the function, when means `sink openarray` owns the data and needs to destroy it. In other cases, destructor shouldn't be lifted for `openarray` in the first place and it shouldn't destroy the data if it doesn't own it. --------- Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* fixes #22597; avoid side effects for call returning openArray types (#23257)ringabout2024-01-261-0/+19
| | | | | | | | | | | | | | fixes #22597 ```nim proc autoToOpenArray*[T](s: Slice[T]): openArray[T] = echo "here twice" result = toOpenArray(s.p, s.first, s.last) ``` For functions returning openarray types, `fixupCall` creates a temporary variable to store the return value: `let tmp = autoToOpenArray()`. But `genOpenArrayConv` cannot handle openarray assignements with side effects. It should have stored the right part of the assignment first instead of calling the right part twice.
* Show error when trying to run in folder that doesn't exist instead of ↵Jake Leahy2024-01-231-0/+6
| | | | | | | assertion (#23242) Closes #23240 Fixes regression caused by #23017
* account for nil return type in tyProc sumGeneric (#23250)metagn2024-01-231-0/+17
| | | fixes #23249
* fixes #23233; Regression when using generic type with Table/OrderedTable ↵ringabout2024-01-191-1/+21
| | | | | (#23235) fixes #23233
* fix mime types data (#23226)Bung2024-01-191-0/+3
| | | | | | generated via https://github.com/bung87/mimetypes_gen source data: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=co
* fixes #22218; avoids cursor when copy is disabled (#23209)ringabout2024-01-181-0/+25
| | | fixes #22218
* fixes #12334; keeps `nkHiddenStdConv` for cstring conversions (#23216)ringabout2024-01-181-0/+10
| | | | | | fixes #12334 `nkHiddenStdConv` shouldn't be removed if the sources aren't literals, viz. constant symbols.
* fix wrong subtype relation in tuples & infer some conversions (#23228)metagn2024-01-182-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | fixes #18125 Previously a tuple type like `(T, int)` would match an expected tuple type `(U, int)` if `T` is a subtype of `U`. This is wrong since the codegen does not handle type conversions of individual tuple elements in a type conversion of an entire tuple. For this reason the compiler already does not accept `(float, int)` for a matched type `(int, int)`, however the code that checked for which relations are unacceptable checked for `< isSubtype` rather than `<= isSubtype`, so subtypes were not included in the unacceptable relations. Update: Now only considered unacceptable when inheritance is used, as in [`paramTypesMatch`](https://github.com/nim-lang/Nim/blob/3379d26629f30e6be8d303a36e220d1039eb4551/compiler/sigmatch.nim#L2252-L2254). Ideally subtype relations that don't need conversions, like `nil`, `seq[empty]`, `range[0..5]` etc would be their own relation `isConcreteSubtype` (which would also allow us to differentiate with `openArray[T]`), but this is too big of a refactor for now. To compensate for this making things like `let x: (Parent, int) = (Child(), 0)` not compile (they would crash codegen before anyway but should still work in principle), type inference for tuple constructors is updated such that they call `fitNode` on the fields and their expected types, so a type conversion is generated for the individual subtype element.
* error on large integer types as array index range (#23229)metagn2024-01-181-0/+18
| | | | | | | | | | fixes #17163, refs #23204 Types that aren't `tyRange` and are bigger than 16 bits, so `int32`, `uint64`, `int` etc, are disallowed as array index range types. `tyRange` is excluded because the max array size is backend independent (except for the specific size of `high(uint64)` which crashes the compiler) and so there should still be an escape hatch for people who want bigger arrays.
* give typedesc param nodes type T not typedesc[T] [backport:2.0] (#23115)metagn2024-01-182-2/+14
| | | | | | | fixes https://github.com/nim-lang/Nim/issues/23112, fixes a mistake in https://github.com/nim-lang/Nim/pull/22581 This makes `getType(t)` where `t` is a typedesc param with value `T` equal to `getType(T)`.
* Fix reset code gen for range types (#22462, #23214) (#23215)Giuliano Mega2024-01-181-0/+20
| | | | | | This PR modifies `specializeResetT` so that it generates the proper reset code for range types. I've tested it in the examples for issues #23214 and #22462 as well as our codebase, and it seems to fix the issues I had been experiencing.
* fixes #23223; prevents `insert` self-assignment (#23225)ringabout2024-01-181-0/+7
| | | fixes #23223
* don't use previous bindings of `auto` for routine return types (#23207)metagn2024-01-177-10/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes #23200, fixes #18866 #21065 made it so `auto` proc return types remained as `tyAnything` and not turned to `tyUntyped`. This had the side effect that anything previously bound to `tyAnything` in the proc type match was then bound to the proc return type, which is wrong since we don't know the proc return type even if we know the expected parameter types (`tyUntyped` also [does not care about its previous bindings in `typeRel`](https://github.com/nim-lang/Nim/blob/ab4278d2179639f19967431a7aa1be858046f7a7/compiler/sigmatch.nim#L1059-L1061) maybe for this reason). Now we mark `tyAnything` return types for routines as `tfRetType` [as done for other meta return types](https://github.com/nim-lang/Nim/blob/18b5fb256d4647efa6a64df451d37129d36e96f3/compiler/semtypes.nim#L1451), and ignore bindings to `tyAnything` + `tfRetType` types in `semtypinst`. On top of this, we reset the type relation in `paramTypesMatch` only after creating the instantiation (instead of trusting `isInferred`/`isInferredConvertible` before creating the instantiation), using the same mechanism that `isBothMetaConvertible` uses. This fixes the issues as well as making the disabled t15386_2 test introduced in #21065 work. As seen in the changes for the other tests, the error messages give an obscure `proc (a: GenericParam): auto` now, but it does give the correct error that the overload doesn't match instead of matching the overload pre-emptively and expecting a specific return type. tsugar had to be changed due to #16906, which is the problem where `void` is not inferred in the case where `result` was never touched.
* fixes #23180; fixes #19805; prohibits invalid tuple unpacking code in for ↵ringabout2024-01-131-2/+2
| | | | | | loop (#23185) fixes #23180 fixes #19805
* fixes #15924; Tuple destructuring is broken with closure iterators (#23205)ringabout2024-01-131-0/+18
| | | fixes #15924
* document the new ambiguous identifier resolution (#23166)metagn2024-01-113-0/+33
| | | | | refs #23123 Not sure if detailed enough.
* fixes #22923; fixes `=dup` issues (#23182)ringabout2024-01-111-0/+26
| | | fixes #22923
* fixes #23129; fixes generated hooks raise unlisted Exception, which never ↵ringabout2024-01-111-0/+16
| | | | | raise (#23195) fixes #23129
* delay resolved procvar check for proc params + acknowledge unresolved ↵metagn2024-01-115-6/+163
| | | | | | | | | | | | | | | | | | | | | | | | | statics (#23188) fixes #23186 As explained in #23186, generics can transform `genericProc[int]` into a call `` `[]`(genericProc, int) `` which causes a problem when `genericProc` is resemmed, since it is not a resolved generic proc. `[]` needs unresolved generic procs since `mArrGet` also handles explicit generic instantiations, so delay the resolved generic proc check to `semFinishOperands` which is intentionally not called for `mArrGet`. The root issue for [t6137](https://github.com/nim-lang/Nim/blob/devel/tests/generics/t6137.nim) is also fixed (because this change breaks it otherwise), the compiler doesn't consider the possibility that an assigned generic param can be an unresolved static value (note the line `if t.kind == tyStatic: s.ast = t.n` below the change in sigmatch), now it properly errors that it couldn't instantiate it as it would for a type param. ~~The change in semtypinst is just for symmetry with the code above it which also gives a `cannot instantiate` error, it may or may not be necessary/correct.~~ Now removed, I don't think it was correct. Still possible that this has unintended consequences.
* trigger range check with new type inference on nkIntLit [backport:1.6] (#23179)metagn2024-01-081-0/+10
| | | | | | | | | | | | fixes #23177 `changeType` doesn't perform range checks to see if the expression fits the new type [if the old type is the same as the new type](https://github.com/nim-lang/Nim/blob/62d8ca43063197272968b4acf8c7a1ef27874c54/compiler/semexprs.nim#L633). For `nkIntLit`, we previously set the type to the concrete base of the expected type first, then call `changeType`, which works for things like range types but not bare types of smaller bit size like `int8`. Now we don't set the type (so the type is nil), and `changeType` performs the range check when the type is unset (nil).
* don't transform typed bracket exprs to `[]` calls in templates (#23175)metagn2024-01-071-0/+38
| | | | | | | | | | | | | | fixes #22775 It's pre-existing that [`prepareOperand` doesn't typecheck expressions which have types](https://github.com/nim-lang/Nim/blob/a4f3bf374238df96f0982b7106e3702da6b485b1/compiler/sigmatch.nim#L2444). Templates can take typed subscript expressions, transform them into calls to `[]`, and then have this `[]` not be resolved later if the expression is nested inside of a call argument, which leaks an untyped expression past semantic analysis. To prevent this, don't transform any typed subscript expressions into calls to `[]` in templates. Ditto for curly subscripts (with `{}`) and assignments to subscripts and curly subscripts (with `[]=` and `{}=`).
* Fixes #23172 (#23173)Ryan McConnell2024-01-062-0/+15
| | | #23172
* fixes #23139; Cannot get repr of range type of enum (#23164)ringabout2024-01-051-0/+5
| | | fixes #23139
* Changing generic weight of `tyGenericParam` (#22143)Ryan McConnell2024-01-059-53/+172
| | | | | | | | | | | | This is in reference to a [feature request](https://github.com/nim-lang/Nim/issues/22142) that I posted. I'm making this PR to demonstrate the suggested change and expect that this should be scrutinized --------- Co-authored-by: Bung <crc32@qq.com> Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* fixes #23167; take `nkOpenSymChoice` into consideration caused by templates ↵ringabout2024-01-051-0/+5
| | | | | [backport] (#23168) fixes #23167
* ambiguous identifier resolution (#23123)metagn2024-01-0110-8/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes #23002, fixes #22841, refs comments in #23097 When an identifier is ambiguous in scope (i.e. multiple imports contain symbols with the same name), attempt resolving it through type inference (by creating a symchoice). To do this efficiently, `qualifiedLookUp` had to be broken up so that `semExpr` can access the ambiguous candidates directly (now obtained directly via `lookUpCandidates`). This fixes the linked issues, but an example like: ```nim let on = 123 {.warning[ProveInit]: on.} ``` will still fail, since `on` is unambiguously the local `let` symbol here (this is also true for `proc on` but `proc` symbols generate symchoices anyway). Type symbols are not considered to not confuse the type inference. This includes the change in sigmatch, up to this point symchoices with nonoverloadable symbols could be created, they just wouldn't be considered during disambiguation. Now every proper symbol except types are considered in disambiguation, so the correct symbols must be picked during the creation of the symchoice node. I remember there being a violating case of this in the compiler, but this was very likely fixed by excluding type symbols as CI seems to have found no issues. The pure enum ambiguity test was disabled because ambiguous pure enums now behave like overloadable enums with this behavior, so we get a longer error message for `echo amb` like `type mismatch: got <MyEnum | OtherEnum> but expected T`
* fixes a typo in the test (#23140)ringabout2023-12-291-1/+1
|
* retain postfix node in type section typed AST, with docgen fix (#23101)metagn2023-12-232-1/+8
| | | | | | Continued from #23096 which was reverted due to breaking a package and failing docgen tests. Docgen should now work, but ~~a PR is still pending for the package: https://github.com/SciNim/Unchained/pull/45~~ has been merged
* add switch, warning, and `bind` support for new generic injection behavior ↵metagn2023-12-222-0/+79
| | | | | | | | | | | | | | | | | | | | | (#23102) refs #23091, especially post merge comments Unsure if `experimental` and `bind` are the perfect constructs to use but they seem to get the job done here. Symbol nodes do not get marked `nfOpenSym` if the `bind` statement is used for their symbol, and `nfOpenSym` nodes do not get replaced by new local symbols if the experimental switch is not enabled in the local context (meaning it also works with `push experimental`). However this incurs a warning as the fact that the node is marked `nfOpenSym` means we did not `bind` it, so we might want to do that or turn on the experimental switch if we didn't intend to bind it. The experimental switch name is arbitrary and could be changed. --------- Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* Don't crash for invalid toplevel parseStmt/Expr calls (#23089)Jake Leahy2023-12-191-0/+15
| | | | | | | | | | | | | | | This code will crash `check`/`nimsuggest` since the `ra` register is uninitialised ```nim import macros static: discard parseExpr("'") ``` Now it assigns an empty node so that it has something Testament changes were so I could properly write a test. It would pass even with a segfault since it could find the error
* Revert "retain postfix node in type section typed AST" (#23098)metagn2023-12-192-8/+1
| | | Reverts nim-lang/Nim#23096
* retain postfix node in type section typed AST (#23096)metagn2023-12-182-1/+8
| | | fixes #22933
* allow replacing captured syms in macro calls in generics (#23091)metagn2023-12-181-0/+86
| | | | | | | | | | | | | | | | | | fixes #22605, separated from #22744 This marks symbol captures in macro calls in generic contexts as `nfOpenSym`, which means if there is a new symbol in the local instantiatied body during instantiation time, this symbol replaces the captured symbol. We have to be careful not to consider symbols outside of the instantiation body during instantiation, because this will leak symbols from the instantiation context scope rather than the original declaration scope. This is done by checking if the local context owner (maybe should be the symbol of the proc currently getting instantiated instead? not sure how to get this) is the same as or a parent owner of the owner of the replacement candidate symbol. This solution is distinct from the symchoice mechanisms which we originally assumed had to be related, if this assumption was wrong it would explain why this solution took so long to arrive at.
* Mark `macros.error` as `.noreturn.` (#23081)Jake Leahy2023-12-172-0/+18
| | | | | | | | | | | | | | | Closes #14329 Marks `macros.error` as `.noreturn` so that it can be used in expressions. This also fixes the issue that occurred in #19659 where a stmt that could be an expression (Due to having `discardable` procs at the end of other branches) would believe a `noreturn` proc is returning the same type e.g. ```nim proc bar(): int {.discardable.} = discard if true: bar() else: quit(0) # Says that quit is of type `int` and needs to be used/discarded except it actually has no return type ```
* Allow `parseAll` to parse statements separated by semicolons (#23088)Jake Leahy2023-12-171-0/+4
| | | | | | | | | | | | | | | | | | Fixes the second issue listed in #9918. Fixed by replacing the logic used in `parseAll` with just a continious loop to `complexOrSimpleStmt` like what the [normal parser does](https://github.com/nim-lang/Nim/blob/devel/compiler/passes.nim#L143-L146). `complexOrSimpleStmt` [guarantees progress](https://github.com/nim-lang/Nim/blob/devel/compiler/parser.nim#L2541) so we don't need to check progress ourselves. Also allows `nimpretty` to parse more valid Nim code such as ```nim proc foo(); # Would complain about indention here # ... proc foo() = # ... ```
* rationals: support Rational[SomeUnsignedInt] (#23046)shirleyquirk2023-12-151-0/+9
| | | | | | | | fixes #22227 rationale: - `3u - 4u` is supported why not`3u.toRational - 4u.toRational` - all of rationals' api is on SomeInteger, looks like unsigned is declared as supported - math on unsigned rationals is meaningful and useful.
* Param match relax (#23033)Ryan McConnell2023-12-155-2/+59
| | | | | | | | | | | #23032 --------- Co-authored-by: Nikolay Nikolov <nickysn@gmail.com> Co-authored-by: Pylgos <43234674+Pylgos@users.noreply.github.com> Co-authored-by: Andreas Rumpf <rumpf_a@web.de> Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com> Co-authored-by: Jason Beetham <beefers331@gmail.com>
* Overloads passed to static proc parameters now convert to the desired… ↵Jason Beetham2023-12-141-1/+8
| | | | | (#23063) … type mirroring proc params
* type graph refactor; part 3 (#23064)Andreas Rumpf2023-12-141-16/+0
|
* fixes #9381; Fix double evaluation of types in generic objects (#23072)Pylgos2023-12-141-0/+14
| | | fixes https://github.com/nim-lang/Nim/issues/9381
* fixes #23060; `editDistance` wrongly compare the length of rune strings (#23062)ringabout2023-12-131-0/+5
| | | fixes #23060
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-06-08 17:12:36 +0000