summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* fixes #12703; nim cpp rejects valid code would lose const qualifier for ↵ringabout2024-03-052-4/+29
| | | | | | cstring to string via cstrToNimstr (#23371) fixes #12703 ref #19588
* closes #10219; adds a test case (#23370)ringabout2024-03-051-0/+20
| | | closes #10219
* fixes #20945; fixes #18262; provides C API `NimDestroyGlobals` for ↵ringabout2024-03-042-0/+25
| | | | | | | | | static/dynlib libraries (#23357) fixes #20945 fixes #18262 todo - [ ] perhaps export with lib prefix when the option is enabled
* fix `isAbsolute` broken when `nodejs` on Windows (#23365)litlighilit2024-03-041-3/+3
| | | | | | | | | | | When target is nodejs, `isAbsolute` used to only check in the POSIX flavor, i.e. for js backend on Windows, ```nim isAbsolute(r"C:\Windows") == false ``` This fixes it.
* makes nimsuggest listen on localhost by default (#23351)Juan M Gómez2024-03-041-1/+1
|
* remove obselete doc with nimrtl (#23358)ringabout2024-03-041-3/+0
| | | since nimrtl.dll is created with `--threads:on`
* ref #23333; fixes AF_INET6 value on Linux (#23334)ringabout2024-03-031-1/+1
| | | ref #23333
* Dont mangle when targeting cpp (#23335)Juan M Gómez2024-03-032-2/+2
| | | | Unfortunately we cant trick the debugger when targeting C++ so this one also needs to wait for our own debugger adapter.
* Update browsers.nim, deprecate unimplemented `openDefaultBrowser()` (#23332)litlighilit2024-03-031-14/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | For this [proc](https://github.com/nim-lang/Nim/blob/773c066634d831a968bb464eab35b25a00026525/lib/pure/browsers.nim#L83) `proc openDefaultBrowser*() {.since: (1, 1).}`: though it's documented to open default browser with `about:blank` page, it behaves differently: - On Windows, it failed and open no window - On Linux(Debian with Kde), it opens not default browser but `Konqueror` I have paid much effort to implement this variant, but even the implementation on Windows is considerably complex. In short, it's not only hard but unworthy to fix this. Just as Araq [said](https://github.com/nim-lang/Nim/issues/22250#issuecomment-1631360617), we shall remove the `proc openDefaultBrowser*() {.since: (1, 1).}` variant --------- Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
* Fix nimsuggest highlight for import statements (#23263)autumngray2024-03-032-1/+21
| | | | | | | | | | | 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-033-2/+19
| | | | | | | | | 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-032-8/+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).
* strformat: detect format string errors at compile-time (#23356)Jacek Sieka2024-03-032-40/+111
| | | | | | | | | | | | 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 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)
* Revert "disable measuremancer" (#23353)ringabout2024-02-261-1/+1
| | | | | | Reverts nim-lang/Nim#23352 ref https://github.com/SciNim/Measuremancer/commit/e2e994b21c162d5c382f04383893f2abb12af51f
* fixes #23306 nim cpp -r invalid code generation regression with closure ↵Juan M Gómez2024-02-262-2/+14
| | | | iterators and try/catch-like constructions (#23317)
* disable measuremancer (#23352)ringabout2024-02-261-1/+1
| | | ref https://github.com/SciNim/Measuremancer/issues/17
* * fixed nimsuggest crash with 'Something = concept' put (erroneously) ↵Nikolay Nikolov2024-02-243-1/+28
| | | | outside of a 'type' block (#23331)
* fixes #22723; skips tyUserTypeClasses in injectdestructors (#23341)ringabout2024-02-242-9/+34
| | | 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
|
* ORC: added -d:nimOrcStats switch and related API (#23272)Andreas Rumpf2024-02-215-20/+67
|
* * fixed nimsuggest crash when opening a .nim file, that contain a {.fatal: ↵Nikolay Nikolov2024-02-202-1/+17
| | | | "msg".} pragma. (#23325)
* `varargs[typed]` should behave more like `typed` (#23303)Ryan McConnell2024-02-202-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-202-2/+19
| | | fixes #23295
* Remove count field from Deque (#23318)Tomohiro2024-02-201-51/+46
| | | | This PR removes `count` field from `Deque` and get `count` from `tail - head`.
* fixes #23304; uses `snprintf` instead of `sprintf` (#23322)ringabout2024-02-204-9/+12
| | | fixes #23304
* 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 nimsuggest sug doesnt return anything on first pass #23283 (#23288)Juan M Gómez2024-02-151-8/+6
| | | fixes #23283
* fixes refc with non-var destructor; cancel warnings (#23156)ringabout2024-02-134-7/+23
| | | fixes https://forum.nim-lang.org/t/10807
* fixes #18104; tranform one liner var decl before templates expansion (#23294)ringabout2024-02-132-0/+25
| | | fixes #18104
* fixes a nimsuggest crash on init (#23300)Juan M Gómez2024-02-111-1/+1
|
* Remove mask field from Deque (#23299)Tomohiro2024-02-111-5/+6
| | | | | | | | | 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>
* nimsuggest --ic:on compiles (#23298)Juan M Gómez2024-02-092-0/+21
|
* MangleProcs following the Itanium spec so they are demangled in the debugger ↵Juan M Gómez2024-02-094-6/+276
| | | | | | | | | 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>
* Add items and contains to heapqueue (#23296)Antonis Geralis2024-02-091-0/+15
| | | | The implementation of these functions are trivial yet they were missing from the module.
* fixes #23275; Add `==` for Deque (#23276)Tomohiro2024-02-082-1/+77
|
* fixes regression #23280; Operations on inline toOpenArray len return a wrong ↵ringabout2024-02-062-3/+13
| | | | | result (#23285) fixes #23280
* closes #14710; adds a test case (#23277)ringabout2024-02-051-0/+10
| | | closes #14710
* [fix] nimsuggest `con` sometimes doesnt return anything on first pass fixes ↵Juan M Gómez2024-02-051-2/+3
| | | | | #23281 (#23282) fixes #23281
* follow up #22380; fixes incorrect usages of `newWideCString` (#23278)ringabout2024-02-054-5/+6
| | | follow up #22380
* Docs-improve: os.getCurrentCompilerExe replace with clearer short-desc (#23270)litlighilit2024-02-021-1/+1
| | | | | | | | | | | | | | | | | The doc for `getCurrentCompilerExe` was originally added at [this commit](https://github.com/nim-lang/Nim/commit/c4e3c4ca2d0a1f44ed1e3dd9db564b66031f0843), saying "`getAppFilename` at CT", and modified as "This is `getAppFilename()`_ at compile time..." since [this](https://github.com/nim-lang/Nim/commit/0c2c2dca2a8a3bcdb9729021d1f4734b8db9efbd#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 regression #22909; don't optimize result init if statements can raise ↵ringabout2024-02-012-10/+31
| | | | | | | | | | | | | | | | 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
|
* Additional speed ups of complex.pow (#23264)Angel Ezquerra2024-01-291-8/+25
| | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-02-14 08:41:21 +0000