summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* Make `data-theme` default to "auto" in HTML (#23222)Jake Leahy2024-01-1913-13/+13
| | | | | | | | | Makes docs default to using browser settings instead of light mode This should fix #16515 since it doesn't require the browser to run the JS to set the default Also means that dark mode can be used without JS if the browser is configured to default to dark mode
* Fixing overload resolution documentation (#23171)Ryan McConnell2024-01-191-22/+64
| | | As requested. Let me know where adjustments are wanted.
* fix mime types data (#23226)Bung2024-01-192-1725/+854
| | | | | | generated via https://github.com/bung87/mimetypes_gen source data: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?view=co
* Make std/math classify work without `--passc:-fast-math`. (#23211)Angel Ezquerra2024-01-181-3/+2
| | | | By using the existing isNaN function we can make std/math's classify function work even if `--passc:-fast-math` is used.
* fixes #22218; avoids cursor when copy is disabled (#23209)ringabout2024-01-182-1/+28
| | | fixes #22218
* fixes #12334; keeps `nkHiddenStdConv` for cstring conversions (#23216)ringabout2024-01-182-0/+12
| | | | | | fixes #12334 `nkHiddenStdConv` shouldn't be removed if the sources aren't literals, viz. constant symbols.
* Nim Compiler User Guide: Add explanations about lto and strip (#23227)Tomohiro2024-01-181-3/+10
|
* fix wrong subtype relation in tuples & infer some conversions (#23228)metagn2024-01-184-3/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-182-3/+24
| | | | | | | | | | 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.
* workaround arrayWith issues (#23230)ringabout2024-01-181-1/+2
| | | I'm working on it, but it's quite tricky. I will fix it soon
* fix(#23231): add nimdoc.cls to installer script (#23232)daylin2024-01-181-1/+1
| | | | | | Change to `compiler/installer.ini` to add `nimdoc.cls` to files copied by installer script. Closes #23231
* give typedesc param nodes type T not typedesc[T] [backport:2.0] (#23115)metagn2024-01-183-3/+15
| | | | | | | 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-182-2/+22
| | | | | | 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.
* Add `^` operator support for Rational numbers (#23219)Angel Ezquerra2024-01-181-0/+20
| | | | Since pow() cannot be supported for rationals, we support negative integer exponents instead.
* fixes #23223; prevents `insert` self-assignment (#23225)ringabout2024-01-182-0/+9
| | | fixes #23223
* don't use previous bindings of `auto` for routine return types (#23207)metagn2024-01-1710-53/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* + 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`.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-07-21 09:37:26 +0000