Rebase on tagged 4.8 shiboken #10
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix potential buffer overrun (__first iterator becomes > __last and starts processing garbage) when parsing macro definitions that would occur if a macro definition ends in a comment. This would cause the macro definition to contain incorrect content or even outright garbage (i.e. random memory) if the trailing comment is at the end of the file, as in boost/type_traits/detail/type_trait_def.hpp. In this worst case, the macro expansion could contain a NUL byte which would cause parsing to prematurely halt at the point of expansion. Change-Id: I94ded39d9a20dc9510d827bc18adb2dc1bad17f0 Reviewed-by: John Cummings <[email protected]>
Allocate and use separate structures for as_* fields in the PyTypeObject rather than using fields in the PyHeapTypeObject. This is a step away from using the PyHeapTypeObject, which is unnecessary and will make supporting stackless python easier. Change-Id: I6e5c514ab6db5b8bee9bee3107b97d6fbd582641 Reviewed-by: Christian Tismer <[email protected]> Reviewed-by: John Cummings <[email protected]>
Starting with OS X 10.9 the system toolchain defaults to libc++. This is a problem with the current sparse hash config as it defaults to using c++11 functionality under the std::tr1 namespace instead of std, which fails for libc++ since it does not implement the tr1 namespace. This change allows libc++ based systems to use the correct namespace. Change-Id: Ia8dd49fb5fad2915f41e44240e45a7af9d6453a8 Reviewed-by: John Ehresman <[email protected]>
Fix omission of 'const' specifier when generating binding code for containers whose value type is 'const', which would lead to binding code that does not compile due to 'const' mismatch. Includes test case. Change-Id: Iff99a16ee071bb255f78e86e2456e5206cc00cfb Reviewed-by: John Cummings <[email protected]>
Sphinx 1.2 made a backwards-incompatible change and removed its `refcounting' extension module because it "is very specific to CPython and has no place in the main distribution". Fix the build with Sphinx 1.2+ by not requiring it in conf.py.in; we were not using it before anyway (the `refcount_file' variable was not set) and it was likely added by default when the configuration file was generated. Change-Id: I6c775fb4c1c2daae25aade68079efc2e77225a0f Reviewed-by: John Ehresman <[email protected]>
FindPython3Libs.cmake lists hardcoded versions of python3 to look for, which include up to python 3.2. Added python 3.3 and 3.4 to this list so that building on these versions works. A better solution would be ideal in future, so as to avoid having to add python versions to this list as time passes. However, this fixes the issue for now. Change-Id: I9c113f70164c30dc3a94a5c946facbc38901f68e Reviewed-by: John Ehresman <[email protected]>
Add an additional check to AbstractMetaBuilder::traverseFunction to also perform a quick-and-dirty construction of the function signature, and to check that against the rejections. Add a unit test for matching full signatures. Before, we were only testing the function name; as a result, a rejection like 'foo()' would never match (because the name does not have ()'s). This is especially helpful for rejecting specific overloads of functions while allowing others to be wrapped normally. (The unit test shows a not-so-far-fetched example why one might want to do this.) The signature building logic isn't very sophisticated and likely requires a very exacting match to the signature as it appears in the wrapped sources, but that's likely not a serious issue, and at any rate this is much better than not being able to match overloads at all. Change-Id: Ic686377477aacf54f79c7bd2013e9aea8521a4ea Reviewed-by: John Ehresman <[email protected]>
Teach Shiboken to parse the 'noexcept' keyword. This doesn't add any features (and we only support unconditional 'noexcept' for now), but addresses an internal error that causes shiboken to SEGV trying to parse modern versions of boost::intrusive_ptr. A test case to replicate the crash (without the other changes) is also added. Change-Id: I4713593dfd189c02ef4a2d7447d785b6d378019c Reviewed-by: John Ehresman <[email protected]>
The protected sections triggered a generation bug when avoiding the protected hack Change-Id: I6346cdb74a25f1ddf49263d9f74670a3b105b07a Reviewed-by: Matthew Woehlke <[email protected]> Reviewed-by: Roman Lacko <[email protected]>
These functions (except createComplexList) are are needed by the test. Prior to 5b39f7f, the rejections were not being recognized; removing them returns the wrappings to their previous state and allows the test to pass again. Change-Id: I3efb08383b2d59f9917a4e4a0200e0516db9c83e Reviewed-by: Matthew Woehlke <[email protected]> Reviewed-by: John Ehresman <[email protected]>
Change-Id: I4da6558dfa2dd2aaae6343d2363b7fcfc7786f45 Reviewed-by: John Cummings <[email protected]>
Modify _ScopeModelItem to return enums (from the enums() method) in the order that they were added (which presumably is the order in which they were declared). We must do this because we must process enumerations in the same order in order to resolve values, as later declared enums may refer to values from earlier declared enums (and in fact, this is exactly the case in the 'testenum' test), and the order we get just from QHash may not match declaration order. Change-Id: I15a05df98a2cee7ecccb6c82d3f9017735281245 Reviewed-by: John Cummings <[email protected]>
In the same vein as the previous commit, process global enums in order added (which presumably is declaration order). For what we're doing at this point, this may not be as critical, but again is needed to avoid a spurious test failure. Change-Id: If32a07fee2e7e9b7699e01eda3408ed57855e947 Reviewed-by: John Cummings <[email protected]>
When building the class topology, don't skip classes, even if we are not going to generate code for them. This is necessary to get the topology order correct in a case such as C derived from B derived from A, where B is not generated, but initializing C depends on A being initialized first. Without this change, there is no guaranteed ordering between A and C in such a case. (In particular, this comes up in the Photon test; Photon::ValueIdentity derives from Photon::TemplateBase, which derives from Photon::Base. However, this was not being reflected in the topology, and as a result, it was just luck that the initialization order was correct anyway.) Change-Id: I4b99a50acef3b06e77100a70f2db8236d06af2be Reviewed-by: John Cummings <[email protected]>
Add 'type-template' tag (and 'arg' child tag) to declare a definition of a template struct/class. Modify 'object-type' and 'value-type' to allow creating these as template instantiations referencing a 'type-template', as an alternative to the usual non-template support. There is also a 'redirect' attribute on 'arg' that will be used to create "redirection" methods on the wrapped class to allow calling methods of a template argument class as if they belonged to the instantiation, which is sort of like having an operator->(). The eventual goal is to support wrapping of e.g. QSharedPointer. This is sufficient to parse a typesystem XML (updates to 'sample' included) using the new tags, but not to do anything useful yet, as neither type resolution is working, nor do we generate code for the instantiations. Change-Id: I37960727c4dd69c39e84a414ae08752e3fd0dbf3
Teach AbstractMetaBuilder to create wrappers for template instantiation types. Teach generators to generate valid code for the same. This is quite half-baked, as type resolution for instantiations is not yet working (which tends to defeat the purpose). However, a typesystem defining template instantiation types now generates code which also compiles (and 'sample' is updated accordingly). To facilitate code generation, fixedCppTypeName(QString) is now a public static member of ShibokenGenerator, and is used in quite a few places that previously only replaced '::'. This is needed as instantiation wrappers have <>'s in their names that also need to be replaced, and since the additional substitutions that fixedCppTypeName performs should be harmless, this way we are using a helper function that already existed rather than creating a new one for the purpose. Change-Id: I7d077e89d9c3190e6850c1e04aac23a1f179c33b
Teach translateType() to find and translate template instantiation types. Teach buildAbstractMetaTypeFromString() how to create AbstractMetaType's for the same. This suffices to recognize and translate template instantiation types. However, since redirection is not yet implemented, and adding methods directly to the instantiation is not currently working, the wrapped objects aren't of much use except as opaque handles. However, this is enough to have at least the start of a meaningful unit test, and one is accordingly added to 'sample'. Change-Id: I3aee6ece8ad769a07127ff5fdd67a7af2d05200d
Tweak how we iterate over instantiations to have proper argument reporting, and to be cleaner and (for the second pass anyway) more efficient. Implement resolution of template arguments on instantiations. Implement redirections on template instantiations. Add unit test for redirections. Change-Id: I51ac71154cd2e8c2c82e4e1dd6305d90661ceced
Add the little tiny missing piece of code that broke adding new methods to a template instantiation type. Add unit test for this. Change-Id: I4e03805d83669af3b036451845394ca7a5a95276
Improve type-template test case to test that Shiboken recognizes and correctly resolves typedefs of type-template instantiations. Change-Id: I613c3f1938561e8dabb25438616316e314163e7d
Fix a corner case where type resolution for a container type breaks due to failing to add the template arguments, due to trailing whitespace causing resolution of the same to fail. As best I can tell, this only happens for redirector functions of type-template instantiations inside of namespaces for which the type-template is also inside of a namespace. Change-Id: Ie5934bcc03ada92c42df49e255ef6df743f9fac6
Modify AbstractMetaBuilder::translateType, and in particular the associated helper function findTypeEntryUsingContext, to also find type-template instantiations within a namespace scope. Change-Id: Id4408fefcb3f3badfe940f15d0f6adab9edc52a3
Modify Binder to correctly qualify type aliases for template instantiations. This seems to mainly be a problem for type-template instantiations, but may affect regular instantiations as well. Also convert the set of qualified types to a QSet (which should be slightly less expensive than an unused QString value on a QHash). Modify the tests to exercise the newly-working resolution. This is in some ways closely related to the previous two commits, and the test updates are at least partly relevant to those also. Change-Id: I45ae5ea9573d0c9ba26dd60c3b70056d13e9868c
Modify translateType to also try a canonicalized form of the type name. This is necessary to resolve function arguments to type-template instantiations, as the canonical instantiation name has spaces inside the <>'s, but the function argument has these stripped due to minimal signature normalization. (Return types are not normalized and so do not have this problem.) Change-Id: Ide191042c709f995a04ff7b77855c0e6f80a7d9c
Fix ::name of AbstractMeta{Type,Class} for type-template instantiations.
These were giving odd results because namespace splitting could split on
a template argument and throw out the actual type name and resulting in
names like 'Object >'. This doesn't seem to obviously affect code
generation (probably it works because the names are still unique for the
cases we've tested so far, but would have collisions in case of more
than one instantiation with the same template argument(s)), but helps
with debugging when inspecting the name()s.
Change-Id: I7de115b31496bf605b9f660d106ba1d6082bfe7f
Don't generate redirections to internal class's protected members. This isn't working right, because it requires a static cast of the inner class to its wrapper to bypass the access protection, but right now the generated code is doing the cast on the outer class instead (which is otherwise the right thing to do). Since 1) it's questionable if protected methods should be exposed anyway, and 2) likely significant work to get it working, just disable it for now. Change-Id: Ia7e3aee3ffd4f670fc74735cec3248dcf8f0d2ef
It isn't obvious why only "inner classes" would need their names sanitized; at least within our tests, no classes that trip this flag have names that need to be sanitized. However, names of type template instantiations must always be sanitized, and there is no ready check for these at the moment, so just sanitize everything. (It may have just been for performance reasons that we weren't doing this anyway, but this shouldn't be in the critical path for that we need to be overly worried about performance here.) Change-Id: Ic13089efde9793fc5da8acd049e9d54363f5efa7
When generating wrapper classes, use the mangled qualified name instead of just the base name. This is required to avoid symbol collisions in the case of wrapping two classes with the same name in different namespaces. This doesn't "really" belong on this branch, as it applies to Shiboken in general, however it effectively depends on the mangling that was added here, and especially the previous commit, where we changed to always mangle the wrapper name. Change-Id: I276a97b4eac4385307a94159437ee4757d88a196
Modify typesystem parser to (partly) set the correct context for function additions/modifications to type-template. Modify AbstractMetaBuilder::createInstantiationMetaClass to add functions from the type template to the instantiation. This is only partly complete; template argument types are not yet supported as types in the function. Change-Id: Ie6369d2facf3bcd642e9a2a51cbb107046e9094d
Don't bother adding redirection functions to the instantiation type entry; they are only needed for adding the functions to the abstract meta objects, which we are doing anyway, and are not needed by the generate phase, so adding them to the type entry also is superfluous. Change-Id: I81adc0a3e4d460e98c4a9849da6bbafe65f1ad61
This marks ptr<B> as inheriting from ptr<A> if B inherits from A and ptr<T> is marked as wraps-pointer-as for T.
Checking the baseClassNames for its size is pointless since everything is run off of the size of baseClasses anyways.
This is actually a work around for a known gcc bug
sbkObject is a struct, but was forward declared as a class.
On Mavericks and other systems using libc++, only C++11 support is provided. Some things, including the hash class, are moved from the tr1 namespace to std. This patch is adapted from [homebrew pull 23867](Homebrew/legacy-homebrew#23867).
These changes allow shiboken-generated code to be compiled with more aggressive warning-reporting enabled (e.g., "-Wall -Wextra"). There are still a few initialization warnings but this patch eliminates the majority of warnings on Darwin+clang.
These still don't test for whether the given filename points to a file that actually exists (other errors might keep us from opening the file). But close enough.
Shiboken cannot parse many boost headers. Shiboken will *never* be able to parse many boost headers. When shiboken is preprocessing files, it should define a macro so that it is possible to handle projects that include boost without crashing. This commit adds the macro SHIBOKEN_SKIP. When it is defined, your source is being parsed by Shiboken.
The function assumes at least unary operators.
|
@mathstuf @vibraphone This MR rebases shiboken on top of the tagged 4.8 shiboken. |
|
Looks to have conflicts. |
|
Also, I just merged another PR onto smtk-head that silences SMTK warnings. Sorry for the extra work. |
|
Oh, the reason is that it's actually targeted to the wrong branch; it should go into the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.