compose-generator / ccom Goto Github PK

This (buffering a Token) should definitely be part of the lexer and not the parser.
The lexer should have methods like lookAheadToken() and advance().

Is there a startsWith() method in C++?

Even though you check the look ahead in the switch statement, we should use expect() and expect the indivdual chars of - for example - a line comment identifier.

This bug was found when developing Compose Generator. It appears when not specifing a langage and feeding CCom with a Dockerfile.

After CCom finishes executing, the contents of the Dockerfile look like this:

panic: runtime error: slice bounds out of range [1:0]

goroutine 1 [running]:
main.getCommentIdenFromLang(0x0, 0x0, 0x7ffc4edd2c14, 0x59, 0xc0000575d0, 0x76b020, 0x76b020, 0x0, 0x41311d, 0xc000016cb8)
	/home/runner/work/ccom/ccom/cli/preprocessor.go:157 +0x2a5
main.analyze(0xc0000e7c20, 0xc0000e7c68, 0xc0000e7c30, 0x0, 0x0, 0xc0000e7c90, 0xc0000e7c48, 0xc0000e7c58, 0x580000c000083500)
	/home/runner/work/ccom/ccom/cli/preprocessor.go:103 +0x24e
main.processInput(0x7ffc4edd2c14, 0x59, 0x600ad3, 0x3, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7ffc4edd249d, ...)
	/home/runner/work/ccom/ccom/cli/preprocessor.go:32 +0xb7
main.main.func1(0xc00007ea80, 0x7ffc4edd2c14, 0x59)
	/home/runner/work/ccom/ccom/cli/ccom.go:97 +0x438
github.com/urfave/cli/v2.(*App).RunContext(0xc000080d00, 0x64a798, 0xc0000160c8, 0xc0000100a0, 0x5, 0x5, 0x0, 0x0)
	/home/runner/go/pkg/mod/github.com/urfave/cli/[email protected]/app.go:322 +0x6fe
github.com/urfave/cli/v2.(*App).Run(...)
	/home/runner/go/pkg/mod/github.com/urfave/cli/[email protected]/app.go:224
main.main()
	/home/runner/work/ccom/ccom/cli/ccom.go:116 +0xbdd

@marcauberer I think it'd be better to move the token types to the token header file.

Currently the cli throws following error when calling it with a single statement and without specifying a language via the --lang flag:

Please use lang 'auto' only in combination of valid file paths as file input

As a single file does not have comment identifiers, there should no language be needed to call CCom.

I wonder why we did not notice this earlier, but CCom currently does not support underscores in identifiers, which is definitely not the intended solution.
The problem is that isalnum() does not return true when the input is an underscore.

Following C++ compiler bug was found while testing for Compose Generator:

Following example:

...
#? if var.QUESTDB_ENABLE_PG_WIRE_ENDPOINT == "yes" {
#  - 8812:8812
#? }
#? if var.QUESTDB_ENABLE_INFLUX_LINE_ENDPOINT == "yes" {
#  - 9009:9009
#? }
#? if var.QUESTDB_ENABLE_HEALTH_ENDPOINT == "yes" {
#  - 9003:9003
#? }
...

which has following compile output if all conditions evaluate to true:

- 8812:8812 - 9009:9009 - 9003:9003

A workaround is to specify the conditional sections with a blank line between them:

...
#? if var.QUESTDB_ENABLE_PG_WIRE_ENDPOINT == "yes" {
#  - 8812:8812
#? }

#? if var.QUESTDB_ENABLE_INFLUX_LINE_ENDPOINT == "yes" {
#  - 9009:9009
#? }

#? if var.QUESTDB_ENABLE_HEALTH_ENDPOINT == "yes" {
#  - 9003:9003
#? }
...

We shouldn't increase the position after having reached EOF since this will screw up the Math.min(...) calculation otherwise.

In Java, I will implement it like this:

    /**
     * Consumes current char and advances to next character.
     */
    private void advance() {
        // Check for EOF
        if (position == file.length - 1) {
            next = 0; // 0 stands for EOF
            return;
        }

        // Increase head position (if not EOF)
        position++;

        // Read next char
        next = file[position];
        lineCol++;
    }

Why is this not a constructor?

Randomly stumbled over this bug while testing:

For example: someIdentifier == false returns true, but the inverse operation someIdentifier != true returns false.

The problem might be the evaluation of comparison statements in the interpreter.

You perform an advance() in if and else.

For Compose Generator we have following single statement:

services.database contains name == "elasticsearch"

This is problematic, because currently CCom terminates with an error if the key services.database does not exist. Same thing for compStmts.
As we currently only support a logical or (|) and no logical and, we cannot check if the key services.database exists before executing the statement above.

A solution for that would be to simply evaluate comp and contain statements to false if the key does not even exist.

Why do we add +1 here in the calculation of max look ahead? It should be sufficient to have a look ahead that is the max of the lengths of the comment chars. No need to look further.

We need an reader.advance() here. Otherwise this is going to end up in an infinite loop.

Discussed in #37

I guess it would make things a lot easier if you splitted up the lexer into a FileReader and a Lexer. This would be especially helpful for #15.

When having line breaks within one conditional section, these are removed after compiling. That causes potential parsing errors later for CG.

Example:

image: adguard/adguardhome:v${{ADGUARD_VERSION}}
container_name: ${{PROJECT_NAME_CONTAINER}}-frontend-adguard
restart: always
volumes:
  - ${{VOLUME_ADGUARD_DATA}}:/opt/adguardhome/work
  - ${{VOLUME_ADGUARD_CONFIG}}:/opt/adguardhome/conf
ports:
  - 53:53/tcp
  - 53:53/udp
#? if var.ADGUARD_ENABLE_DHCP == "true" {
#   - 67:67/udp
#   - 68:68/tcp
#   - 68:68/udp
#? }
#? if var.ADGUARD_ENABLE_UI == "true" {
#   - 80:80/tcp
#   - 443:443/tcp
#   - 443:443/udp
#   - 3000:3000/tcp
#? }
#? if var.ADGUARD_ENABLE_DOT == "true" {
#   - 853:853/tcp
#? }
#? if var.ADGUARD_ENABLE_DOQ == "true" {
#   - 784:784/udp
#   - 853:853/udp
#   - 8853:8853/udp
#? }
#? if var.ADGUARD_ENABLE_DNS_CRYPT == "true" {
#   - 5443:5443/tcp
#   - 5443:5443/udp
#? }

The log message from CG is:

ERROR: 2021/11/01 11:20:59.593752 load.go:170: Unable to load 'frontend-adguard-home': 1 error(s) decoding:

* error decoding 'Ports': Invalid ip address 53:53/udp
- 80:80/tcp - 443:443/tcp - 443: address 53:53/udp
- 80:80/tcp - 443:443/tcp - 443:: too many colons in address

What is the purpose of having an token where we can't be sure about what it is exactly? Could you just throw an error here?