joshdreamland / justdefineit

C/C++ Definition Parser

JustDefineIt ⁂ 

JustDefineIt is a C/C++ definition crawler. Its purpose is to harvest large amounts of information from C/C++ header files for use by modules outside of the compiler.

Pardon our dust

This project is under heavy rennovation. It was designed mostly between 2008 and 2010, served its purpose in some capacity for a decade, and now is in need of refresh for C++11-20.

Status:

• Master contains a new lexer (Jan2020) that should support everything up through C++20. Tests are written for some of the nichier caveats of the C preprocessor.
• Master has a lot of trouble with C++11-20. Missing features such as inline namespaces and variadic templates leave namespace std vacant when C++17 is set as the standard. The ENIGMA project works around this by asking G++ for its C++03 preprocessor configuration.
• Complicated specialization resolution is supported, but constexpr and parameter packs are not, so a lot of rennovation will be required there before fully-accurate comprehension can be achieved for new standards. Template comprehension through C++03 should be fine.
• Error reporting for tokens originating from macros is busted up pretty good.

Goals

This parser is designed to be small and portable, in the sense that it is cheap to add into an existing project's code base. Its goal is to be capable and modular enough to meet a variety of needs, from code completion in IDEs to—with some extension—use as a complete C++ interoperablity layer. It should carry as few dependencies as possible while remaining small and simple to understand (unlike Clang, which depends on parts of LLVM that has proven difficult to separate).

The code is set up to compile in GNU G++, using all warning flags except -winline and -weff-c++. The -werr, -pedantic, and -pedantic-errors flags are also set. The project is carefully monitored for memory leaks before each commit, via Valgrind, although the switch to smart pointers has largely obviated the need for this.

Docs are not currently included as anyone with Doxygen can simply generate them. Still, the best documentation is the kind that compiles. See MAIN.cc for examples of how to configure the tool.

Building

We support CMake, and ship a Code::Blocks project file.

justdefineit's Issues

halp

Some build errors on Windows system(msys2)

I have msys2, and have its 64bit GCC compiler install.
When using the cbp file under Code::Blocks, I see some build errors, such as this one:

[100.0%] g++.exe -Wshadow -Winit-self -Wredundant-decls -Wcast-align -Wundef -Wfloat-equal -Wunreachable-code -Wmissing-declarations -Wmissing-include-dirs -Wswitch-enum -Wswitch-default -Wmain -pedantic-errors -pedantic -Wextra -Wall -Werror -std=c++1z -g -D_GLIBCXX_DEBUG -DDEBUG_MODE -I.\src -c F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.cpp -o obj\Debug\src\System\lex_cpp.o
F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.cpp: In function 'llreader try_find_and_open(const llreader&, const jdi::Context*, std::string_view, bool, bool)':
F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.cpp:781:51: error: cannot convert 'const value_type*' {aka 'const wchar_t*'} to 'const char*'
  781 |     incfile.open((incfn = cur_path / fnfind).c_str());
      |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
      |                                                   |
      |                                                   const value_type* {aka const wchar_t*}
In file included from F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.h:41,
                 from F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.cpp:26:
.\src/General/llreader.h:74:25: note:   initializing argument 1 of 'void llreader::open(const char*)'
   74 |   void open(const char* filename);
      |             ~~~~~~~~~~~~^~~~~~~~
F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.cpp:784:72: error: cannot convert 'const value_type*' {aka 'const wchar_t*'} to 'const char*'
  784 |       incfile.open((incfn = (fdir = ctx->search_dir(i)) / fnfind).c_str());
      |                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
      |                                                                        |
      |                                                                        const value_type* {aka const wchar_t*}
In file included from F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.h:41,
                 from F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.cpp:26:
.\src/General/llreader.h:74:25: note:   initializing argument 1 of 'void llreader::open(const char*)'
   74 |   void open(const char* filename);
      |             ~~~~~~~~~~~~^~~~~~~~
F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.cpp: At global scope:
F:\code\justdefineit\JustDefineIt\src\System\lex_cpp.cpp:45:13: error: 'void donothing(int)' defined but not used [-Werror=unused-function]
   45 | static void donothing(int) {}
      |             ^~~~~~~~~

There are some other build errors, but let's fix them one by one.

doestnt pase c++ correctly

you should prolly fix this

When you dun hiding?

How long you gon hide for?

Good Job!

I just want to say your project is great. I see this project is similar to Code::Blocks' internal CodeCompletion C/C++ parser, I hope those two can help each other in the future.

halp

save me

Support expanding environment variables in strings passed to functions

This is something i'd like to be a checkbox in lateral/radialgm as an optional feature, and it will make strings slower but it will be good for projects which make heavy usage of environment variables so we won't have to constantly call environment_get_variable or c++ users wont have to getenv and concat a ton of times. It would be nice to have the option for having this done automatically

there could be an additional setting for whether to use $VARIABLE, %VARIABLE%. or ${VARIABLE} as those are only ways i've ever seen it done. Other options include if a variable isn't found whether to replace %VARIABLE%, etc with an empty string or leave it as-is. This i'm assuming is not something many people would want but it is a nice convenience for those who do need it.

Feel free to close this issue if you feel I'm beating a dead horse here.

halp

Performance drop; need symbol table

Performance is looking pretty terrible. The more academic approach to lexing is partially responsible, but the core issue is that COW strings are gone. We're now SSO, which means we're copying variable names and chunks of code everywhere. Things that used to be efficient by-value are now terrible. So, thanks, Google.

JDI needs to incorporate a proper symbol table to deal with that. We can just store everything in it, honestly; doc comments, too, as needed.

Some of the macro application logic is particularly egregious as it hybridizes the string copy performance hit with dropping the optimizations that made the code difficult to maintain.

Doesn't correctly parse functions with c++ custom return types and zero arguments

I discovered this in my reworking window_handle() ENIGMA pr.

window_t is the return type of window_handle(), which has zero arguments...

In the LateralGM IDE, if I write window_handle() it compiles, using this code as to C-style typedef window_t:

#if GM_COMPATIBILITY_VERSION <= 81
typedef unsigned long long window_t;
#else
typedef void * window_t;
#endif 

In the LateralGM IDE, if I write window_handle() it doesn't compiles, using this code as to C++-style typedef window_t:

#if GM_COMPATIBILITY_VERSION <= 81
using window_t = unsigned long long;
#else
using window_t = void *;
#endif 

Instead, it says undefined reference to function window_handle(). The only way to make ENIGMA correctly compile the latter code, (the C++-style), typedef, is by removing the parenthesis and treating the function like a constant by writing window_handle instead to compile at all.

I don't know if this has already been fixed, as fundies informed me we have a version of JDI that's 2 years behind the current one under the enigma-dev repository.