-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Codegen bug with lock - no member "abi" #14873
Comments
Lines 100 to 104 in 6951549
|
I don't think this is related to this: https://github.com/nim-lang/Nim/pull/14170/files#r419710290
IMO the correct approach is proposal 4 from nim-lang/RFCs#205 |
I've encountered a similar error but without using echo. I'll put it here although, it may belong in a separate issue. It seems that a class that contains both a Lock and a string property cannot be instantiated outside of a proc or similar: Exampleimport Locks
type
Test = object
path: string # Removing this makes both cases work.
lock: Lock
# A: This is not fine.
var a = Test()
proc main(): void =
# B: This is fine.
var b = Test()
main()
Current Output
Expected OutputI expected it work really. Additional Information
|
WorkAround: import locks
type
Test = object
path: string # Removing this makes both cases work.
lock: Lock
var a: Test
initLock(a.lock) |
I consider this bug fixed. |
#14873 (comment) |
still exists, see https://forum.nim-lang.org/t/7927#50512 import sharedlist
var s:SharedList[int]
s.init()
echo s.repr
import sharedlist
var s:SharedList[int]
s.init()
echo s
❯ nim -v git hash: 1640508 |
please check whether #17944 fixes these remaining cases (i can't reproduce those locally because i'm on osx) |
* fix #14873 properly by skipping `abi` field in importc type * add test * fix test for windows
Any ETA for this fix? |
you can't copy locks neither on windows or linux. Ref: nim-lang/RFCs#377 (comment) |
I worked around this in Nim-1.0 by implementing |
All these compile for me: type
Test = object
path: string
lock: Lock
var a = Test(path: "hello")
proc main =
let c = newUniquePtr(Test(path: " world"))
var b = Test()
echo b.path, a.path, c[].path
main() was it fixed? |
It was fixed. |
It appears I ran over this one just now. I tried to implement a database connection pool import std/[locks]
type ConnectionPool* = object
connections: seq[int]
lock: Lock
var POOL: ConnectionPool
proc initConnectionPool*() =
POOL = ConnectionPool(connections: @[])
initLock(POOL.lock)
initConnectionPool() I am not that experienced so I'm not 100% certain whether this is actually a bug or me doing something I shouldn't do (or both), but I thought I should at least bring this to your attention to be on the safe side if it is a bug. @xflywind was so kind to inform me that I should be doing this instead (for anybody else reading this looking for a solution):
Edit: It might be that this is platform dependant? The above code does not work for me on nim v1.6.2 on Ubuntu 18.04.6 LTS (git hash as per nim -v: 9084d9b) |
I'm also encountering this issue on Ubuntu 18.04
My workaround so far has been to move my locks out of objects and share a global lock at a file level: NecsusECS/Necsus@0593f1e |
* ref nim-lang#14873 * comment * Update lib/core/locks.nim
…im-lang#17944) * fix nim-lang#14873 properly by skipping `abi` field in importc type * add test * fix test for windows
…c type (nim-lang#17944)" (nim-lang#17992) This reverts commit 98c29c0.
I'd like to use locks and guards while starting threads, but they require SharedPtr and gcsafe in my code so I can't move the lock. Is this going to get fixed? Can it be fixed without breaking anything? |
Update: it works with final builds(-d:release). |
I just confirmed, my code sample above works on nim 1.6.6 from 21 Jan. Running on arch linux. nim -v:
Has the issue been ninja-fixed? |
Hello @PhilippMDoerner Feel free to add a testcase to close this issue ref #19935 |
@PhilipMDoerner's example fails to compile on Ubuntu 20.04 with GCC 9.4.0, as well as: import std/locks
type Connection pool = object
connections:seq[int]
lock:Lock
var POOL= ConnectionPool() fails to compile with
With 1.6.6 and devel |
@xflywind it appears this is... distro specific? GCC specific? Really not sure on that one. it might be noteworthy that I compiled on GCC 12.1.0
|
I see. |
Reopen #12855 under my name to avoid spamming the original poster as Github keeps notifying an issue author even if they unsubscribe.
The text was updated successfully, but these errors were encountered: