summary refs log tree commit diff stats
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
* + added nimsuggest support for exception inlay hints (#23202)Nikolay Nikolov2024-03-155-22/+324
| | | | | | | | | | | | | | | | | This adds nimsuggest support for displaying inlay hints for exceptions. An inlay hint is displayed around function calls, that can raise an exception, which isn't handled in the current subroutine (in other words, exceptions that can propagate back to the caller). On mouse hover on top of the hint, a list of exceptions that could propagate is shown. The changes, required to support this are already commited to nimlangserver and the VS code extension. The extension and the server allow configuration for whether these new exception hints are enabled (they can be enabled or disabled independently from the type hints), as well as the inlay strings that are inserted before and after the name of the function, around the function call. Potentially, one of these strings can be empty, for example, the user can choose to add an inlay hint only before the name of the function, or only after the name of the function.
* refactoring: no inheritance for PType/PSym (#23403)Andreas Rumpf2024-03-1414-253/+106
|
* propagate efWantStmt in semWhen (#23400)metagn2024-03-141-3/+4
| | | | | | | | fixes #23399 The new case introduced in #21657 is triggered by `efWantStmt` but the `when` statement doesn't normally propagate this flag, so propagate it when the `semCheck` param in `semWhen` is true which happens when the `when` statement is `efWhenStmt` anyway.
* fixes #23382; gives compiler errors for closure iterators in JS (#23398)ringabout2024-03-141-1/+3
| | | | fixes #23382 follow up https://github.com/nim-lang/Nim/pull/15823
* Fixes an issue where exported types werent being cgen with the `exportc` ↵Juan M Gómez2024-03-111-4/+7
| | | | pragma (#23369)
* [C++] Allow `member` to define static funcs (#23387)Juan M Gómez2024-03-111-4/+9
|
* fixes #22284; fixes #22282; don't override original parameters of inferred ↵ringabout2024-03-091-1/+0
| | | | | | | | | | | | | | | | | lambdas (#23368) fixes #22284 fixes #22282 ``` Error: j(uRef, proc (config: F; sources: auto) {.raises: [].} = discard ) can raise an unlisted exception: Exception ``` The problem is that `n.typ.n` contains the effectList which shouldn't appear in the parameter of a function defintion. We could not simply use `n.typ.n` as `n[paramsPos]`. The effect lists should be stripped away anyway.
* fixes #23378; fixes js abs negative int64 (#23379)ringabout2024-03-091-1/+7
| | | fixes #23378
* 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)`.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-07-18 11:15:31 +0000