I have added a new overload of `^` for float exponents.
Is two overloads for `float32` and `float64` better than just one
overload with `SomeFloat` type ?
I guess this would not work with `SomeFloat`, as `pow` is not defined
for `float`.
Another remark. Maybe we should catch exponents with 0.5 and call `sqrt`
instead ?
---------
Co-authored-by: Clay Sweetser <Varriount@users.noreply.github.com>
Co-authored-by: metagn <metagngn@gmail.com>
(cherry picked from commit e9a4d096ab)
fixes#23587
As explained in the issue, `getOrDefault` has a parameter named
`default` that can be a proc after generic instantiation. But the
parameter having a proc type [overrides all other
overloads](f73e03b132/compiler/semexprs.nim (L1203))
including the magic `system.default` overload and causes a compile error
if the proc doesn't match the normal use of `default`. To fix this, the
`result = default(B)` initializer call is removed because it's not
needed, `result` is always set in `getOrDefaultImpl` when a default
value is provided.
This is still a suspicious behavior of the compiler but `tables` working
has a higher priority.
(cherry picked from commit 67ea754b7f)
refs #24207
The `-d:nimUseCAtomics` flag added in #24207 is now inverted and made
into `-d:nimUseCppAtomics`, which means C++ atomics are only enabled
with the define. This flag is now also documented and tested.
Added in #24119, the test checks if every string produced is equal, but
the value of the strings depend on the `now()` timestamp of when they
were produced. 30 of them are produced in a for loop in sequence with
each other, but the first one is set after the data is marshalled into
and unmarshalled from a file. This means the timestamp strings can
differ depending on the execution time and causes this test to be flaky.
Instead we just make 2 strings from the same data and check if they
equal each other.
fixes#24054
`readData` is not implemented for the VM as mentioned in the issue, but
`readDataStr` is, so that is used for `readStr` instead on the VM. We
could also just use it in general since it falls back to `readData`
anyway but it's kept the same otherwise for now.
Also where and why streams in general don't work in VM is now documented
on the top level `streams` module documentation.
Corrects a slicing mistake in the `std/varints` implementation which
caused it to fail when writing large numbers into buffers smaller than
10..13-bytes, now 9-byte buffers are sufficient as the documentation
states.
makes new hash the default, with an opt-out (& js-no-big-int) define.
Also update changelog (& fix one typo).
Only really expect the chronos hash-order sensitive test to fail until
they merge that PR and tag a new release.
```
$ curl -v http://example.com/404 |& grep 'HTTP/1.1'
> GET /404 HTTP/1.1
< HTTP/1.1 500 Internal Server Error
```
So, the test with http://example.com/404 should be disabled, I think.
Unlike present Nim this actually fills `Hash` for `string` & related.
For the curious, note that `hashData` remains the aboriginal Nim string
hasher & `import hashes {.all.}` allows simultaneous test/time of {orig,
murmur, farm} on your favorite CPU & back end compiler.
Update tests also conditioned upon `nimPreviewHashFarm` so they should
pass either with or without that `define` on.
In `--jsbigint=on` mode, only the lower 32-bits of `Hash` match nimvm &
run-time values because `type Hash = int` and on JS int=int32, not int64
as for 64-bit Nim platforms. Due to the matching, `const` Table should
match run-time `Table` on all platforms.
To operate in `--jsbigint=off` mode is feasible but needs much "double
precision mul/xor/ror/shr-arithmetic"-style work. That is distracting &
also of questionable value since JS added BigInt in 2018, ringabout
added Nim support for it in 2021 & `nimPreviewHashFarm` is unlikely to
swap from an opt-in to an opt-out default before 2025..2026 which will
have given a backward looking time window of 7..8 years for deployment
platforms - reasonably generous.
Add a changelog entry for 2.2.
Because of the bug in `tools/parse_unicodedata.nim`, CJK Ideographs were
not considered letters in `isAlpha()`, even though they have category
Lo. This is because they are specified as range in `UnicodeData.txt`,
not as separate characters:
```
4E00;<CJK Ideograph, First>;Lo;0;L;;;;;N;;;;;
9FEF;<CJK Ideograph, Last>;Lo;0;L;;;;;N;;;;;
```
The parser was not prepared to parse such ranges and thus omitted almost
all CJK Ideographs from consideration.
To fix this, we need to consider ranges from `UnicodeData.txt` in
`tools/parse_unicodedata.nim`.
This adds a version of `almostEqual` (which was already available for
floats) thata works with `Complex[SomeFloat]`.
Proof that this is needed is that the first thing that the complex.nim
runnable examples block did before this commit was define (an
incomplete) `almostEqual` function that worked with complex values.
`reset`, `wasMoved` and `move` doesn't support primitive types, which
generate `null` for these types. It is now produce `x = default(...)` in
the backend. Ideally it should be done by ast2ir in the future
fixes#16771
follow up https://github.com/nim-lang/Nim/pull/16536
Ideally it should be handled in the IR part in the future
I have also checked the double evaluation of `swap` in the JS runtime
https://github.com/nim-lang/Nim/issues/16779, that might be solved by a
copy flag or something. Well, it should be best solved in the IR so that
it doesn't bother backends anymore.
This also prevents unwanted `raises: [ValueError]` effects from bubbling
up from correct format strings which makes `fmt` broadly unusable with
`raises`.
The old runtime-based `formatValue` overloads are kept for
backwards-compatibility, should anyone be using runtime format strings.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
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`](ab4278d217/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](18b5fb256d/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.
fixes#22227
rationale:
- `3u - 4u` is supported why not`3u.toRational - 4u.toRational`
- all of rationals' api is on SomeInteger, looks like unsigned is
declared as supported
- math on unsigned rationals is meaningful and useful.
…var/let symbols
fixes#22939fixes#16890
Besides, it was applied to let/const/var with pragmas, now it is
universally applied.
```nim
{.push exportc.}
proc foo =
let bar = 12
echo bar
{.pop.}
```
For example, the `bar` variable will be affected by `exportc`.
