Fixed: linking errors (#1)

* added lexer and updated docs * Fixed: linking errors * fixed clang tidy errors and added panic mode for lexing * added main file dummy tests Co-authored-by: Shuvayan Ghosh Dastidar <[email protected]>
TheSYNcoder · Apr 24, 2021 · df0592d · df0592d
1 parent 636f40a
commit df0592d
Show file tree

Hide file tree

Showing 16 changed files with 495 additions and 22 deletions.
diff --git a/.github/workflows/build_tests.yml b/.github/workflows/build_tests.yml
@@ -47,4 +47,3 @@ jobs:
           working-directory: ./build
           run: |
              bash <(curl -s https://codecov.io/bash)
-
diff --git a/README.md b/README.md
@@ -16,16 +16,41 @@ This is the official Jadavpur University Compiler Compiler repository.
 The JuCC project is built and tested on **Ubuntu 20.04**.
 
 ```
-git clone https://github.com/TheSYNcoder/JuCC
-cd JuCC
-sudo ./script/installation/packages.sh
-mkdir build
-cd build
-cmake -GNinja -DCMAKE_BUILD_TYPE=Release ..
-ninja jucc
-./bin/jucc
+$ git clone https://github.com/TheSYNcoder/JuCC
+$ cd JuCC
+$ sudo ./script/installation/packages.sh
+$ mkdir build
+$ cd build
+$ cmake -GNinja -DCMAKE_BUILD_TYPE=Release ..
+$ ninja jucc
+$ ./bin/jucc
 ```
 
+To run the unit tests provided, 
+
+```
+$ mkdir build
+$ cd build
+$ cmake -GNinja -DCMAKE_BUILD_TYPE=Release ..
+$ ninja
+$ ninja test
+
+```
+
+Before pushing or making a pull request
+
+```
+$ ninja
+$ ninja check-format
+$ ninja check-clang-tidy
+$ ninja check-lint
+$ ninja test ( The tests must pass, compulsory !! )
+
+```
+
+To add a new unit test, make a folder with the same relative path as in the src folder, and define your test. Please refer to [docs](https://github.com/TheSYNcoder/JuCC/tree/main/docs/) for more details about writing tests using the [googletest](https://github.com/google/googletest) framework.
+
+
 Additional Notes:
 - If you know what you're doing, install the prerequisite packages from `./script/installation/packages.sh` manually.
 

diff --git a/docs/README.md b/docs/README.md
@@ -37,7 +37,7 @@ You should learn a little about the following:
 - You should know these targets.
   - `jucc`: Building will build the `jucc` binary and all its dependencies.
   - `jucc_benchmark`: Building will build and link the `jucc` object file to the `benchmark` library. Running will run the benchmarks.
-  - `test`: Building will run all unit tests using `gtest`.
+  - `test`: Building will run all unit tests using `gtest`. This will not show specifics of failed test, run `build/bin/jucc_test` for detailed info.
   - `format`: Building will run the formatter `clang-format` on the codebase with our rules. Use this every time right before you commit and right before you make a pull request!
   - `check-format`: Building will check if the codebase is correctly formatted according to `clang-format` with our rules.
   - `check-clang-tidy`: Building will check if the codebase passes the `clang-tidy` static analyzer tests with our rules.
@@ -65,7 +65,13 @@ If you run into issues, you may need your default `python` to point to a `python
 
 ### Running tests locally
 
-Use `make test` or `ninja test` to run inside your build folder.
+Use `make test` or `ninja test` to run inside your build folder to run all tests.
+
+For detailed test info:
+1. Go to the folder: `cd ~/JuCC/build`
+2. Generate optimized config with `cmake -GNinja .. -DCMAKE_BUILD_TYPE=Release`
+3. Build project with `ninja`
+4. Run `./bin/jucc_test`
 
 ### Benchmarks
 

diff --git a/docs/cpp_guidelines.md b/docs/cpp_guidelines.md
@@ -111,7 +111,7 @@ If you need to do complex debugging, you may want to check out the following lin
 
 Unit tests are critical for ensuring the correct functionality of your modules and reduce time spent on debugging. It can help prevent regressions. We use [googletest](https://github.com/google/googletest), a nice unit-testing framework for C++ projects. 
 
-You should write unit test cases for each class/algorithm that you have added or modified. See the testing section for detail. Try to come up with test cases that make sure that the module exhibits the desired behavior. Some developers even suggest writing the unit tests before implementing the code. Make sure that you include corner cases, and try to find off-by-one errors. 
+You should write unit test cases for each class/algorithm that you have added or modified. See the testing section for detail. Try to come up with test cases that make sure that the module exhibits the desired behavior. Some developers even suggest writing the unit tests before implementing the code. Make sure that you include corner cases, and try to find off-by-one errors.
 
 ## Documentation
 

diff --git a/docs/tech_clangtools.md b/docs/tech_clangtools.md
@@ -66,7 +66,7 @@ Check the [official documentation](https://clang.llvm.org/docs/ClangFormat.html)
 
 **Gotchas**
 
-1. We use the [run_clang_format.py](https://github.com/TheSYNcoder/JuCC/blob/master/build_support/run_clang_format.py) to automate the workflow.
+1. We use the [run_clang_format.py](https://github.com/TheSYNcoder/JuCC/blob/main/build_support/run_clang_format.py) to automate the workflow.
 
 ## Summary
 

diff --git a/docs/tech_git.md b/docs/tech_git.md
@@ -22,14 +22,14 @@ Stash is very useful. For example, you will use it before/after (push/pop) merge
 * view content of your stash: git stash show -p `stash@\{0\}`
 
 ### Rebase or how to screw the history
-**Never** rebase commits that were pushed remotely. Rebase can be used to improve your current patch set, or to fast-forward-merge after a fetch. For better software engineering we **never** directly merge the upstream master when doing local development. When accepting a PR, we expect you to fetch the upstream master to your local repository, and rebase all the changes in your local branch on top of the upstream master.
-* The rebase command: git rebase -i `<upstream master branch>`
+**Never** rebase commits that were pushed remotely. Rebase can be used to improve your current patch set, or to fast-forward-merge after a fetch. For better software engineering we **never** directly merge the upstream main when doing local development. When accepting a PR, we expect you to fetch the upstream main to your local repository, and rebase all the changes in your local branch on top of the upstream main.
+* The rebase command: git rebase -i `<upstream main branch>`
 * Cancel it : git rebase --abort
 * Resolve conflict: git mergetool `<file>`
 * Continue rebase: git rebase --continue
 
 ### Branch or how to separate your work by feature
-Please note that master is actually the default branch
+Please note that main is actually the default branch
 * List branches: git branch -v
 * Switch to another branch: git checkout `<branch>`
 * Creates: git branch `<branch>`
@@ -39,11 +39,11 @@ Please note that master is actually the default branch
 # Git use case example
 
 ### Branch management
-Let's say you want to rebase your current branch topic-v1 to topic-v2 with new additions. Note: topic-v1 could also be master too.
+Let's say you want to rebase your current branch topic-v1 to topic-v2 with new additions. Note: topic-v1 could also be main too.
 * Go to current branch: git checkout topic-v1
 * Create a new one: git branch topic-v2
 * Go into the new branch: git checkout topic-v2
-* Set the reference: git branch --set-upstream-to=origin/master topic-v2 
+* Set the reference: git branch --set-upstream-to=origin/main topic-v2 
 * Rebase: git rebase -i
 * ...
 

diff --git a/src/include/lexer/lexer.h b/src/include/lexer/lexer.h
@@ -0,0 +1,91 @@
+#ifndef JUCC_LEXER_H
+#define JUCC_LEXER_H
+
+#include <cctype>
+#include <cstdio>
+#include <fstream>
+#include <iostream>
+#include <string>
+
+namespace jucc {
+
+enum Token {
+  TOK_EOF = -1,
+  TOK_IDENTIFIER = -2,
+  TOK_DECIMAL = -3,
+  TOK_FRACTIONAL = -4,
+
+  // Conditionals
+  TOK_IF = -6,
+  TOK_ELSE = -7,
+
+  // Data types
+  TOK_INT = -8,
+  TOK_FLOAT = -9,
+  TOK_VOID = -10,
+  // error
+  TOK_ERROR = -100,
+
+  // punctuation tokens
+
+  TOK_SEMICOLON = -11,     // ;
+  TOK_CURLY_OPEN = -12,    // {
+  TOK_CURLY_CLOSE = -13,   // }
+  TOK_PAREN_OPEN = -14,    // (
+  TOK_PAREN_CLOSE = -15,   // )
+  TOK_DOT = -16,           // .
+  TOK_COMMA = -17,         // ,
+  TOK_LEFT_SHIFT = -18,    // <<
+  TOK_RIGHT_SHIFT = -19,   // >>
+  TOK_LESS_THAN = -20,     // <
+  TOK_GREATER_THAN = -21,  // >
+  TOK_EQUAL_TO = -22,      // ==
+  TOK_ASSIGNMENT = -23,    // =
+  TOK_COMMENT = -24,       //  //
+  TOK_LITERAL = -25,       // "c++"
+  TOK_CHARACTER = -26,     // 'c'
+
+  // cout, cin
+
+  TOK_COUT = -27,  // cout
+  TOK_CIN = -28,   // cin
+};
+
+class Lexer {
+ public:
+  /**
+   * used to store a identifier token
+   */
+  std::string identifier_string_;
+  /**
+   * used to store a corresponding error token
+   * suppose a numerical token 16.3ere which is
+   * neither a numerical token or a identifier
+   */
+  std::string error_string_;
+  /**
+   * used to store a literal string
+   * literal strings are of type "a string"
+   */
+  std::string literal_string_;
+  /**
+   * used to store the value of the integer token
+   * during tokenization.
+   */
+  int intval_;
+  /**
+   * used to store the value of the float token
+   * during tokenization.
+   */
+  double floatval_;
+
+  /**
+   * Takes a ifstream object as input and gets the next character
+   * from the input file and returns the appropriate token.
+   */
+  int GetToken(std::ifstream &is);
+};  // class Lexer
+
+}  // namespace jucc
+
+#endif
diff --git a/src/include/main/jucc.h b/src/include/main/jucc.h
@@ -2,12 +2,13 @@
 #define JUCC_JUCC_H
 
 #include <iostream>
+#include <string>
 
 namespace jucc {
 /**
  * Dummy function to test setup clang and build config
  */
-void Hello();
+std::string Hello();
 
 /**
  * Dummy function increments computes x + y the retarded way
Original file line number	Diff line number	Diff line change
Expand Up		@@ -47,4 +47,3 @@ jobs:
		working-directory: ./build
		run: \|
		bash <(curl -s https://codecov.io/bash)