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
Extend Annotation Support #1125
Extend Annotation Support #1125
Conversation
Annotation support extended to on the following types and their contents: - Interfaces - Porttypes - Eventtypes - Components Annotations on Valuetypes and most of their possible contents are also supported. The exceptions to this are these types of valuetype statements: - import: not supported by TAO - typeid: not supported by TAO on valuetypes - typeprefix: No corresponding AST Node to attach annotations to
The errors in VS2017 WChar aren't the same as on master, but they're similar. I feel like I've seen this behavior in TAO before where the build fails because the results from IDL weren't generated in the proper order. |
By the way, TAO/tests/IDLv4/TestIDLv4.idl can be turned into valid IDLv4 with these changes:
Okay to piggyback on here, or do you prefer a separate pull request? |
Let's do that one separately. It's not related to the changes in this PR. |
@iguessthislldo Looks this PR causes some compile and runtime issues, see for example https://buildlogs.remedy.nl/rhel70_atcd_debug_ndds523rev0/index.html
|
Looks bcc32 also has some issues https://buildlogs.remedy.nl/win_cbxe13_bcc32_acetao_debug/
|
@jwillemsen could CI be enhanced to catch these compile-time issues? @iguessthislldo looks like Annotation_Test.h:64 should be |
Building also all TAO tests will take probably another 2 to 3 hours, that is probably not workable anymore with only 20 workers when there are multiple PRs on a day |
It would be interesting to try to dynamically determine which tests to build based on the changes from master.
Looks like this is due to using a deleted object |
This function deletes its first argument and replaces it with a different object when a forward-declared valuetype is being expanded to its fully-declared valuetype (note passing pointer by reference):
|
Using compiler explorer, it looks like gcc and clang accept this, but msvc complains in a similar manner as whatever bcc is. The preprocessor is weird. I will take a look at all these issues tomorrow. |
Fixes for DOCGroup#1125 - TAO_IDL/fe.ypp - Fixed using wrong pointer in grammer. - Other minor tweaks. - tests/IDLv4/annotations - Fixed preprocessor usage in that some compilers don't like. - Fixed passing std::string as a const char*. - Rewrote idl output funciton to be more flexable.
Fixes for DOCGroup#1125 - `TAO_IDL/fe.ypp` - Fixed using wrong pointer in grammar. - Other minor tweaks. - `tests/IDLv4/annotations` - Fixed preprocessor usage that some compilers don't like. - Fixed passing `std::string` as a `const char*`. - Rewrote IDL output function to try to be more flexible.
#1132 has fixed the problems in the TAO tests but there looks there is last problem in CIAO, see http://scoreboard.ociweb.com/doc_master_tick_linux_gcc_d0o1b32/index.html |
Looks like it's an IDL file generated by tao_idl3_to_idl2, in case that matters. I'm also wondering why the Remedy CIAO builds didn't fail? |
We only compile LwCCM with no CCM events support, looks this test is dependent on CCM events so it is not run in our builds |
Just made a PR to also build the specific test with noevent, it works on my system, but I don't have the latest tao_idl changes, see DOCGroup/CIAO#126 |
With lwccm+noevent enabled the test runs, so probably it is in the area of event support |
Callstack, line 6504 did got changed as part of the annotation support
|
Okay, that's:
but this should be the same as what was happening before:
|
More Fixes for DOCGroup#1125 Fixed using wrong prointer for add to scope in DOCGroup#1132 for interfaces, now doing that for eventtype and component. See: DOCGroup#1125 (comment)
Annotation support extended to on the following types and their
contents:
Annotations on Valuetypes and most of their possible contents are also
supported. The exceptions to this are these types of valuetype
statements: