mirror of
https://github.com/open-goal/jak-project
synced 2026-05-26 15:46:14 -04:00
Tyler Wilding
d1ece445d4
Relates to #1353 This adds no new functionality or overhead to the compiler, yet. This is the preliminary work that has: - added code to the compiler in several spots to flag when something is used without being properly required/imported/whatever (disabled by default) - that was used to generate project wide file dependencies (some circulars were manually fixed) - then that graph underwent a transitive reduction and the result was written to all `jak1` source files. The next step will be making this actually produce and use a dependency graph. Some of the reasons why I'm working on this: - eliminates more `game.gp` boilerplate. This includes the `.gd` files to some extent (`*-ag` files and `tpage` files will still need to be handled) this is the point of the new `bundles` form. This should make it even easier to add a new file into the source tree. - a build order that is actually informed from something real and compiler warnings that tell you when you are using something that won't be available at build time. - narrows the search space for doing LSP actions -- like searching for references. Since it would be way too much work to store in the compiler every location where every symbol/function/etc is used, I have to do ad-hoc searches. By having a dependency graph i can significantly reduce that search space. - opens the doors for common shared code with a legitimate pattern. Right now jak 2 shares code from the jak 1 folder. This is basically a hack -- but by having an explicit require syntax, it would be possible to reference arbitrary file paths, such as a `common` folder. Some stats: - Jak 1 has about 2500 edges between files, including transitives - With transitives reduced at the source code level, each file seems to have a modest amount of explicit requirements. Known issues: - Tracking the location for where `defmacro`s and virtual state definitions were defined (and therefore the file) is still problematic. Because those forms are in a macro environment, the reader does not track them. I'm wondering if a workaround could be to search the reader's text_db by not just the `goos::Object` but by the text position. But for the purposes of finishing this work, I just statically analyzed and searched the code with throwaway python code.
33 lines
844 B
C++
33 lines
844 B
C++
#pragma once
|
|
|
|
#include <string>
|
|
#include <unordered_map>
|
|
|
|
#include "common/goos/Object.h"
|
|
|
|
class CompilerSettings {
|
|
public:
|
|
CompilerSettings();
|
|
bool debug_print_ir = false;
|
|
bool debug_print_regalloc = false;
|
|
bool disable_math_const_prop = false;
|
|
bool emit_move_after_return = true;
|
|
bool check_for_requires = false; // check for missing 'require' statements (TODO - does not work
|
|
// for virtual state usages or macro usages)
|
|
|
|
void set(const std::string& name, const goos::Object& value);
|
|
|
|
private:
|
|
void link(bool& val, const std::string& name);
|
|
|
|
enum class SettingKind { BOOL, STRING, INVALID };
|
|
|
|
struct SettingsEntry {
|
|
SettingKind kind = SettingKind::INVALID;
|
|
goos::Object value;
|
|
bool* boolp = nullptr;
|
|
};
|
|
|
|
std::unordered_map<std::string, SettingsEntry> m_settings;
|
|
};
|