Commit Graph

8188 Commits

Author SHA1 Message Date
ringabout
dd2edf4562 allows foreign functions having forward decls 2024-07-12 22:35:17 +08:00
ringabout
ca7821bea3 fixes 23827; Cyclic proc calls causes infinite memory usage in VM 2024-07-12 22:10:11 +08:00
Ryan McConnell
22ba5abd63 fixes 23823; array static overload - again (#23824)
#23823
2024-07-11 22:57:17 +02:00
ringabout
173b8a8c58 fixes #3011; handles meta fields defined in the ref object (#23818)
fixes #3011

In https://github.com/nim-lang/Nim/pull/23532, meta fields that defined
in the object are handled.

In this PR, RefObjectTy is handled as well:
```nim
type
  Type = ref object 
    context: ref object
```
Ref alias won't trigger mata fields checking so there won't have
cascaded errors on `TypeBase`.

```nim
type
  TypeBase = object 
    context: ref object
  Type = ref TypeBase 
    context: ref object
```
2024-07-11 15:39:44 +02:00
ringabout
e53a2ed19b fixes #20865; fixes #20987; Missing bounds check in array slicing (#23814)
fixes #20865
fixes #20987
2024-07-10 17:25:34 +02:00
ringabout
5c5e7a9b6e fixes #22389; fixes #19840; don't fold paths containing addr (#23807)
fixes #22389;
fixes #19840
2024-07-09 12:59:21 +02:00
ringabout
732f7752a9 remove nir; succeeded by nif (#23809)
ref https://github.com/nim-lang/nif
2024-07-09 09:29:45 +02:00
Andrew Brower
dc46350fa1 Add support for nvcc & hipcc (cuda/rocm) (#23805)
I've been working on making some basic cuda examples work, both with
cuda (nvcc) and with AMD HIP (hipcc) https://github.com/monofuel/hippo

- hipcc is just a drop-in replacement for clang and works out of the box
with clang settings in Nim. hipcc is capable of compiling for AMD ROCm
or to CUDA, depending on how HIP_PLATFORM is set.
- nvcc is a little quirky. we can use `-x cu` to tell it to handle nim's
`.cpp` files as if they were `.cu` files. nvcc expects all backend
compiler flags to be wrapped with a special `-Xcompiler=""` flag when
compiling and also when linking.

I manually tested on a linux desktop with amd and a laptop with nvidia.
2024-07-08 11:17:04 +02:00
Alexander Kernozhitsky
1dcc364cd2 [backport] fixes #23796; remove extra indirection for args in importc'ed functions in cpp (#23800)
fixes #23796
2024-07-06 23:10:15 +02:00
Alexander Kernozhitsky
841d30a213 fixes #23790; roll back instCounter properly in case of exceptions (#23802)
fixes #23790
2024-07-06 22:50:46 +02:00
Yuriy Glukhov
05df263b84 Optimize closure iterator locals (#23787)
This pr redefines the relation between lambda lifting and closureiter
transformation.

Key takeaways:
- Lambdalifting now has less distinction between closureiters and
regular closures. Namely instead of lifting _all_ closureiter variables,
it lifts only those variables it would also lift for simple closure,
i.e. those not owned by the closure.
- It is now closureiter transformation's responsibility to lift all the
locals that need lifting and are not lifted by lambdalifting. So now we
lift only those locals that appear in more than one state. The rest
remains on stack, yay!
- Closureiter transformation always relies on the closure env param
created by lambdalifting. Special care taken to make lambdalifting
create it even in cases when it's "too early" to lift.
- Environments created by lambdalifting will contain `:state` only for
closureiters, whereas previously any closure env contained it.

IMO this is a more reasonable approach as it simplifies not only
lambdalifting, but transf too (e.g. freshVarsForClosureIters is now gone
for good).

I tried to organize the changes logically by commits, so it might be
easier to review this on per commit basis.

Some ugliness:
- Adding lifting to closureiters transformation I had to repeat this
matching of `return result = value` node. I tried to understand why it
is needed, but that was just another rabbit hole, so I left it for
another time. @Araq your input is welcome.
- In the last commit I've reused currently undocumented `liftLocals`
pragma for symbols so that closureiter transformation will forcefully
lift those even if they don't require lifting otherwise. This is needed
for [yasync](https://github.com/yglukhov/yasync) or else it will be very
sad.

Overall I'm quite happy with the results, I'm seeing some noticeable
code size reductions in my projects. Heavy closureiter/async users,
please give it a go.
2024-07-03 22:49:30 +02:00
ringabout
051a536275 fixes #23784; don't allow fold paths containing nkAddr (#23792)
fixes #23784

notes that before https://github.com/nim-lang/Nim/pull/23477, it didn't
fold paths containing `addr`/`unsafeAddr` because it retained the form
of the magic function: `mAddr`.
2024-07-03 22:48:19 +02:00
ringabout
fe3039410f fixes #23775; injectdestructors now handles discardable statements (#23780)
fixes #23775
2024-07-02 08:49:37 +02:00
Ryan McConnell
27abcdd57f fixes #23755; array static inference during overload resolution (#23760)
#23755

---------

Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
2024-07-01 14:39:16 +02:00
Alexander Kernozhitsky
4202b606b1 [backport] fixes #23748; do not skip materializing temporaries for proc arguments (#23769)
fixes #23748
2024-06-30 14:10:10 +02:00
ringabout
56ed4e0bb9 fixes #23759; rework move for refc (#23764)
fixes #23759
2024-06-29 10:43:41 +02:00
ringabout
828cd58d8a fixes #9940; genericAssign does not take care of the importC variables in refc [backport] (#23761)
fixes #9940
2024-06-26 18:24:51 +02:00
metagn
948fc29bb2 adapt semOpAux to opt-in symchoices (#23750)
fixes #23749, refs #22716

`semIndirectOp` is used here because of the callback expressions, in
this case `db.getProc(...)`, and `semIndirectOp` calls `semOpAux` to
type its arguments before overloading starts. Hence it can opt in to
symchoices since overloading will resolve them.
2024-06-25 15:49:43 +02:00
ringabout
646bd99d46 [backport] fixes #23711; C code contains backtick`gensym (#23716)
fixes #23711
2024-06-19 08:33:38 +02:00
ringabout
9d08d26e33 adds a define nimHasJsNoLambdaLifting so we can use it in the config for compatibility (#23736) 2024-06-19 08:26:15 +08:00
Andreas Rumpf
3f1de49e26 IC: use tables instead of huge seqs because the compiler can create l… (#23737)
…ots of dummy syms and types
2024-06-18 22:41:22 +02:00
metagn
128090c593 ignore uninstantiated static on match to base type [backport:2.0] (#23731)
fixes #23730

Since #23188 the compiler errors when matching a type variable to an
uninstantiated static value. However sometimes an uninstantiated static
value is given even when only a type match is being performed to the
base type of the static type, in the given issue this case is:

```nim
proc foo[T: SomeInteger](x: T): int = int(x)
proc bar(x: static int): array[foo(x), int] = discard
discard bar(123)
```

To deal with this issue we only error when matching against a type
variable constrained to `static`.

Not sure if the `q.typ.kind == tyGenericParam and
q.typ.genericConstraint == tyStatic` check is necessary, the code above
for deciding whether the variable becomes `skConst` doesn't use it.
2024-06-18 06:54:12 +02:00
ringabout
4867931af3 implement legacy:jsNoLambdaLifting for compatibility (#23727) 2024-06-17 19:06:38 +02:00
ringabout
ae4b47c5bd fixes #20048; fixes #15746; don't sink object fields if it's of openarray type (#23608)
fixes #20048
fixes #15746
2024-06-15 16:07:49 +02:00
ringabout
948bb38335 ref #20653; fixes chronos empty case branches (#23706)
ref #20653

```nim
  Error* = object
    case kind*: ErrorType
    of ErrorA:
      discard
    of ErrorB:
      discard
```
For an object variants without fields, it shouldn't generate empty
brackets for default values since there are no fields at all in case
branches.
2024-06-14 15:55:08 +02:00
Andreas Rumpf
5996b12355 fixes a long standing bug with varargs type inference [backport] (#23720) 2024-06-14 09:16:39 +02:00
ringabout
0b5a938f57 nrvo for embedded importc'ed types (#23708) 2024-06-12 20:51:52 +02:00
ringabout
262ff648aa [backport] fixes #23690; SIGSEGV with object variants and RTTI (#23703)
fixes #23690

```nim
dest.`:state` = src.`:state`
var :tmp_553651276 = dest.e1.a
`=wasMoved`(dest.e1.a)
dest.e1.a.kind = src.e1.a.kind
case dest.e1.a.kind
of 0:
  dest.e1.a.a = src.e1.a.a
of 1:
  `=copy`(dest.e1.a.c, src.e1.a.c)
case :tmp_553651276.kind
of 0:
of 1:
  `=destroy`(:tmp_553651276.c)
```
`dest.e1.a.kind = src.e1.a.kind` changes the discrimant but it fails to
clear the memory of `dest.e1.a`. Before using hooks for copying, we need
to clear the dest, e.g. `=wasMoved(dest.e1.a.c)`.

```nim
dest.`:state` = src.`:state`
var :tmp_553651276 = dest.e1.a
`=wasMoved`(dest.e1.a)
dest.e1.a.kind = src.e1.a.kind
case dest.e1.a.kind
of 0:
  `=wasMoved`(dest.e1.a.a)
  dest.e1.a.a = src.e1.a.a
  `=wasMoved`(dest.e1.a.b)
of 1:
  `=wasMoved`(dest.e1.a.c)
  `=copy`(dest.e1.a.c, src.e1.a.c)
case :tmp_553651276.kind
of 0:
of 1:
  `=destroy`(:tmp_553651276.c)
```
2024-06-11 05:55:08 +02:00
Andreas Rumpf
8cbbe12ee4 fixes #22398; [backport] (#23704) 2024-06-10 18:43:23 +02:00
Andreas Rumpf
56c95758b2 fixes #23445; fixes #23418 [backport] (#23699) 2024-06-09 08:16:05 +02:00
Andreas Rumpf
7039b8b5bc fixes #23354; [backport] (#23685) 2024-06-07 09:01:30 +02:00
ringabout
8f5ae28fab fixes #22672; Destructor not called for result when exception is thrown (#23267)
fixes #22672
2024-06-06 11:51:41 +02:00
ringabout
2d1533f34f fixes #5901 #21211; don't fold cast function types because of gcc 14 (#23683)
follow up https://github.com/nim-lang/Nim/pull/6265

fixes #5901
fixes #21211

It causes many problems with gcc14 if we fold the cast function types.
Let's check what it will break
2024-06-05 20:54:00 +02:00
metagn
42e8472ca6 fix noreturn/implicit discard check logic (#23681)
fixes #10440, fixes #13871, fixes #14665, fixes #19672, fixes #23677

The false positive in #23677 was caused by behavior in
`implicitlyDiscardable` where only the last node of `if`/`case`/`try`
etc expressions were considered, as in the final node of the final
branch (in this case `else`). To fix this we use the same iteration in
`implicitlyDiscardable` that we use in `endsInNoReturn`, with the
difference that for an `if`/`case`/`try` statement to be implicitly
discardable, all of its branches must be implicitly discardable.
`noreturn` calls are also considered implicitly discardable for this
reason, otherwise stuff like `if true: discardableCall() else: error()`
doesn't compile.

However `endsInNoReturn` also had bugs, one where `finally` was
considered in noreturn checking when it shouldn't, another where only
`nkIfStmt` was checked and not `nkIfExpr`, and the node given for the
error message was bad. So `endsInNoReturn` now skips over
`skipForDiscardable` which no longer contains
`nkIfStmt`/`nkCaseStmt`/`nkTryStmt`, stores the first encountered
returning node in a var parameter for the error message, and handles
`finally` and `nkIfExpr`.

Fixing #23677 already broke a line in `syncio` so some package code
might be affected.
2024-06-05 20:53:05 +02:00
qiangxuhui
77c04092e0 Add linux/loongarch64 support in 'compiler/installer.ini' (#23672)
The files(like `build/build.sh`)generated by the command `koch csource`
do not contain complete `linux/loongarch64` support. This patch will fix
it.
2024-06-04 09:50:35 +02:00
ringabout
17475fc5d3 fixes openarray hoist with gcc 14 (#23647)
blocks https://github.com/nim-lang/Nim/pull/23673

---------

Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
2024-06-04 09:43:12 +02:00
ringabout
4bd1cf2376 rework ctypes with gcc 14 (#23636) 2024-06-02 15:16:44 +02:00
ringabout
a9a32ca3b8 improve view types for jsgen; eliminate unnecessary copies of view types (#23654) 2024-06-02 15:15:31 +02:00
Juan M Gómez
cb0ebecb20 #Fixes #23657 C++ compilation fails with: 'T1_' was not declared in t… (#23666)
…his scope
2024-06-02 15:15:03 +02:00
ringabout
08f1eac8ac fixes#23665; rework spawn with gcc 14 and fixes other tests (#23660)
fixes #23665
2024-06-02 11:54:39 +02:00
ringabout
c615828ccb fixes #22852; fixes #23435; fixes #23645; SIGSEGV when slicing string or seq[T] with index out of range (#23279)
follow up https://github.com/nim-lang/Nim/pull/23013

fixes #22852
fixes #23435
fixes #23645

reports rangeDefect correctly

```nim
/workspaces/Nim/test9.nim(1) test9
/workspaces/Nim/lib/system/indices.nim(116) []
/workspaces/Nim/lib/system/fatal.nim(53) sysFatal
Error: unhandled exception: value out of range: -2 notin 0 .. 9223372036854775807 [RangeDefect]
```
2024-05-27 14:13:18 +02:00
Jason Beetham
d837d32fd5 Skip tyAlias inside semTypeTraits in case a concept accidently emits one (#23640) 2024-05-23 20:15:20 +02:00
Andreas Rumpf
6cd03bae29 Minor refactoring (#23637) 2024-05-23 08:53:45 +02:00
ringabout
5cd141cebb fixes reifiedOpenArray; nkHiddenStdConv is PathKinds1 not PathKinds0 (#23633) 2024-05-22 20:38:09 +08:00
ringabout
309f97af4c fixes #23627; Simple destructor code gives invalid C (#23631)
fixes #23627

```nim
type
  TestObj = object of RootObj

  TestTestObj = object of RootObj
    testo: TestObj

proc `=destroy`(x: TestTestObj) =
  echo "Destructor for TestTestObj"

proc testCaseT() =
  echo "\nTest Case T"
  let tt1 {.used.} = TestTestObj(testo: TestObj())
```

When generating const object fields, it's likely that
we need to generate type infos for the object, which may be an object
with
custom hooks. We need to generate potential consts in the hooks first.

https://github.com/nim-lang/Nim/pull/20433 changed the semantics of
initialization. It should evaluate`BracedInit` first.
2024-05-21 14:53:08 +02:00
ringabout
b87732b5f1 fixes #16671; openarray conversion for object construction (#23618)
fixes #16671

related to https://github.com/nim-lang/Nim/pull/18911
2024-05-16 23:27:08 +02:00
PHO
0ba932132e Support NetBSD/aarch64 (#23616)
I could trivially port Nim to NetBSD/aarch64 because it already
supported NetBSD and aarch64. I only needed to generate `c_code` for
this combination.
2024-05-16 23:22:49 +02:00
ringabout
2c8551556e fixes lifting subtype calling parent's hooks (#23612)
ref https://forum.nim-lang.org/t/11587

Tested with `gcc version 14.0.1 20240412` locally
2024-05-15 20:52:18 +02:00
ringabout
0fcd838fd9 fixes openarray views default values in JS (#23607) 2024-05-14 18:07:47 +02:00
metagn
81a937ce1f ignore modules when looking up symbol with expected type (#23597)
fixes #23596

When importing a module and declaring an overloadable symbol with the
same name as the module in the same scope, the module symbol can take
over and make the declared overload impossible to access. Previously
enum overloading had a quirk that bypassed this in a context where a
specific enum type was expected but this was removed in #23588. Now this
is bypassed in every place where a specific type is expected since
module symbols don't have a type and so wouldn't be compatible anyway.

But the issue still exists in places where no type is expected like `let
x = modulename`. I don't see a way of fixing this without nerfing module
symbols to the point where they're not accessible by default, which
might break some macro code.
2024-05-14 11:26:33 +02:00