summary refs log tree commit diff stats
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* fixes #12703; nim cpp rejects valid code would lose const qualifier for ↵ringabout2024-03-051-4/+15
| | | | | | cstring to string via cstrToNimstr (#23371) fixes #12703 ref #19588
* fixes #20945; fixes #18262; provides C API `NimDestroyGlobals` for ↵ringabout2024-03-041-0/+23
| | | | | | | | | static/dynlib libraries (#23357) fixes #20945 fixes #18262 todo - [ ] perhaps export with lib prefix when the option is enabled
* Dont mangle when targeting cpp (#23335)Juan M Gómez2024-03-031-1/+1
| | | | Unfortunately we cant trick the debugger when targeting C++ so this one also needs to wait for our own debugger adapter.
* Fix nimsuggest highlight for import statements (#23263)autumngray2024-03-031-1/+9
| | | | | | | | | | | Currently, I don't have syntax highlighting (+ no/wrong jump-to-definition) for some import statement forms, namely: - `import module/name/with/(slashes)` - `import (mod) as alias` - `import basemod/[ (sub1), (sub2) ]` With this patch, highlight/def will work for the regions indicated by parentheses.
* fixes #23273; forbids methods having importc pragmas (#23324)ringabout2024-03-031-0/+4
| | | fixes #23273
* fixes sink regression for ORC; ref #23354 (#23359)ringabout2024-03-032-2/+3
| | | | | | | | | ref #23354 The new move analyzer requires types that have the tfAsgn flag (otherwise `lastRead` will return true); tfAsgn is included when the destructor is not trival. But it should consider the assignement for objects in this case because objects might have a trival destructors but it's the assignement that matters when it is passed to sink parameters.
* fixes #13481; fixes #22708; disable using union objects in VM (#23362)ringabout2024-03-031-0/+2
| | | | | | fixes #13481; fixes #22708 Otherwise it gives implicit results or bad codegen
* make use of C++11's auto type deduction for temporary variables (#23327)heterodoxic2024-03-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is just one of those tiny steps towards the goal of an "optimized" C and C++ codegen I raised elsewhere before - what does me babbling "optimized" mainly entail? (not mutually-exclusive ascertainment proposals following:) - less and simplified resulting code: easier to pick up/grasp for the C/C++ compiler for to do its own optimization heuristics, less parsing effort for us mere humans trying to debug, especially in the case of interop - build time reduction: less code emission I/O, runtime string formatting for output... - easier access for fresh contributors and better maintainability - interop improvements - further runtime optimizations I am eagerly looking forward to the results of the LLVM-based undertakings, but I also think we can do a bit better (as outlined above) with our current C/C++ backends till those come to fruition. **Long story short**: this PR here focuses on the C++ backend, augmenting the current codegen method of establishing "temporary" variables by using C++11's auto type deduction. The reasons for adopting an "Almost Always Auto" style have been collected [here ](https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/) for the C++ world. For those hopping between C++'s and Nim's realms, this change also results in a bit less code and less work for the codegen part (no redundant `getTypeDesc`s): no need to tell the C++ compiler the type it already knows of (in most cases).
* fixes an issue with string to 'var openArray' at compile-time; [backp… ↵Andreas Rumpf2024-03-032-21/+26
| | | | | (#23363) …ort]
* improve error messages [backport] (#23345)ringabout2024-02-261-34/+79
| | | | | | ref https://forum.nim-lang.org/t/11052 ![image](https://github.com/nim-lang/Nim/assets/43030857/1df87691-32d9-46b5-b61b-6b9f7cc94862)
* fixes #23306 nim cpp -r invalid code generation regression with closure ↵Juan M Gómez2024-02-261-2/+2
| | | | iterators and try/catch-like constructions (#23317)
* * fixed nimsuggest crash with 'Something = concept' put (erroneously) ↵Nikolay Nikolov2024-02-241-1/+1
| | | | outside of a 'type' block (#23331)
* fixes #22723; skips tyUserTypeClasses in injectdestructors (#23341)ringabout2024-02-241-9/+10
| | | fixes #22723
* compiler/ast.nim: fix a typo (#23340)litlighilit2024-02-231-1/+1
| | | | | | | constains -> constrains --------- Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
* Fixes #23337; When NimScript errors prevents NimSuggest from Init (#23338)Juan M Gómez2024-02-221-1/+5
|
* * fixed nimsuggest crash when opening a .nim file, that contain a {.fatal: ↵Nikolay Nikolov2024-02-201-1/+2
| | | | "msg".} pragma. (#23325)
* `varargs[typed]` should behave more like `typed` (#23303)Ryan McConnell2024-02-201-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes an oversight with a change that I made a while ago. Basically, these two snippets should both compile. Currently the `varargs` version will fail. ```nim template s(d: typed)=discard proc something()=discard proc something(x:int)=discard s(something) ``` ```nim template s(d: varargs[typed])=discard proc something()=discard proc something(x:int)=discard s(something) ``` Potentially unrelated, but this works currently for some reason: ```nim template s(a: varargs[typed])=discard proc something()=discard proc something(x:int)=discard s: something ``` also, this works: ```nim template s(b:untyped, a: varargs[typed])=discard proc something()=discard proc something(x:int)=discard s (g: int): something ``` but this doesn't, and the error message is not what I would expect: ```nim template s(b:untyped, a: varargs[typed])=discard proc something()=discard proc something(x:int)=discard s (g: int), something ``` So far as I can tell, none of these issues persist for me after the code changes in this PR.
* Fixes a nimsuggest crash when using chronos (#23293)Juan M Gómez2024-02-202-2/+5
| | | | | | | | | | | | | | | The following would crash nimsuggest on init: ```nim import chronos type HistoryQuery = object start: int limit: int HistoryResult = object messages: string type HistoryQueryHandler* = proc(req: HistoryQuery): Future[HistoryResult] {.async, gcsafe.} ```
* fixes #23295; don't expand constants for complex structures (#23297)ringabout2024-02-201-2/+1
| | | fixes #23295
* assume a module's usage if it contains a passC/passL/compile pragma w… ↵heterodoxic2024-02-191-1/+8
| | | | | | | | | | | | | | | | | | | | | (#23323) …hich conveys effects beyond its module scope for C/C++ codegen(suppresses current UnusedImport warning) Just a minor inconvenience working in the area of C/C++ integration I guess, but here we go: I noticed receiving ```UnusedImport``` warnings for modules having only ```passC```/```passL```/```compile``` pragmas around. I gather the compiler cannot actually infer those modules being unused as they *may* have consequences for the whole build process (as they did in my simple case). Thus, I hereby suggest adding the `sfUsed` flag to the respective module in order to suppress the compiler's warning. I reckon other pragmas should be put into consideration as well: I will keep up the investigation with PR followups.
* fixes refc with non-var destructor; cancel warnings (#23156)ringabout2024-02-131-3/+13
| | | fixes https://forum.nim-lang.org/t/10807
* fixes #18104; tranform one liner var decl before templates expansion (#23294)ringabout2024-02-131-0/+18
| | | fixes #18104
* fixes a nimsuggest crash on init (#23300)Juan M Gómez2024-02-111-1/+1
|
* nimsuggest --ic:on compiles (#23298)Juan M Gómez2024-02-091-0/+1
|
* MangleProcs following the Itanium spec so they are demangled in the debugger ↵Juan M Gómez2024-02-093-6/+84
| | | | | | | | | 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 regression #23280; Operations on inline toOpenArray len return a wrong ↵ringabout2024-02-061-3/+3
| | | | | result (#23285) fixes #23280
* fixes regression #22909; don't optimize result init if statements can raise ↵ringabout2024-02-011-9/+19
| | | | | | | | | | | | | | | | 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
* compute checksum of nim files early in the pipelines (#23268)ringabout2024-01-315-8/+25
| | | | related https://github.com/nim-lang/Nim/issues/21717 configs will be resolved later
* minor fixes for std prefix in the compiler (#23269)ringabout2024-01-301-2/+2
|
* fixes #19977; rework inlining of 'var openarray' iterators for C++ (#23258)ringabout2024-01-261-1/+2
| | | fixes #19977
* fixes #23247; don't destroy openarray since it doesn't own the data (#23254)ringabout2024-01-261-2/+7
| | | | | | | | | | | | | | | | | | | | | | | 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 #23085: update grammars for 'concept' (#23256)Silly Carbon2024-01-261-2/+3
| | | Fixes #23085
* fixes #22597; avoid side effects for call returning openArray types (#23257)ringabout2024-01-263-6/+18
| | | | | | | | | | | | | | 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-1/+2
| | | | | | | assertion (#23242) Closes #23240 Fixes regression caused by #23017
* account for nil return type in tyProc sumGeneric (#23250)metagn2024-01-231-1/+2
| | | fixes #23249
* fixes #23233; Regression when using generic type with Table/OrderedTable ↵ringabout2024-01-191-1/+1
| | | | | (#23235) fixes #23233
* fixes #22218; avoids cursor when copy is disabled (#23209)ringabout2024-01-181-1/+3
| | | fixes #22218
* fixes #12334; keeps `nkHiddenStdConv` for cstring conversions (#23216)ringabout2024-01-181-0/+2
| | | | | | 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-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+6
| | | | | | | | | | 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.
* 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-181-1/+1
| | | | | | | 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-2/+2
| | | | | | 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.
* don't use previous bindings of `auto` for routine return types (#23207)metagn2024-01-173-43/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-152-4/+20
| | | | don't have an explicit `.raises` pragma (#23193)
* fixes #23180; fixes #19805; prohibits invalid tuple unpacking code in for ↵ringabout2024-01-131-1/+4
| | | | | | loop (#23185) fixes #23180 fixes #19805
* fixes #15924; Tuple destructuring is broken with closure iterators (#23205)ringabout2024-01-131-5/+8
| | | fixes #15924
* fixes #22923; fixes `=dup` issues (#23182)ringabout2024-01-113-1/+21
| | | fixes #22923
* fixes #23129; fixes generated hooks raise unlisted Exception, which never ↵ringabout2024-01-111-1/+6
| | | | | raise (#23195) fixes #23129
* delay resolved procvar check for proc params + acknowledge unresolved ↵metagn2024-01-113-17/+33
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-07-12 05:39:42 +0000