As enum PrimitiveType is supposed to represent C++ types, having Int32
and UInt32 there is not correct.
This patch renames those values to Int and UInt.
This doesn't change the behavior, but makes it clearer that the types
for 'int' and 'unsigned int' are not necessarily 32 bits.
As enum PrimitiveType is supposed to represent C++ types, having Int64
and UInt64 there is not correct.
This patch renames those values to LongLong and ULongLong.
This doesn't change the behavior, but makes it clearer that the types
for 'long long' and 'unsigned long long' are not necessarily 64 bits.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@iki.fi>
As enum PrimitiveType is supposed to represent C++ types, having Int16
and UInt16 there is not correct.
This patch renames those values to Short and UShort.
This doesn't change the behavior, but makes it clearer that the types
for 'short' and 'unsigned short' are not necessarily 16 bits.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@iki.fi>
As enum PrimitiveType is supposed to represent C++ types, having Int8
and UInt8 there is not correct.
This patch removes those values. As Int8 and UInt8 were set to be
equivalent to Char and UChar, we can just change all references to Int8
and UInt8 to Char and UChar.
This doesn't change the behavior, but makes it clearer that the types
for 'char' and 'unsigned char' are not necessarily 8 bits.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@iki.fi>
The enum PrimitiveType represents, according to the comment, "the C++
built-in types.". However, it does not contain values for C++'s "long"
or "unsigned long", and the parser converts long to int. This is not
correct, and is a problem with 64bit support.
This patch adds Long and ULong values to PrimitiveType, and adds those
to all the switch-cases all around the code. For now Long and ULong are
handled exactly like Int and UInt, so this patch does not change
behavior.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@iki.fi>
Fix the following warning by renaming RawComment::FullComment to
FullCommentBlock.
In file included from ../../../src/CppParser/AST.cpp:8:0:
../../../src/CppParser/AST.h:783:18: warning: declaration of ‘CppSharp::CppParser::AST::FullComment* CppSharp::CppParser::AST::RawComment::FullComment’ [-fpermissive]
FullComment* FullComment;
^
../../../src/CppParser/AST.h:760:15: warning: changes meaning of ‘FullComment’ from ‘struct CppSharp::CppParser::AST::FullComment’ [-fpermissive]
struct CS_API FullComment : public Comment
^
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@iki.fi>
Fix the following warning by renaming RawComment::RawCommentKind to
Kind.
In file included from ../../../src/CppParser/AST.cpp:8:0:
../../../src/CppParser/AST.h:780:20: warning: declaration of ‘CppSharp::CppParser::AST::RawCommentKind CppSharp::CppParser::AST::RawComment::RawCommentKind’ [-fpermissive]
RawCommentKind RawCommentKind;
^
../../../src/CppParser/AST.h:765:13: warning: changes meaning of ‘RawCommentKind’ from ‘enum class CppSharp::CppParser::AST::RawCommentKind’ [-fpermissive]
enum struct RawCommentKind
^
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@iki.fi>
* Use clangIndex to identify declarations across translation units.
* Added new Find*ByUSR methods and removed unused Find*(IntPtr) methods.
* Added Depth/Index and IsParameterPack fields to TemplateParameterType.
* Fixed member initialization issues in C++ Method class.
* Added AST tests for function and class templates.
* All tests pass with new and old parser.
* Implemented missing parts in regards to class templates.
* Fixed couple of class member initialization issues in C++ AST classes.
* Make code more look alike so it's easier to compare them.
* All tests pass now with old and new parser. Especially the nasty STL one with the ostream typedef.
We should not need to do this, but Clang ignores the GCC flag "-fkeep-inline-functions" which we need to actually get these to be properly exported in a library...
This is a workaround for missing symbols when P/Invoking on the Mac for instance. There should be a working "-fkeep-inline-functions" switch available in Clang but upon reading the source code, it does not do anything besides consuming the option (not even a warning!).
The previous version did not handle methods properly and lead to duplicate definitions since it did not check for existing templates with the same signature.
We just parsed the function type "parameters" which does not even make sense from a type system point of view but it's useful in some instances in the generator when function types are "mappable" to function declarations.
Dimitar Dobrev
triton
Tomi Valkeinen
Elias Holzer
triton
Joao Matos