From: William S F. <ws...@fu...> - 2013-12-16 19:58:17
|
On 15/12/13 14:07, Vladimir Kalinin wrote: >> 1) Is there any reason why you enabled %template with a name to work >> within a class?, like: >> Previously these were treated as though there was no name and warning >> WARN_PARSE_NESTED_TEMPLATE was issued. >> I am wondering because enabling it will open up a can of worms, eg I >> havn't been able to figure out why you needed to make the changes in >> nested_template_typemap.i (I think it is because the partial >> specialization can't handle this and needs some more work). > I made that change, because otherwise the java nested_template_typemap > runtime test just won't compile (Typemap<> is undeclared) > >> Also I had a few seg faults when trying it out, eg: >> >> struct Outer { >> template<typename T> struct Inner {}; >> %template(InnerInt) Inner<int>; >> }; > > There is a bug in the parser, handling such case. Should I just commit the > fix to 'master' or create a pull request? (I attach a patch, so that you > might try it out) > If you are fairly confident it will pass all the tests, then commit to master and please modify an existing or add in a new testcase for the fix, otherwise a pull request is a good idea as it will run the Travis tests without actually affecting master. I see you have committed something. I've reverted the template_nested_typemaps testcase which works now :) This used to issue WARN_PARSE_NESTED_TEMPLATE though and should be turned on again though for now as the %template is silenty ignored and then the resulting code doesn't compile: template<typename T> struct Thingy {}; struct Stuff { #ifdef SWIG %template(ThingyInt) Thingy<int>; #endif }; There is also some other problem (that was also present in 2.0.11) where a class Thingy<int> ends up in the parse tree in the above! Plenty of bugs about! >> I'm inclined to revert this until me/someone can spend some time fixing >> the numerous scoping problems we already have with %template. > In simple cases this seems to be working. It would be, kind of, > unfair, to completely disable the feature. There is a problems when the %template is > not in the same scope as the template class itself but it is always up to the user to decide, > where to put the %template - if it does not work in other places he > may move it to the template declaration scope. I mean - there is nothing broken that was working > before, and something new is added. Fixing these scoping problems is non-trivial and fully qualified names are a suitable alternative. It is very easy to break something else when fixing one scoping problem, it has happened plenty of times before. Until I or someone else has lots of time to attend to this, I don't really want to enable this if it known to be half working, so better to prevent it until it is polished off. There are already a number of regressions in 2.0.5 due to scoping improvements that I just don't have the time to attend to. The whole %template instantiation needs an overhaul: I think the symbol table changes that %template makes should be done in the parser rather than in Typepass so that the symbols are available during the first pass. Also some sort of implicit %template should be put in place as soon as usage of template is parsed. These are quite radical changes, more suitable for a separate release, my focus is to get 3.0.0 out the door sooner rather than later. I was hoping by end of year, but that isn't looking good atm. > >> 3) C nested structs again... Although C nested structs are really >> global, I can imagine a user might want to make them nested in the >> target language. How about we make them nested in the target language by >> default, like they are in C++. Then they can be made global with the >> 'flatnested' feature, as they can be for C++ wrappers. I was thinking >> that this will make for a pretty reasonable default plus a consistent >> way to provide flexibility in choosing between nested or global proxy >> classes in the target language. Otherwise, we'll have to have some sort >> of unflatnesting feature for C. > > In principle it should be possible, because it is like "flatnested" in > reverse (C symbol table contain global names, while normal symbol > tables contain scoped ones). I'll give it a try but can't promise any timeframe > estimates. > In any case it may be useful to better understand symbol table > mechanics to fix %template scoping issues. That would be great, thanks. Given the mechanisms are already there for C++, hopefully it isn't much extra. William |