mirror of
https://github.com/open-goal/jak-project.git
synced 2024-10-20 11:26:18 -04:00
c162c66118
This PR does two main things: 1. Work through the main low-hanging fruit issues in the formatter keeping it from feeling mature and usable 2. Iterate and prove that point by formatting all of the Jak 1 code base. **This has removed around 100K lines in total.** - The decompiler will now format it's results for jak 1 to keep things from drifting back to where they were. This is controlled by a new config flag `format_code`. How am I confident this hasn't broken anything?: - I compiled the entire project and stored it's `out/jak1/obj` files separately - I then recompiled the project after formatting and wrote a script that md5's each file and compares it (`compare-compilation-outputs.py` - The results (eventually) were the same:  > This proves that the only difference before and after is non-critical whitespace for all code/macros that is actually in use. I'm still aware of improvements that could be made to the formatter, as well as general optimization of it's performance. But in general these are for rare or non-critical situations in my opinion and I'll work through them before doing Jak 2. The vast majority looks great and is working properly at this point. Those known issues are the following if you are curious: 
122 lines
4.2 KiB
C++
122 lines
4.2 KiB
C++
#pragma once
|
|
|
|
#include <set>
|
|
#include <string>
|
|
|
|
#include "common/formatter/formatter_tree.h"
|
|
|
|
namespace formatter_rules {
|
|
|
|
extern const std::set<std::string> constant_types;
|
|
namespace constant_list {
|
|
bool is_constant_list(const FormatterTreeNode& node);
|
|
}
|
|
|
|
// The formatter will try to collapse as much space as possible in the top-level, this means
|
|
// separating forms by a single empty blank line
|
|
//
|
|
// The exception are comments, top level comments will retain their following blank lines from the
|
|
// original source
|
|
// - this could be none, in the case where a comment is directly next to a form (like this one!)
|
|
// - you don't want them to be separated!
|
|
// - or this could be top level comments / comment blocks documenting things but not being
|
|
// associated with a form
|
|
// - in this case, you want them to remain separated
|
|
//
|
|
// Reference - https://github.com/kkinnear/zprint/blob/main/doc/options/blank.md
|
|
namespace blank_lines {
|
|
bool should_insert_blank_line(const FormatterTreeNode& containing_node,
|
|
const FormatterTreeNode& node,
|
|
const int index);
|
|
} // namespace blank_lines
|
|
|
|
// TODO:
|
|
// - align consecutive comment lines
|
|
// - if/when the formatter is concerned with line length, there are implications here
|
|
//
|
|
// Reference - https://github.com/kkinnear/zprint/blob/main/doc/options/comments.md
|
|
namespace comments {
|
|
std::vector<std::string> format_block_comment(const std::string& comment);
|
|
}
|
|
|
|
// Paired elements in a list will be kept in-line rather than the default new-line indentation
|
|
// For example:
|
|
// (:msg "hello world" :delay 100 :fn (lambda () (+ 1 1)))
|
|
// Would typically become:
|
|
// (:msg
|
|
// "hello world"
|
|
// :delay
|
|
// 100
|
|
// :fn
|
|
// (lambda ()
|
|
// (+ 1 1)))
|
|
// But with constant pairs:
|
|
// (:msg "hello world"
|
|
// :delay 100
|
|
// :fn
|
|
// (lambda ()
|
|
// (+ 1 1)))
|
|
//
|
|
// Reference - https://github.com/kkinnear/zprint/blob/main/doc/options/constantpairs.md
|
|
namespace constant_pairs {
|
|
const static int min_pair_amount = 4;
|
|
|
|
// Determines if the given element is the second element in a constant pair, if it is then we would
|
|
// usually want to elide the new-line in whatever code that applies it
|
|
//
|
|
// This is true if:
|
|
// - the element is in a list
|
|
// - the element is preceeded by a keyword
|
|
// - the element is a:
|
|
// - keyword, symbol, string, number, or boolean
|
|
bool is_element_second_in_constant_pair(const FormatterTreeNode& containing_node,
|
|
const FormatterTreeNode& node,
|
|
const int index);
|
|
bool is_element_second_in_constant_pair_new(const FormatterTreeNode& prev_node,
|
|
const FormatterTreeNode& curr_node);
|
|
bool form_should_be_constant_paired(const FormatterTreeNode& node);
|
|
} // namespace constant_pairs
|
|
|
|
// There are two main types of indentations "flow"s and "hang"s
|
|
// (this is
|
|
// a
|
|
// hang)
|
|
// (this
|
|
// is
|
|
// a
|
|
// flow)
|
|
//
|
|
// `flow` is the default indentation mode and right now the determination between the two is down to
|
|
// manual configuration based on the head of the form. In general, we only `flow` or `hang` if the
|
|
// form cannot fit on the current line.
|
|
//
|
|
// Additionally, if the head of the form is a constant we `flow` with an indent of `1` instead of
|
|
// `2`
|
|
//
|
|
// By default, we always hang unless:
|
|
// - the head-form overrides the configuration
|
|
// - TODO it will use more lines than the flow approach
|
|
//
|
|
// Reference - https://github.com/kkinnear/zprint/blob/main/doc/options/indent.md
|
|
namespace indent {
|
|
const static int line_width_target = 120;
|
|
|
|
} // namespace indent
|
|
|
|
// Let forms fall into two main categories
|
|
// - Ones that can be entirely inlined
|
|
// - Ones that cannot
|
|
//
|
|
// Single line let forms:
|
|
// - If there is a single binding, let it continue to be one line
|
|
// - otherwise, flow it just as a multi-line let would be done
|
|
//
|
|
// For multi-line let forms, the difficulty is how to format the binding:
|
|
// - align the bindings to within the binding list (single indent space)
|
|
// - always format the binding value on the same line as the binding, no new lines
|
|
// - forms inside the let binding are flowed
|
|
//
|
|
// Reference - https://github.com/kkinnear/zprint/blob/main/doc/options/let.md
|
|
namespace let {} // namespace let
|
|
} // namespace formatter_rules
|