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.
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.}
```
…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.
It seems Deque doesn't need `mask` field because `data.len - 1` equals
to `mask`.
Deque without `mask` field passes test `tests/stdlib/tdeques.nim`.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
The doc for `getCurrentCompilerExe` was originally added at [this
commit](c4e3c4ca2d),
saying "`getAppFilename` at CT", and modified as "This is
`getAppFilename()`_ at compile time..." since
[this](0c2c2dca2a (diff-8ed10106605d9e0e3f28a927432acd8312e96791c96dbb126a52a7010cf4b44a))
Which means "at compile time, get result innerly from Nim compiler via
`getAppFilename`", not "get from nim programs".
Thus, the doc was confusing, only mentioning `compile time` and
`getAppFilename`
---------
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
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
This PR speeds up complex.pow when both base and exponent are real; when
only the exponent is real; and when the base is Euler's number. These
are some pretty common cases which appear in many formulas. The speed
ups are pretty significant. According to my measurements (using the
timeit library) when both base and exponent are real the speedup is ~2x;
when only the exponent is real it is ~1.5x and when the base is Euler's
number it is ~2x.
There is no measurable difference when using other exponents which makes
sense since I refactored the code a little to reduce the total number of
branches that are needed to get to the final "fallback" branch, and
those branches have less comparisons. Anecdotally the fallback case
feels slightly faster, but the improvement is so small that I cannot
claim an improvement. If it is there it is perhaps in the order of 3 or
4%.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
In doc, there are 4 references for `getAppFilename`
`getAppFilename` is still in `os`, but the references refer it as if
it's in the current module `cmdline`
fixes#23247closes#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#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.
The documentation links for `parentDir()` and `getCurrentDir()` are
broken as they are no longer part of `std/os`. Link changed to
`std/private/ospaths2`.
This PR speeds up the calculation of the power of a complex number when
the exponent is 2.0 or 0.5 (i.e the square and the square root of a
complex number). These are probably two of (if not) the most common
exponents. The speed up that is achieved according to my measurements
(using the timeit library) when the exponent is set to 2.0 or 0.5 is >
x7, while there is no measurable difference when using other exponents.
For the record, this is the function I used to mesure the performance:
```nim
import std/complex
import timeit
proc calculcatePows(v: seq[Complex], factor: Complex): seq[Complex] {.noinit, discardable.} =
result = newSeq[Complex](v.len)
for n in 0 ..< v.len:
result[n] = pow(v[n], factor)
let v: seq[Complex64] = collect:
for n in 0 ..< 1000:
complex(float(n))
echo timeGo(calculcatePows(v, complex(1.5)))
echo timeGo(calculcatePows(v, complex(0.5)))
echo timeGo(calculcatePows(v, complex(2.0)))
```
Which with the original code got:
> [177μs 857.03ns] ± [1μs 234.85ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [128μs 217.92ns] ± [1μs 630.93ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [136μs 220.16ns] ± [3μs 475.56ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
While with the improved code got:
> [176μs 884.30ns] ± [1μs 307.30ns] per loop (mean ± std. dev. of 7
runs, 1000 loops each)
> [23μs 160.79ns] ± [340.18ns] per loop (mean ± std. dev. of 7 runs,
10000 loops each)
> [19μs 93.29ns] ± [1μs 128.92ns] per loop (mean ± std. dev. of 7 runs,
10000 loops each)
That is, the new optimized path is 5.6 (23 vs 128 us per loop) to 7.16
times faster (19 vs 136 us per loop), while the non-optimized path takes
the same time as the original code.
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
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`](3379d26629/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.
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.
