freenode/#clasp - IRC Chatlog
Search
14:37:31
Bike
i read it wrong, caller and callee only need the same prototype for musttail, not tail. still need the same calling convention though. that's annoying.
15:18:37
drmeister
You can look in build/boehm/generated/enum_inc.h for what is being exposed via clbind.
15:20:49
drmeister
I thought the translators would be generated by the macros as well - but that doesn't appear to be the case.
15:22:22
drmeister
The translators need to be available where the call is exposed so that the template code knows what to do.
15:25:18
drmeister
So SOMEWHERE there needs to be a to_object and from_object translator for llvmo::ClaspCallingConv. I'm starting to think we have to write it ourselves. Looking...
15:28:09
drmeister
https://github.com/clasp-developers/clasp/blob/master/include/clasp/core/symbolToEnumConverter.h#L114
15:31:31
drmeister
I think all header files get included before the scraper generated code that exposes functions gets compiled - so the code generated by the ENUM_TRANSLATOR will be available for the clbind template code.
15:38:57
drmeister
Clasp has built with compile-file-parallel 12 times since I changed SharedMutex and turned it back on. I'm ready to declare that the weird crashes to be due to the old broken SharedMutex.
15:42:25
Bike
i didn't do an ENUM_TRANSLATOR when i defined the atomic ordering enum, and that works fine
15:48:24
Bike
tons of compile errors. "error: no template named 'to_object': did you mean '::translate::to_object'?"
15:52:04
drmeister
Ihttps://github.com/clasp-developers/clasp/blob/master/include/clasp/core/symbolToEnumConverter.h#L114
15:52:07
drmeister
https://github.com/clasp-developers/clasp/blob/master/include/clasp/core/symbolToEnumConverter.h#L114
15:53:11
drmeister
It's not dicey - it's just stupid. If you put ENUM_TRANSLATOR inside of namespace llvmo then you end up in llvmo::translate::from_object - that can't work.
15:53:55
Bike
well no, i mean the dicey part is i don't understand why this enum needs ENUM_TRANSLATOR and others don't.
15:54:38
drmeister
It's probably why I don't use it much - C++ macros with bizarro rules about where you are allowed to use them suck.
15:55:11
drmeister
I don't know. What is the name of a function that takes one of these other enums?
15:59:50
drmeister
https://github.com/clasp-developers/clasp/blob/master/include/clasp/llvmo/llvmoExpose.h#L4527
16:02:42
drmeister
When the code that exposes the function that takes or returns these enumerated types is compiled clang needs to have the template specializer for to_object and from_object available - otherwise it falls back to the default and the default cant do anything useful with it and you get those alien whatchamawhosits errors.
16:04:49
drmeister
The macro is in the .cc file? I don't think that will work. This is arcana - but IIRC these functions all get exposed inside of gc_interface.cc and that source file includes every header file - so those translators need to be in the header file.
16:06:39
drmeister
The downside of having them in header files is if you change them - then you need to recompile EVERYTHING.
16:07:09
drmeister
So I tend to now put SYMBOL_EXPORT_SC_ and CL_ENUM_xxx in .cc files and the translators go into header files.
16:09:07
drmeister
Try the header file, right after the enum is defined, in the top level namespace.
16:10:47
drmeister
If you really want to see the sausage being made - run the C preprocessor on gc_interface.cc - that shows everything to do with exposing functions.
16:11:52
drmeister
Any .def("xxx",&xxx) where xxx takes some weird enum will be preceded by the translator and that will be preceded by the enum definition. You will have to wade through a million lines of code.
16:15:48
drmeister
We have a bit more fussiness because the scraper generates code and it gets included in gc_interface.cc and these translators need to be available when gc_interface.cc is compiled - so I generally put them in header files.
16:18:06
drmeister
Yeah - there isn't a single translator in any .cc files in clasp except for astExpose.cc and clangTooling.cc - and they use the public clbind.
16:18:58
drmeister
This stuff is very opaque as well. It's C++ compile time type/template resolution.
16:40:56
Bike
it built except that it crashed for unclear reasons while building asdf. so imma try it again
17:55:54
Bike
also, right now llvm-sys:set-calling-conv does a kind of manual dispatch rather than using a single dispatch gf, which kinda sucks?