| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* c_parser: support parenthesized compounds
Support parenthesized compound statements as described here:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
* test_c_parser: support additional initializers
Add support to `expand_init` for additional `c_ast` types. If a type
is not explicitly handled, return the type name instead of `None`.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
* test_c_parser: test parenthesized compounds
Add parsing tests for various situations of parenthesized compound
statements. The complete tree generated by the test string is:
```
FileAST:
FuncDef:
Decl: foo, [], [], []
FuncDecl:
TypeDecl: foo, []
IdentifierType: ['void']
Compound:
Decl: a, [], [], []
TypeDecl: a, []
IdentifierType: ['int']
Compound:
Compound:
Constant: int, 1
Compound:
Constant: int, 1
Constant: int, 2
Decl: b, [], [], []
TypeDecl: b, []
IdentifierType: ['int']
Compound:
Constant: int, 1
Decl: c, [], [], []
TypeDecl: c, []
IdentifierType: ['int']
Decl: d, [], [], []
TypeDecl: d, []
IdentifierType: ['int']
Compound:
Decl: x, [], [], []
TypeDecl: x, []
IdentifierType: ['int']
Constant: int, 1
BinaryOp: +
ID: x
Constant: int, 2
Assignment: =
ID: a
Compound:
Decl: x, [], [], []
TypeDecl: x, []
IdentifierType: ['int']
Constant: int, 1
BinaryOp: *
Constant: int, 2
ID: x
```
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use the stdlib standard entry point for running tests through the
command:
python -m unittest discover
Docs: https://docs.python.org/3/library/unittest.html#unittest-test-discovery
This automatically looks for files with the test_ prefix and runs them
as tests. This removes the need for the custom test entry point script,
all_tests.py.
|
| |
|
| |
Python 3.9 was released on October 5th, 2020.
|
| |
|
|
|
|
| |
It's not currently required and adds all kinds of complexity for
managing and keeping up to date. GitHub actions do this well for pending
PRs. May reconsider and bring it back in the future.
|
| |
|
| |
The project now uses GitHub actions and Travis does not run.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
[no fix yet]
|
| |
|
|
| |
We run Windows tests through GitHub actions now
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
* Test change
* Add OS
|
| |\ |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Fix #385: generate code with nested sizeofs
* Fix #378: replace assertion with check
Only the assertion inside `_build_function_definition` is replaced. The
assertion is not appropriate because there are possible inputs that
would trigger the assertion, they're just grammatically incorrect. Thus,
it is replaced with a check that raises `ParseError` on failure.
* Fix #379: parse struct with nested enum
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Based on #358 by @WasabiFan
Fixes #358
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Recognize integer multicharacter constants like 'ABCD'
The feature I am adding is defined here - 5th case.
https://en.cppreference.com/w/c/language/character_constant
Also here: 6.4.4.4.10 of C99.
Put simply, pycparser thought a statement like this is an error:
int a = 'ABCD';
However it is not.
It is likely possible to just modify char_const regular expression in c_lexer.py:240 to allow longer characters, but the way it is done in this PR - multicharacter constants are clearly separated. I am also limiting the length of multicharacter const integers to 4 characters - this matches VS compiler behavior (gcc allows any length with a warning) and lets pycparser NOT consider lengthy single-quoted strings as integers - these would be nonsensical anyway.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix slow backtracking when parsing strings (no external deps)
Fixes #61
This uses negative lookaheads to avoid ambiguity in how string should be
parsed by the regex.
- https://docs.python.org/2/library/re.html#regular-expression-syntax
- Previously, if it didn't immediately succeed at parsing an escape
sequence such as `\123`, it would have to try `\1`+`23`, `\12` + `3`,
and `\123`, which multiplied the time taken by 3 per additional escape
sequence. This solves that by only allowing `\123`
- The same fix was added for hex escapes.
Also fix a test that relied on the incorrect handling of regexes.
The implementation documentation says that it intends to allow
**decimal** escapes permissively.
* WIP debug
* Fix ambiguity caused by allowing #path directives
Solve this by allowing "\x" when not followed by hex,
in the regular string literal.
In the previous commits,
`\x12` could be parsed both as `\x`+`12` and `\x12`,
which caused exponential options for backtracking.
* Document changes to lexer, remove debug code
* Optimize this for strings
|
| | |
|
| |
|
|
|
| |
Label .ppout files as vendored so Github doesn't count them as pycparser's
source
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix error transforming an empty switch
The parser would crash on that line for `switch(1) {}`
because NoneType is not iterable.
Fixes #345
* Add a test of empty switch statements
* Address review comments
|
