Merge cpp #1346
Merge cpp #1346
Conversation
Also checked parameters for all rules in the template files as there were changes too.
- Changed the empty return state PredictionContext to max int (instead fixing it on int 16), like it's done in the Java runtime. - Converted 2 static init lambdas in the Cpp.stg to normal code, as VS doesn't allow us to access private class members in such lambdas.
Sometimes in the prediction process temporary ATNConfig instances are created which either share their prediction context with other configs or get a new context which receives the context of another config as parent. Later in the process such temporary configs are released, but the set parent prediction context should stay alive as it is used later. Since there is no top level structure that would keep them alive we need a way to make them stay. For this effect the SinglePredictionContext (which is the only prediction context that keeps a parent reference) uses a shared_ptr instead of a weak_ptr for the parent reference.
Things start looking very promising now. We are ready for runtime tests.
Forgot to commit that with the last changeset.
…reordered tests).
Removed a few unneeded cpp files on the way. Note: building as DLL produces many of the well known compiler warnings C4251 (type needs to have a DLL interface ..) because the runtime uses many STL classes in exported classes. I tried exporting all those types via explicit template instantion, but once I hit unordered_map I gave up. Just crazy what you have to export just to make this map export properly (and I already had like 50 exports already in place). So at the end I disabled this warning on project level. So make sure you build this DLL and all binaries using it with exact the same compiler and linker settings (same C++ runtime etc.).
One of the lambdas used in a "finally" expression executed already while defining the "finally" instance, which is way too early of course (others did not show this behavior), which happens only with the Visual Studio compiler, not clang. By changing the capture list to a general reference capture things started working as they should.
- Updated XCode project (removed obsolete cpp files refs). - Set channel datatype in lexer + tokens to size_t. - Removed one unit test that no longer works, now that we require all objects in a vector given to murmur hash code computation to support the hashCode() function.
In order to allow building the OSX libraries without the demo project they have been split into 2.
Jar files are manually copied into the repository to generate files, but don't belong to it.
The default install name is /usr/libs/antlrcpp.dylib which makes running the demo from command line not working (location and install name of the dylib differ). Since the probability that the lib is placed in an app bundle is much higher than that the lib is being installed in the system, the default has been changed to just the dylib name. This can be changed to anything else if needed in a concrete project.
The runtime folder now contains the individual project files for each platform (and associated files/folders). The actual source code moved down one level to folder src.
C++ target: - More sections are now supported: pre + post include, declarations, definitions (in addition to header and members). - Added specific variants of these sections for (base)listener + (base)visitor files (baselistenerpreinclude etc.). Had to add named sections to VisitorFile.java + ListenerFile.java. Also added the new namedActions parameter to all target stg files where needed.
- Compiling with cmake brought up quite a number of new warnings. Some of them have to be disabled yet (dollar in identifier, four char constant, overloaded virtual). The others have all been fixed. - Updated the README to include build instruction.
Also updated the list of ignored tests in the Cpp.test.stg file (lke it is done for the other targets).
Had to resolve a number of conflicts + added code required for the C++ target to generate header files, after the recent changes in the main repo.
|
@parrt is there any estimate for a release date of 4.6? I can't wait to start using it :) |
|
well, you can build yourself from github src if you want ;) I'm waiting on Swift target. hopefully within a few weeks. |
|
Yes, I can, but it must be official :) Besides this, we need the new version of the Maven and IntelliJ plugins to complete the party. |
|
True dat. |
|
Wow!!!
|
|
People have been waiting years and years for the C++ target. Why not release 4.6 now and 4.6.1 with Swift later on? |
|
@pureconfig we're all set to go minus a few build issues for 4.6 with swift. :) |
|
Go! Go! Go! |
|
@marcospassos working on build issues cross-platform etc.. ;) |
We have C++!!!!