Pass connected funtest on all but js and interp - #465
Conversation
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
Signed-off-by: Tom <tom@temper.systems>
| // For more on includes, see https://en.cppreference.com/cpp/preprocessor/include#Notes | ||
| Include ::= "#" & "include" & "<" & path%Raw & ">" & "\n"; | ||
| /** For string literals, although escapes don't work. */ | ||
| IncludeLocal ::= "#" & "include" & path%LiteralExpr & "\n"; |
There was a problem hiding this comment.
Technically not necessarily local-priority includes, but typically all compilers treat them that way, and it at least provides a different convention that can be used by compilers.
Separately, I tried explicit double-quotes around raw to make differences from strings more explicit, but the spacing was off, and it doesn't really accomplish anything.
| content = file.value, | ||
| ).also { add(it) } | ||
| } | ||
| } |
There was a problem hiding this comment.
For all the backends, I haven't tested submodules yet. Putting that off for build tests in a future PR.
| fileExtensionMap = mapOf( | ||
| FileType.Module to lang.ext, | ||
| FileType.Script to lang.ext, | ||
| FileType.Header to HPP_EXT, |
There was a problem hiding this comment.
We need extensions registered for all files we might want to copy.
| mimeTypeMap = mapOf( | ||
| FileType.Module to MimeType.cppSource, | ||
| FileType.Script to MimeType.cppSource, | ||
| FileType.Header to MimeType.cppSource, |
There was a problem hiding this comment.
We were already supplying this mime type for header files, just not using this map.
| def == WellKnownTypes.dequeTypeDefinition -> | ||
| WellKnownTypes.dequeTypeDefinition -> | ||
| return sharedPtr(cpp.template(cppBaseTypeForDefinition(def)!!, typeArgs)) | ||
| else -> {} |
There was a problem hiding this comment.
The overall change recommended by ij, and it's cleaner overall except for needing the else. Went along with it.
| return i * j | ||
| end | ||
|
|
||
| return exports |
There was a problem hiding this comment.
I made "support" or "more" code for each backend just to prove we have access to them. And made class-like things in each also just for kicks.
| @@ -0,0 +1,15 @@ | |||
| namespace Work | |||
| { | |||
| static class WorkConnected | |||
There was a problem hiding this comment.
We already had <Lib/Mod>Global in be-csharp and be-java, so I reused the same style for <Lib/Mod>Connected for both. But after everyone else is just getting _connected, it's almost tempting to do that for csharp and java also. Or maybe I should make others more idiomatic instead of making these worse. Don't know. These can be refined in future PRs, if we decide for sure to change from what I've made so far.
| internal static int Prod(Hidden hidden, int j) | ||
| { | ||
| return new MoreSupport().Prod(hidden.I, j); | ||
| } |
There was a problem hiding this comment.
I am trying to make the functions themselves use idiomatic naming. And I've proved I can use the Hidden type in each backend.
| return i + j + bonus | ||
| end | ||
|
|
||
| ---@param hidden work.Hidden TODO Actually define types in our Lua. |
There was a problem hiding this comment.
We don't yet generated static EmmyLua (or rather Lua Language Server) typing in our LuaTranslator, and we also don't strip numeric suffices yet. But we also don't need static typing for Lua to work. I just wanted to do static type annotations where possible in the lua connected code in this PR, anyway. This is just the case I can't do yet.
Shaw also would like to make generating type annotations optional in the future, if we do get around to generating them (which I personally would greatly like, as luals is actually pretty high quality in my using it so far in hobby things).
| Script, | ||
|
|
||
| /** a header file for pre-declarations */ | ||
| Header, |
There was a problem hiding this comment.
Felt a bit bad adding this, but C and/or OCaml and/or others might also want header files in the future.
There was a problem hiding this comment.
So this just keys into a lookup table for mime types so helps in picking accurate mime-types?
There was a problem hiding this comment.
So this just keys into a lookup table for mime types so helps in picking accurate mime-types?
I don't think all backends even use them meaningfully. Looks like FileType.Module gets used in a couple of places. I'm not sure others do at all. But fileExtensionMap and mimeTypeMap in BackendMeta need them. We maybe could adjust in the future. But I needed something other than Module to list .hpp, and JsModule and Script both seemed very wrong.
Signed-off-by: Tom <tom@temper.systems>
mikesamuel
left a comment
There was a problem hiding this comment.
What would it take to have our backend test framework test how backends and translators deal with connected files?
| PreProc = Define | Undef | Pragma | IncludeGuard | Include | IfPreProc; | ||
| PreProc = Define | Undef | Pragma | IncludeGuard | Include | IncludeLocal | IfPreProc; | ||
| // For more on includes, see https://en.cppreference.com/cpp/preprocessor/include#Notes | ||
| Include ::= "#" & "include" & "<" & path%Raw & ">" & "\n"; |
There was a problem hiding this comment.
If you run into formatting glitches you could try token references for some of these with specified operator association. Like < as bracket operators instead of as infix.
There was a problem hiding this comment.
Note to self: these resources are just for the connected functional test.
| Script, | ||
|
|
||
| /** a header file for pre-declarations */ | ||
| Header, |
There was a problem hiding this comment.
So this just keys into a lookup table for mime types so helps in picking accurate mime-types?
| | [ControlFlowLoops][] | ✅ | ❌<sup>[198][]</sup> | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | ||
| | [FunctionsAsValues][] | ✅ | ❌<sup>[198][]</sup> | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | ||
| | [FunctionsConnected][] | ❌<sup>[456][]</sup> | ❌<sup>[198][]</sup> | ❌<sup>[456][]</sup> | ❌<sup>[456][]</sup> | ✅ | ✅ | ❌<sup>[456][]</sup> | ❌<sup>[456][]</sup> | ✅ | ✅ | ❌<sup>[456][]</sup> | | ||
| | [FunctionsConnected][] | ✅ | ❌<sup>[198][]</sup> | ✅ | ❌<sup>[456][]</sup> | ✅ | ✅ | ❌<sup>[456][]</sup> | ✅ | ✅ | ✅ | ✅ | |
Do you mean just the ...BackendTest suites? If so, it would be fairly easy to include them. I didn't feel like I would get much out of them, but it sounds like you would, so I can add some in future PRs, at least. |
Uh oh!
There was an error while loading. Please reload this page.