| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
The files(like `build/build.sh`)generated by the command `koch csource`
do not contain complete `linux/loongarch64` support. This patch will fix
it.
|
| |
|
|
|
|
|
| |
blocks https://github.com/nim-lang/Nim/pull/23673
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| |
|
|
| |
These packages are some of the dependencies of Nimbus with shorter
testing times.
|
| | |
|
| |
|
|
| |
(#23654)
|
| |
|
|
|
| |
(#23666)
…his scope
|
| |
|
| |
fixes #23665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #22798
Per
https://stackoverflow.com/questions/33675638/gcc-link-the-math-library-by-default-in-c-on-mac-os-x
and
https://stackoverflow.com/questions/30694042/c-std-library-dont-appear-to-be-linked-in-object-file
> There's no separate math library on OSX. While a lot of systems ship
functions in the standard C math.h header in a separate math library,
OSX does not do that, it's part of the libSystem library, which is
always linked in.
required by https://github.com/nim-lang/Nim/pull/23290
|
| |
|
| |
fixes #23663
|
| |
|
|
|
| |
platform (#23661)
Cannot compile on Linux reliably
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
| |
revert #23436
|
| |
|
|
|
|
|
| |
fixes #23635
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For now, `expandSymlinks()` can handle only symlinks with lengths up to
1024.
We can improve this logic and retry inside a loop with increasing
lengths until we succeed.
The same approach is used in
[Go](https://github.com/golang/go/blob/377646589d5fb0224014683e0d1f1db35e60c3ac/src/os/file_unix.go#L446),
[Rust](https://github.com/rust-lang/rust/blob/785eb65377e5d7f8d8e8b82ede044212bbd2d76e/library/std/src/sys/pal/unix/fs.rs#L1700)
and [Nim's
`getCurrentDir()`](https://github.com/nim-lang/Nim/blob/devel/lib/std/private/ospaths2.nim#L877),
so maybe it's a good idea to use the same logic in `expandSymlinks()`
also.
|
| |
|
|
|
|
|
|
|
|
| |
... by moving the Google font includes near the top of the head. By
including them as early as possible, they are known, when the browser
starts rendering the body.
Test it by making the change manually in `doc/html/system.html` and then
press ctrl+f5 (reload without cache). This removes the font flashing.
Tested in Chrome and Firefox.
|
| |
|
| |
closes #13426
|
| | |
|
| |
|
|
| |
(#23640)
|
| | |
|
| |
|
|
| |
(#23633)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
followup #23560
|
| |
|
|
|
| |
In doc, `loongarch64` used to be written as `'"loongarch64"'`
since it's [supported](https://github.com/nim-lang/Nim/pull/19223)
|
| |
|
| |
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| |
|
|
|
| |
fixes #16671
related to https://github.com/nim-lang/Nim/pull/18911
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
ref https://forum.nim-lang.org/t/11587
Tested with `gcc version 14.0.1 20240412` locally
|
| |
|
| |
closes #15778
|
| | |
|
| | |
|
| |
|
|
|
|
| |
tests untested (#23592)
Targets are not changes, which means the C binary is actually tested for
JS backend
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
By allowing `exportc` in params one can decide the name of a param or to
dont mangle them.
|
| |
|
| |
Feel free to close if this an unwanted addition :)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ref https://forum.nim-lang.org/t/11564
```nim
block: # unordered enum
block:
type
unordered_enum = enum
a = 1
b = 0
doAssert (ord(a), ord(b)) == (1, 0)
block:
type
unordered_enum = enum
a = 1
b = 0
c
doAssert (ord(a), ord(b), ord(c)) == (1, 0, 2)
block:
type
unordered_enum = enum
a = 100
b
c = 50
d
doAssert (ord(a), ord(b), ord(c), ord(d)) == (100, 101, 50, 51)
block:
type
unordered_enum = enum
a = 7
b = 6
c = 5
d
doAssert (ord(a), ord(b), ord(c), ord(d)) == (7, 6, 5, 8)
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
refs
https://github.com/nim-lang/Nim/issues/23586#issuecomment-2102113750
In #20091 a bad kind of type inference was mistakenly left in where if
an identifier `abc` had an expected type of an enum type `Enum`, and
`Enum` had a member called `abc`, the identifier would change to be that
enum member. This causes bugs where a local symbol can have the same
name as an enum member but have a different value. I had assumed this
behavior was removed since but it wasn't, and CI seems to pass having it
removed.
A separate PR needs to be made for the 2.0 branch because these lines
were moved around during a refactoring in #23123 which is not in 2.0.
|
| |
|
| |
ref https://github.com/nim-lang/Nim/pull/23226
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#23570)
[`rsplit
iterator`](https://nim-lang.org/docs/strutils.html#rsplit.i,string,char,int)
yields substring in reversed order,
while [`proc
rsplit`](https://nim-lang.org/docs/strutils.html#rsplit%2Cstring%2Cchar%2Cint)'s
order is not reversed, but its doc only declare ```
The same as the rsplit iterator, but is a func that returns a sequence
of substrings.
```
|
| |
|
|
|
| |
(#23558)
fixes #23552
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23568, fixes #23310
In #23091 `semFinishOperands` was changed to not be called for `mArrGet`
and `mArrPut`, presumably in preparation for #23188 (not sure why it was
needed in #23091, maybe they got mixed together), since the compiler
handles these later and needs the first argument to not be completely
"typed" since brackets can serve as explicit generic instantiations in
which case the first argument would have to be an unresolved generic
proc (not accepted by `finishOperand`).
In this PR we just make it so `mArrGet` and `mArrPut` specifically skip
calling `finishOperand` on the first argument. This way the generic
arguments in the explicit instantiation get typed, but not the
unresolved generic proc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
## Bug
Fixes https://github.com/nim-lang/Nim/issues/12381 - HttpClient socket
handle leak
To replicate the bug, run the following code in a loop:
```nim
import httpclient
while true:
echo "New loop"
var client = newHttpClient(timeout = 1000)
try:
let response = client.request("http://10.44.0.4/bla", httpMethod = HttpPost, body = "boo")
echo "HTTP " & $response.status
except CatchableError as e:
echo "Error sending logs: " & $e.msg
finally:
echo "Finally"
client.close()
```
Note the IP address as the hostname. I'm directly connecting to a
plausible local IP, but one that does not resolve, as I have everything
under 10.4.x.x.
The output looks like this to me:
```
New loop
Error sending logs: Operation timed out
Finally
New loop
Error sending logs: Operation timed out
Finally
New loop
...
```
In Nim 2.0.4, running the code above leaks the socket:
<img width="944" alt="Screenshot 2024-05-05 at 22 00 13"
src="https://github.com/nim-lang/Nim/assets/53387/ddac67db-d7df-45e6-b7a5-3d42f79775ea">
## Fix
With the added line of code, each old socket is cleanly removed:
<img width="938" alt="Screenshot 2024-05-05 at 21 54 18"
src="https://github.com/nim-lang/Nim/assets/53387/5b0b4b2d-d4f0-4e74-a9cf-74aec0c50d2e">
I believe the line below, `closeUnusedFds(ord(domain))` was supposed to
clean up the failed connection attempts, but it failed to do so for the
last one, assuming it succeeded. Yet it didn't. This fix makes sure
failed connections are closed immediately.
## Tests
I don't have a test with this PR. When testing locally, the
`connect(lastFd, ..)` call on line 2032 blocks for ~75 seconds, ignoring
the http timeout. I fear any test I could add would either 1) take way
too long, 2) one day run in an environment where my randomly chosen IP
is real, yielding in weird flakes.
The only bug i can imagine is if running `lastFd.close()` twice is a bad
idea. I tested by actually running it twice, and... no crash/op? So
seems safe? I'm hoping the CI run will be green, and this will be
enough. However I'm happy to take feedback on how I should test this,
and do the necessary changes.
~Edit: looks like a test does fail, so moving to a draft while I figure
this out.~ Attempt 2 fixed it.
|
| |
|
|
|
| |
`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
|