mori0091 / cparsec2 Goto Github PK

What's happen? Please describe the problem you met.
For skip1st(p1, p2), at the present, both p1 and p2 must be a CharParser.
I hope it will be more generic function.

Describe the solution you'd like
For skip1st(p1, p2), each p1 and p2 may be a one of the following type of:

• CharParser
• StringParser
• IntParser

For example:

parseTest(skip1st(char1('a'), string1("bc")), "abc"); // -> results (const char*)"bc"
parseTest(skip1st(string1("ab"), char1('c')), "abc"); // -> results (char)'c'

Describe alternatives you've considered

Additional context

Describe the bug
Cannot compile test/src/test_list.cpp

To Reproduce

# on Mingw64 w/ gcc 8.3.0
./build -s 

Expected behavior
Build and test should be completed successfully.

Development environment (please complete the following information):

• OS and version: [Mingw64]
• Compiler and version: [gcc 8.3.0, g++ 8.3.0]

Additional context
nullptr is recommended instead of NULL in modern C++.

What's happen?
We found that code coverage of some files are not reported, such as 'example/calc/src/main.c'.

What's expected?
Coverage of the projects' whole source code should be reported.

How to reproduce
See also CodeCov coverage report, and CircleCI report of 'coverage' task.

Further info (if available)
Maybe gcov is confused, since :

1. make is executed at for each (sub-)project directory.
2. Each (sub-)project has its own 'src/main.c' as follows :

• example/calc/src/main.c
• example/digit3/src/main.c
• example/digit3b/src/main.c
• example/mult/src/main.c
• src/main.c

Proposal (if available)
Shall we fix the GNUmakefile rules like as follows ?
For example in case of line 58 of GNUmakefile:

• before: @$(CC) $(CFLAGS) -c -o $@ $<
• after: @$(CC) $(CFLAGS) -c -o $@ $(realpath $<)

Describe the bug
Should update API Reference relative to #46

To Reproduce
Specification of macros for "Building block of Parser-combinators" are changed.
But docs is not updated.

Expected behavior
New spec. of macros should be described in docs/API.org

Development environment (please complete the following information):

• OS and version: [e.g. Ubuntu 18.04]
• Compiler and version: [e.g. gcc 7.4.0, g++ 7.4.0]

Additional context

Describe the bug
runParser(p, input) API returns broken result or causes crash, on MINGW environment.

To Reproduce
The following sample code fails on MINGW, though it passes on Ubuntu or MSYS.
Checkout the following branch, and do make test in bug/bug_20190925 sub-folder:
https://github.com/mori0091/cparsec2/tree/bug/runParser_returns_broken_result

/* -*- coding: utf-8-unix -*- */
#include <assert.h>
#include <cparsec2.h>

int main(void) {
  cparsec2_init();
  {
    /* the below should pass but fails */
    ParseResult(Char) r = runParser(anyChar, "abc");
    assert(r.consumed == 1);
    assert(r.succeeded);
    assert(r.ok == 'a');
  }
  cparsec2_end();
  return 0;
}

Expected behavior
runParser(p, input) should return correct result.

Development environment (please complete the following information):

• OS and version: Mingw64 ; Windows 10
• Compiler and version: gcc 9.2.0

Additional context
(1) CPARSEC2's self-test (src/main.c) was passed.
(2) But the sub-project (bug/bug_20190925/src/main.c) failed.
Note that (2) is same code as one of the test defined in (1).

Describe the bug
The following APIs were changed at #38 , but not reflected to docs.

• Macros for declaration/definition of PARSER(T)
• Macros for declaration/definition of parser-combinators
• Macros for declaration/definition of List(T) and Buff(T)

To Reproduce
See Building block of Parser-class section of docs/API.org

Expected behavior
At least the following contents should be described and/or updated:

• New ELEMENT_TYPE(List(T))
• New ELEMENT_TYPE(Buff(T))
• New RETURN_TYPE(PARSER(T))
• New TYPEDEF_PARSER(T, R)
• Changed DECLARE_PARSER(T)
• Changed DEFINE_PARSER(T, x) { /* print x */ }

Development environment (please complete the following information):

• OS and version: [e.g. Ubuntu 18.04]
• Compiler and version: [e.g. gcc 7.4.0, g++ 7.4.0]

Additional context
Maybe some macros (such as TYPEDEF_xx, DECLARE_xx, DEFINE_xx, GENERIC_xx, and other relative macros) should be described in another document.
Because these APIs are for developer of CPARSEC2 library, not for users of CPARSEC2 library at the present.

Describe the bug
./build.sh clean fails on WSL due to obj/*.d, which have been generated on Mingw64
(see also #9)

To Reproduce
NOTE: Supposing that the git's working-copy is shared by Mingw64 and WSL.

1. Run ./build.sh on Mingw64
2. Run ./build.sh clean on Ubuntu18.04 (WSL)
3. make command causes an error like as follows:

obj/seq.d:1: *** target pattern contains no '%'.  Stop.

obj/seq.d generated on Mingw64:

obj/seq.o: C:/msys64/home/mori0091/cparsec2/src/seq.c \
 include/cparsec2.h

Expected behavior
./build.sh clean (i.e. make clean) should clean up all artifacts successfully, even if it was a artifact generated on different environment.

Development environment (please complete the following information):
I'm using the following environments on Windows10:

• Msys w/ gcc 8.3.0
• Mingw64 w/ gcc 7.4.0
• Ubuntu 18.04 on WSL w/ gcc 7.4.0

Additional context
All the above environments shares git's working-copy.
But its file-path is different each other. For example:

• /home/mori0091/cparsec2 on Msys / Mingw64
• /mnt/c/msys64/home/mori0091/cparsec2 on Ubuntu on WSL

And $(realpath ...) function of GNU make produces such as

• /home/mori0091/cparsec2 on Msys
• C:/msys64/home/mori0091/cparsec2 on Mingw64 👎
• /mnt/c/msys64/home/mori0091/cparsec2 on Ubuntu on WSL

Therefore make on WSL is confused due to *.d which is generated on Mingw64.

Describe the bug
Relative to #28
Description of some parser-combinators should be updated.

• many(p) (refactored at #31)
• many1(p) (refactored at #31)
• seq(p, ...) (refactored at #32)
• cons(p, ps) (refactored at #34)

To Reproduce
See API docs.

Expected behavior
The above four parser-combinators are now a generic parser-combinator.
Supporting type of its arguments and return value (parser) should be described.

Development environment (please complete the following information):

• OS and version: [e.g. Ubuntu 18.04]
• Compiler and version: [e.g. gcc 7.4.0, g++ 7.4.0]

Additional context

Describe the bug
Some file's coverage seems wrong.

To Reproduce
Steps and/or code snippet to reproduce the behavior:
For example, 'src/oneOf.c'.
It is tested by 'test/src/test_oneOf.cpp', but CodeCov says its coverage is 0%.

Expected behavior
All test result must be reflected to the coverage report.

Development environment (please complete the following information):

• OS and version: [e.g. Ubuntu 18.04 on WSL]
• Compiler and version: [e.g. gcc 7.4.0, g++ 7.4.0]

Additional context
Maybe this is a usage issue of gcov.
When and where the gcov should be executed?

What's happen? Please describe the problem you met.
README seems too larger.
Shall you divide it into some sub-documents in docs folder?

Describe the solution you'd like
Here is my suggestion, for example:

• Extract Tutorial section into docs/Tutorial/*.org
  • docs/Tutorial.org ... summary of Tutorial contents
  • docs/Tutorial/tutrial01.org
  • docs/Tutorial/tutrial02.org
• Extract API section into docs/API/*.org
  • docs/API.org ... summary of API contents
  • docs/API/core.org
  • docs/API/*.org
• and the top-level README.org links to docs/Tutorial and docs/API folders

Describe alternatives you've considered

Additional context

What's happen? Please describe the problem you met.
The spec of number built-in parser is unclear.

Describe the solution you'd like
Please add description of number built-in parser to docs/API.org

Describe alternatives you've considered

Additional context

Proposal:

• remove Token type
• replace Token token(int type, PARSER(T) p with R token(PARSER(T) p)
  • where R is the result type of parse(p, src, ex)
• token(p) return a parser, which skip any leading white-spaces and return the result of p.

Reason why:
After We wrote the sample app example/calc, we noticed that:

• There are many parse(spaces, src, ex)
• Perhaps Token and token(type, p) is useless.
• token(p) is simpler, easy to use, and enough, we think.

What's happen? Please describe the problem you met.
A generic parser-combinator (such as either(p1, p2)) is not tested for PARSER(Int).
To test it, we need to implement a parser of PARSER(Int) type everytime...

Describe the solution you'd like
Supports a built-in parser of PARSER(Int) type.
For example, PARSER(Int) number which parses one or more digits and returns an integer.
If such one was available, we can use it to write testcase for a generic parser-combinator.
(and also to keep coverage higher)

Describe alternatives you've considered

Additional context

It is appreciate if there is more variation of examples. (in example folder)
For example :

• simple calculator :
  • which parse and evaluate integer expression and output result.
  • in expression, following token is available :
    • integer literal
    • + and - binary operator
    • * and / binary operator
    • ( expr ) expression grouped by parens

Describe the bug
Some test-case's name are misleading or confusing. (Perhaps garbage of copy & paste is left)
This is not a bug, but should be corrected.

To Reproduce
See 'test/src/test_oneOf.cpp' and 'test/src/test_noneOf.cpp'.
There is some misleading GIVEN("...") clause, for example:

  GIVEN("an input: \"a\" (i.e. SPC)") {
     ... snip ...
  }

What means "(i.e. SPC)" ? Isn't it garbage of copy & paste ?

Expected behavior
All such GIVEN(...) clause should be fixed as follows:

  GIVEN("an input: \"a\"") {
     ... snip ...
  }

Development environment (please complete the following information):

• OS and version: [e.g. Ubuntu 18.04 on WSL]
• Compiler and version: [e.g. gcc 7.4.0, g++ 7.4.0]

Additional context

• test/src/test_oneOf.cpp has 4 such same issue.
• test/src/test_noneOf.cpp has 4 such same issue.

We would like to add explanation and sort out about concept.

• What is parser?
• What is parser-class?
• What is parser-generator?
• What is parser-combinator?

What's happen? Please describe the problem you met.
There is non-generic parser-combinators, though it should be generic, such as for example many(p).
To make it more generic, we need List(T), a generic list container, and PARSER(List(T)).
For example:

PARSER(List(Int)) p = many(number);  // NOTE: `number` is a PARSER(Int)
List(Int) xs = parse(p, src, ex);  // xs is a list of int

Describe the solution you'd like
We need a generic container List(T), and parser-class PARSER(List(T)).
And List(Char) should be same as const char* if possible.

Describe alternatives you've considered
There is two major design of List container:

• LISP/Haskell like List (cons-cell)
• C++ STL like List (container and iterator)

I think "C++ STL like List" is better for C, because iterating a container by loop is better than recursive function call, in case of C/C++.

Additional context
To keep simple API, maybe it's better to define two set of APIs:

• List(T) and iterator API for List(T)
• List builder API for List(T) construction. (such as StringBuilder in Java)

Codacy is working fine for static code analysis, but its result is not shown on GitHub.
Because Codacy badge written in README.org do not work.

We need following two parser combinators :

• or(p1, p2) :

  • Create a parser, which
    • return p1's result if p1success, or
    • if p1 consumed one or more chars and failed, throw p1's error
    • if p1 consumed no chars and failed, return p2's result or throw p2's error

• tryp(p) :

  • Create a parser, which
    • return result of p if p success,
    • otherwise rewind the input-state back then throw p's error.

Describe the bug
Some parser-combinators should support PARSER(List(String)) and PARSER(List(Int))

• skip1st(p1, p2)
• either(p1, p2)
• tryp(p)
• token(p)

To Reproduce
For example:

PARSER(List(Int)) p1 = tryp(many(number)); // compile error
PARSER(String) digits = token(many1(digit));
PARSER(List(String)) p2 = token(many(digits)); // compile error
PARSER(List(Int)) p3 = skip1st("++", many(number)); // compile error
PARSER(List(Int)) p4 = either(many(number), skip1st("++", many(number))); // compile error

Expected behavior
The above four parser-combinators should support List(String) and List(Int).
And should be tested for List(String) and List(Int). (including above example code and more)

Development environment (please complete the following information):

• OS and version: [e.g. Ubuntu 18.04]
• Compiler and version: [e.g. gcc 7.4.0, g++ 7.4.0]

Additional context

Describe the bug
Description of cons(p,ps) seems wrong.

To Reproduce
See the description of cons(p, ps):

Create a parser of PARSER(List(T)) type, which

• apply p and parsers in the list ps to a text.
• return a list consists of the result of p and results of each parsers in ps.
• if any parser failed, throws an error of it.

The 2nd argument ps is not a list but a parser which returns a list.

Expected behavior
The description should be corrected as follows for example:

• cons(p, ps) creates a parser
  • the parser returns a list when it is applied to a text
    • the list is consists of the following:
      • the result of p and
      • elements of the result of ps.

Development environment (please complete the following information):

• OS and version: [e.g. Ubuntu 18.04]
• Compiler and version: [e.g. gcc 7.4.0, g++ 7.4.0]

Additional context