summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* + show the inferred exception list (as part of the type) for functions that ↵Nikolay Nikolov2024-01-1514-43/+59
| | | | don't have an explicit `.raises` pragma (#23193)
* remove unnecessary workaround from `arrayWith` (#23208)ringabout2024-01-151-2/+1
| | | The problem was fixed by https://github.com/nim-lang/Nim/pull/23195
* fixes #23180; fixes #19805; prohibits invalid tuple unpacking code in for ↵ringabout2024-01-132-3/+6
| | | | | | loop (#23185) fixes #23180 fixes #19805
* fixes #15924; Tuple destructuring is broken with closure iterators (#23205)ringabout2024-01-132-5/+26
| | | fixes #15924
* fix link to `jsfetch` stdlib (#23203)Ethosa2024-01-121-1/+1
|
* patches for #23129 (#23198)ringabout2024-01-111-1/+1
| | | fixes it in the normal situation
* document the new ambiguous identifier resolution (#23166)metagn2024-01-114-4/+59
| | | | | refs #23123 Not sure if detailed enough.
* fixes #22923; fixes `=dup` issues (#23182)ringabout2024-01-115-2/+49
| | | fixes #22923
* fixes #23129; fixes generated hooks raise unlisted Exception, which never ↵ringabout2024-01-112-1/+22
| | | | | raise (#23195) fixes #23129
* delay resolved procvar check for proc params + acknowledge unresolved ↵metagn2024-01-118-23/+196
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Nim manual: better byref pragma explanation (#23192)Tomohiro2024-01-091-2/+56
| | | | | | | | | | | | | | Nim manual says: > When using the Cpp backend, params marked as byref will translate to cpp references `&` But how `byref` pragma translate to depends on whether it is used with `importc` or `importcpp`. When `byref` pragma used with `importc` types and compiled with the Cpp backend, it is not traslated to cpp reference `&`. --------- Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* Docs:strutils. Expand `multiReplace` docs, add runnableExamples (#23181)Zoom2024-01-081-7/+20
| | | | | | | | | - Clarified the implications of order of operation. - Mentioned overlapping isn't handled - Added the runnableExamples block Fixes #23160, which supposedly should have been fixed in an earlier PR #23022, but the wording was still not clear enough to my liking, which the raised issue kind of confirms.
* trigger range check with new type inference on nkIntLit [backport:1.6] (#23179)metagn2024-01-082-2/+11
| | | | | | | | | | | | 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-072-14/+63
| | | | | | | | | | | | | | 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-063-1/+16
| | | #23172
* fixes #23139; Cannot get repr of range type of enum (#23164)ringabout2024-01-052-1/+6
| | | fixes #23139
* Changing generic weight of `tyGenericParam` (#22143)Ryan McConnell2024-01-0511-89/+237
| | | | | | | | | | | | 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-052-6/+15
| | | | | [backport] (#23168) fixes #23167
* Recommend hanging indent in NEP1 (#23105)Jacek Sieka2024-01-031-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR modernises the NEP1 style guide to prefer hanging indent over vertial alignment for long code statements while still allowing alignment in legacy code. The change is based on research and study of existing style guides for both braced and indented languages that have seen wide adoption as well as working with a large Nim codebase with several teams touching the same code regularly. The research was done as part of due diligence leading up to [nph](https://github.com/arnetheduck/nph) which uses this style throughout. There are several reasons why hanging indent works well for collaboration, good code practices and modern Nim features: * as NEP1 itself points out, alignment causes unnecessary friction when refactoring, adding/removing items to lists and otherwise improving code style or due to the need for realignment - the new recommendation aligns NEP1 with itself * When collaborating, alignment leads to unnecessary git conflicts and blame changes - with hanging indent, such conflicts are minimised. * Vertical alignment pushes much of the code to the right where often there is little space - when using modern features such as generics where types may be composed of several (descriptively named) components, there is simply no more room for parameters or comments * The space to the left of the alignemnt cannot productively be used for anything (unlike on the right, where comments may be placed) * Double hanging indent maintaines visual separation between parameters / condition and the body that follows. This may seem like a drastic change, but in reality, it is not: * the most popular editor for Nim (vscode) already promotes this style by default (if you press enter after `(`, it will jump to an indent on the next line) * although orthogonal to these changes, tools such as `nph` can be used to reformat existing code should this be desired - when done in a single commit, `git blame` is not lost and neither are exsting PRs (they can simply be reformatted deterministically) - `nph` is also integrated with vscode. * It only affects long lines - ie most code remains unchanged Examples of vertical alignment in the wild, for wildly successful languages and formatters: * [PEP-8](https://peps.python.org/pep-0008/#indentation) * [black](https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#how-black-wraps-lines) * [prettier](https://prettier.io/docs/en/) The above examples are useful mainly to show that hanging-indent _generally_ is no impediment to efficient code reading and on the whole is an uncontroversial choice as befits the standard library.
* Deprecate asm stmt for js target (#23149)ASVIEST2024-01-0211-114/+121
| | | | | | | | | | | | | | | | | | | | | | | why ? - We already have an emit that does the same thing - The name asm itself is a bit confusing, you might think it's an alias for asm.js or something else. - The asm keyword is used differently on different compiler targets (it makes it inexpressive). - Does anyone (other than some compiler libraries) use asm instead of emit ? If yes, it's a bit strange to use asm somewhere and emit somewhere. By making the asm keyword for js target deprecated, there would be even less use of the asm keyword for js target, reducing the amount of confusion. - New users might accidentally use a non-universal approach via the asm keyword instead of emit, and then when they learn about asm, try to figure out what the differences are. see https://forum.nim-lang.org/t/10821 --------- Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* fixes #23148; restricts infix path concatenation to what starts with `/` ↵ringabout2024-01-021-5/+8
| | | | | (#23150) fixes #23148
* ambiguous identifier resolution (#23123)metagn2024-01-0113-71/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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`
* `typRel` and `sumGeneric` adjustments (#23137)Ryan McConnell2023-12-311-54/+46
| | | | | | | | | | Filling in some more logic in `typeRel` that I came across when poking the compiler in another PR. Some of the cases where `typeRel` returns an "incorrect" result are actually common, but `sumGeneric` ends up breaking the tie correctly. There isn't anything wrong with that necessarily, but I assume that it's preferred these functions behave just as well in isolation as they do when integrated. I will be following up this description with specific examples.
* fixes wrong indentation (#23145)ringabout2023-12-311-104/+104
| | | 4 spaces => 2 spaces
* Update copyright year 2024 (#23144)ringabout2023-12-313-3/+3
|
* Fix typo in pegs.nim (#23143)Ikko Eltociear Ashimine2023-12-301-3/+3
| | | wether -> whether
* Adds info:capabilities to NimSuggest (#23134)Juan M Gómez2023-12-291-0/+8
|
* fixes a typo in the test (#23140)ringabout2023-12-291-1/+1
|
* Fix cmpRunesIgnoreCase on system where sizeof(int) < 4. Fixes #23125. (#23138)Gianmarco2023-12-281-1/+6
| | | | | | | Fixes an issue where importing the `strutils` module, or any other importing the `strutils` module, ends up with a compile time error on platforms where ints are less then 32-bit wide. The fix follows the suggestions made in #23125.
* Asm syntax pragma (#23119)ASVIEST2023-12-254-15/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | (Inspired by this pragma in nir asm PR) `inlineAsmSyntax` pragma allowing specify target inline assembler syntax in `asm` stmt. It prevents compiling code with different of the target CC inline asm syntax, i.e. it will not allow gcc inline asm code to be compiled with vcc. ```nim proc nothing() = asm {.inlineAsmSyntax: "gcc".} """ nop """ ``` The current C(C++) backend implementation cannot generate code for gcc and for vcc at the same time. For example, `{.inlineAsmSyntax: "vcc".}` with the ICC compiler will not generate code with intel asm syntax, even though ICC can use both gcc-like asm and vcc-like. For implement support for gcc and for vcc at the same time in ICC compiler, we need to refactor extccomp --------- Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* CI entry may be reset to default (#23127)Ryan McConnell2023-12-251-1/+1
|
* make `-d:debugHeapLinks` compile again (#23126)ringabout2023-12-241-4/+6
| | | | | I have made `realloc` absorb unused adjacent memory, which improves the performance. I'm investigating whether `deallocOsPages` can be used to improve memory comsumption.
* fix spurious indent and newlines in rendering of nkRecList (#23121)metagn2023-12-245-20/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rendering of `nkRecList` produces an indent and adds a new line at the end. However for things like case object `of`/`else` branches or `when` branches this is already done, so this produces 2 indents and an extra new line. Instead, just add an indent in the place where the indent that `nkRecList` produces is needed, for the rendering of the final node of `nkObjectTy`. There doesn't seem to be a need to add the newline. Before: ```nim case x*: bool of true: y*: int of false: nil ``` After: ```nim case x*: bool of true: y*: int of false: nil ```
* Add `toSinglyLinkedRing` and `toDoublyLinkedRing` to `std/lists` (#22952)Eric N. Vander Weele2023-12-242-0/+23
| | | | Allow for conversion from `openArray`s, similar to `toSinglyLinkedList` and `toDoublyLinkedList`.
* retain postfix node in type section typed AST, with docgen fix (#23101)metagn2023-12-236-25/+65
| | | | | | 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-228-6/+176
| | | | | | | | | | | | | | | | | | | | | (#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>
* makes nimsuggest `con` work under v3 (#23113)Juan M Gómez2023-12-222-3/+19
| | | Co-authored-by: Jake Leahy <jake@leahy.dev>
* document `--experimental:vtables` (#23111)ringabout2023-12-211-0/+35
|
* fixes nimdoc warnings (#23110)ringabout2023-12-211-1/+1
|
* update action versions (#23109)ringabout2023-12-213-4/+4
|
* update mac CI to macos 12 (#23108)metagn2023-12-212-3/+3
| | | | | | closes #23107 Could also change to `macos-latest` but nothing else in CI uses `latest` OS versions.
* Don't crash for invalid toplevel parseStmt/Expr calls (#23089)Jake Leahy2023-12-193-4/+27
| | | | | | | | | | | | | | | 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
* fixes strictnotnil for func, method, converter (#23083)ringabout2023-12-191-1/+1
|
* fixes #18073; fixes #14730; document notnil is only applied to local … ↵ringabout2023-12-191-3/+7
| | | | | | | | (#23084) …symbols fixes #18073 fixes #14730
* allow non var deinit for locks and conds: alternative way (#23099)ringabout2023-12-193-17/+17
| | | alternative to https://github.com/nim-lang/Nim/pull/23092
* Revert "retain postfix node in type section typed AST" (#23098)metagn2023-12-194-29/+5
| | | Reverts nim-lang/Nim#23096
* retain postfix node in type section typed AST (#23096)metagn2023-12-184-5/+29
| | | fixes #22933
* add tuple unpacking changes to changelog (#23093)metagn2023-12-181-0/+19
| | | | | | closes #23042 Adds changes from #22537 and #22611 to changelog (I believe both are set for 2.2).
* allow replacing captured syms in macro calls in generics (#23091)metagn2023-12-185-7/+126
| | | | | | | | | | | | | | | | | | 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.
* Fix grammar (#23090)Stephen2023-12-181-1/+1
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-06-06 21:55:25 +0000