Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more lex tests #36

Merged
merged 11 commits into from
Jun 26, 2024
Merged

Conversation

JakeRoggenbuck
Copy link
Member

No description provided.

return 0;
}

int test_ttype_one_char() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to get some representation for failure paths, e.g. invalid tokens?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean as in testing that it fails gracefully and doesn't segfault or something if we ask ttype_string("/* This is not a token. */") or similar.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, testing doesn't segfault, it just prints the assert that failed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mean that the testing code itself might be broken, I mean testing whether ttype_string might fail gracefully or just crash or something. I think this is good to test because our system should be robust.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohh I see, yup we definitely should have that added. Same PR or later?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Later is probably fine.

if (isdigit(c)) {
return TT_LITERAL;
} else {
return TT_IDENTIFIER;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we know that everything not listed is an identifier?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great question. I think we might need to check for one character symbols that definitely aren't tokens or identifiers. I can only think of things like the @ symbol that isn't either, so we might want to have error handling for that later

tassert(strcmp(ttype_name(TT_PLUS), "+") == 0);
tassert(strcmp(ttype_name(TT_SIZEOF), "sizeof") == 0);
tassert(strcmp(ttype_name(TT_WHILE), "while") == 0);

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

testing this function is great! I am worried that as a lookup table with no information about the ordering of the enum, it is a bit fragile though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true. Having this is a good canary in the coal mine for names not working. If the tests break, any code that relies on the function will also break. It's a problem with how naming enums works in C in general so we should be careful with the use of the enum + name function.

Copy link
Contributor

@adamhutchings adamhutchings left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but merge conflicts :(

@JakeRoggenbuck
Copy link
Member Author

Looks good, but merge conflicts :(

Oh noooo

@JakeRoggenbuck
Copy link
Member Author

I will fix

Copy link
Contributor

@adamhutchings adamhutchings left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming the tests pass (which see PR #40 for why I'm not testing this myself), this looks good!

@JakeRoggenbuck
Copy link
Member Author

Yup, tests pass on this one. Tests however fail on main.

jccc (add-more-lex-testing) λ ./scripts/build.sh
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /home/jake/Repos/jccc/build
[  6%] Building C object CMakeFiles/jccc.dir/src/lexer/lex.c.o
[ 12%] Building C object CMakeFiles/jccc.dir/src/lexer/test_lexer.c.o
[ 18%] Building C object CMakeFiles/jccc.dir/src/driver/main.c.o
[ 25%] Linking C executable jccc
[ 50%] Built target jccc
[ 56%] Building C object CMakeFiles/test_jccc.dir/src/lexer/lex.c.o
[ 62%] Building C object CMakeFiles/test_jccc.dir/src/lexer/test_lexer.c.o
[ 68%] Building C object CMakeFiles/test_jccc.dir/src/testing/main.c.o
[ 75%] Linking C executable test_jccc
[100%] Built target test_jccc
jccc (add-more-lex-testing) λ ./build/test_jccc
Running tests from "test_lexer" ...
Running "test_ttype_name"
Running "test_ttype_from_string"
Running "test_ttype_many_chars"
Running "test_ttype_one_char"
Concluded tests from "test_lexer"
Running tests from "test_x86" ...
Running "test_init_int_literal"
Concluded tests from "test_x86"

@JakeRoggenbuck JakeRoggenbuck merged commit b8fe835 into jabacat:main Jun 26, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants