Strip export annotations

[bloodwiing]

Working on #38 I came across @export_group requirement to end in a newline and considered that annotations like this are not even required for an exported game.

Which made me think that there are some tokens in scripts that could be removed with no harm.

Similarly by testing (4.3 release) I found that .tscn files can assign to any variable, @export is not required it simply visually displays it in the editor.

So it would seem plausible (and especially easy) to remove every @export_*.

This wouldn't change much how the code looks or reads, but opening the exported project in the Editor would make the project self-destructive as saving any scene will recreate the .tscn file, but this time without any @export it will delete all script parameters from the scene.
Additionally more complex @exports such as @export_enum would be harder to decipher.

[bloodwiing]

I would not mind to write it, but with how many PRs are pending I'm slightly concerned for merge conflicts.

Not sure how to approach handling @annotations better, maybe have it have its own type like NodePath has right now? And instead of hard-coding what could be supported we could pick up any valid unicode identifier since Godot will automatically error if the annotation does not exist.

gdmaim/addons/gdmaim/obfuscator/script/tokenizer/token.gd

Lines 4 to 18 in e643266

	enum Type {
	NONE = 0,
	SYMBOL = 2^0,
	KEYWORD = 2^1,
	LITERAL = 2^2,
	NUMBER_LITERAL = 2^3,
	STRING_LITERAL = 2^4,
	NODE_PATH = 2^5,
	PUNCTUATOR = 2^6,
	OPERATOR = 2^7,
	COMMENT = 2^8,
	WHITESPACE = 2^9,
	IDENTATION = 2^10,
	LINE_BREAK = 2^11,
	}

Also, uh, random question but: was this meant to be an enum of XORs..? It confused me when I was writing some PRs xd

[cherriesandmochi]

Working on #38 I came across @export_group requirement to end in a newline and considered that annotations like this are not even required for an exported game.

Which made me think that there are some tokens in scripts that could be removed with no harm.

Yes, I had planned to remove redundant tokens like @export_group, @export_category and @warning_ignore. Should probably just use the existing RegEx pass to do that.

Similarly by testing (4.3 release) I found that .tscn files can assign to any variable, @export is not required it simply visually displays it in the editor.

So it would seem plausible (and especially easy) to remove every @export_*.

This wouldn't change much how the code looks or reads, but opening the exported project in the Editor would make the project self-destructive as saving any scene will recreate the .tscn file, but this time without any @export it will delete all script parameters from the scene. Additionally more complex @exports such as @export_enum would be harder to decipher.

Oh, that's a very good catch. Should be pretty easy to implement too!

[cherriesandmochi]

I would not mind to write it, but with how many PRs are pending I'm slightly concerned for merge conflicts.

Yea, I hope I can merge most of the PRs soon, so I can start working on stuff again. Though, I reckon that I'm gonna have to solve a lot of merge conflicts anyway, so there's that.

Not sure how to approach handling @annotations better, maybe have it have its own type like NodePath has right now? And instead of hard-coding what could be supported we could pick up any valid unicode identifier since Godot will automatically error if the annotation does not exist.

That does sound like a good idea. Everything that makes the tokenizer less clunky is more than welcome haha.

gdmaim/addons/gdmaim/obfuscator/script/tokenizer/token.gd

Lines 4 to 18 in e643266

	enum Type {
	NONE = 0,
	SYMBOL = 2^0,
	KEYWORD = 2^1,
	LITERAL = 2^2,
	NUMBER_LITERAL = 2^3,
	STRING_LITERAL = 2^4,
	NODE_PATH = 2^5,
	PUNCTUATOR = 2^6,
	OPERATOR = 2^7,
	COMMENT = 2^8,
	WHITESPACE = 2^9,
	IDENTATION = 2^10,
	LINE_BREAK = 2^11,
	}

Also, uh, random question but: was this meant to be an enum of XORs..? It confused me when I was writing some PRs xd

Now that I think about it, I don't remember why I set the types up as bit flags. I'm pretty sure I never assign more than one type to a token. Maybe I wanted to do something like this to quickly check if a token is one of certain types:
(Token.Type.WHITESPACE | Token.Type.IDENTATION | Token.Type.LINEBREAK) & token

[bloodwiing]

Now that I think about it, I don't remember why I set the types up as bit flags. I'm pretty sure I never assign more than one type to a token. Maybe I wanted to do something like this to quickly check if a token is one of certain types: (Token.Type.WHITESPACE | Token.Type.IDENTATION | Token.Type.LINEBREAK) & token

Well an enum is an enum, but I was more focused on...

Cause SYMBOL is equal to 2, KEYWORD to 3 and even LITERAL equals 0 which clashes with NONE.

[cherriesandmochi]

Now that I think about it, I don't remember why I set the types up as bit flags. I'm pretty sure I never assign more than one type to a token. Maybe I wanted to do something like this to quickly check if a token is one of certain types: (Token.Type.WHITESPACE | Token.Type.IDENTATION | Token.Type.LINEBREAK) & token

Well an enum is an enum, but I was more focused on...

Cause SYMBOL is equal to 2, KEYWORD to 3 and even LITERAL equals 0 which clashes with NONE.

...

For some reason I thought that was the power operator... Don't know why either, because I've never set bitflags up like that before.
Yeah uh, definitely have to change that.