Segfault on build #811
Comments
|
Hm, weird. Is lock a generic type or a generic function here btw? |
|
Lock is supposed to be defined as lock: func ~function <T> (function: Func -> T) -> Tand called like this Foo: class {
_done: Bool
done: Bool { get {
f := func -> Bool { this _done }
this lock<Bool>(f)
}}
}but the 4 lines of code I posted in the OP is the only thing I'm building and is enough to cause the segfault. The same segfault occurs when trying to build this here snippet as well, but I didn't want to distract from what seems to be a parsing issue more than anything else. |
|
Ah, thanks for the info, I'll fix this tonight |
|
Hm, the call is handled as a call combo, this is weird :P |
|
@davidhesselbom f: func <T> (T: Class) -> T { /* ... */ }
//...
ok? := f(Bool)Actually, in your case, this should be enough Foo: class {
_done: Bool
done: Bool { get {
f := func -> Bool { this _done }
this lock(f)
}}
}
@fasterthanlime Should I implement this syntax or not? |
|
Ofc the segfault should not happen, this should be a syntax error. |
|
It should be documented somewhere for sure though. |
|
@Shamanas I have no idea what you're referring to in
Care to elaborate? |
|
@davidhesselbom Just curious - what resource are you locking/releasing access to? In the SDK we have mutexes (mutii?) and we do stuff like // this call will block until the mutex is available
mutex with(||
// in there, the mutex is acquired to this thread
// after the closure ends, the mutex is released
)
// and now the mutex is available again |
|
Ups sorry I didn't escape < and >, I meant f <String> (...)Is not valid syntactically |
|
Ah, indeed. Types are kind of first-class in ooc, so you can just pass them as regular arguments. I've never been fond of the Java-y way of doing things which was to specify types when calling it, with carets. (Also it makes parsing harder). But maybe I was mistaken back then. That would be a breaking change, though... |
|
It doesn't necessarily need to be breaking (the current code should run fine if the only thing modified is resolving generic arguments from the function call < and >) However, I do think the current syntax is pleasent and frankly, this change would require some prettty deep digging into FunctionCall.ooc which may be the most intimidating part of the rock codebase :P Also: f: func <T, V> (val: V) -> T { /* ... */ }
f <String> (42) // Does this compile? If it does, isn't it misleading?
// Or do we need
f <String, Int> (42)
// Versus
f: func <T, V> (val: V, T: Class) -> T { /* ... */ }
f(42, String) // \o/ !
|
|
Btw, what happens currenty: this f <Int> ()
// this f -> VariableAccess
// <Int> shouldn't match to anything but FunctionCallNoName is the fallback
// and it somehow ends up matching to it, although it should expect ( args ) directly
// after the variable access... |
|
Also, it would be nice to error out on definitions like f: func <T> -> T {
null as T
}Where we know the generic type cannot be infered from a function call |
|
@Shamanas Yeaaaah rock isn't that smart. |
|
@fasterthanlime But it could be! :D We can move this to algo/GenericInference.ooc and do... stuff... there :) |
|
@Shamanas Insert something about pile of hacks here and mention proper inference engine |
|
I think splitting off generic inference tools into another module rather than having them tied into FunctionCall would be less hacky though ^_^ |
|
I can't figure out why nagaqueen just ignores the < ... > part :/ |
|
Couldn't it be parsed as |
|
I thought so but the parenthesis are interpreted as FunctionCallNoName which means we are in the Access rule which is (FunctionCallNoName only appears in this rule) |
|
After I reported this, I noticed that rock tends to crash with segfaults in many cases where a simple "syntax error" message would be more helpful. I think this started happening at around the same time that abstract operator support was added, but I'm not sure. @fasterthanlime, can lock (this.lock) {
// do stuff, more code
return whatever
}but in ooc you have to do result: Int
mutex lock()
// more code
result = whatever
mutex unlock()
resultafaik and by passing a function to lock() we were hoping to keep our code cleaner, so that's why we tried this the first place. If I can do with mutex(||
//do stuff, more code
return whatever
)I guess that would work too.
|
|
@davidhesselbom |
|
I think this would work though: extend Mutex {
with: func <T> ~return (f: Func -> T) {
lock()
ret := f()
unlock()
ret
}
} |
|
Well, that syntax is still not supported, but at least it throws a rock error now, not a segfault. |
This results in a segfault when building:
I'm running rock on the master branch, if it's any help.
The text was updated successfully, but these errors were encountered: