Repository navigation
PEP 617: new PEG-based parser #84514
Description
Activity
Note: PEP-617 is currently under review by the Steering Council, but if they approve we'd like to get it into alpha 6, and reviews are welcome (even though we're still finagling some corner cases of the implementation).
Once PR 19503 will be merged, I would be interested to see if setjmp()/longjmp() can be avoided. I'm scared by these functions: they require that all functions in between setjmp() and longjmp() call stack have no state and don't need any cleanup at exit.
VIctor, you were very right about longjmp. See we-like-parsers#119
bpo-40334: Fix errors in parse_string.c with old compilers (GH-19666)
Pablo told me in private that he plans to add a buildbot worker to test the old parser. So this change is fine.
Looks like the build changes do not work with a build directory outside of the source directory:
mkdir build && cd build && ../configure && make
gcc -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -I../Include/internal -IObjects -IInclude -IPython -I. -I../Include -DPy_BUILD_CORE -o Parser/pegen/pegen.o ../Parser/pegen/pegen.c
error: unable to open output file 'Parser/pegen/pegen.o': 'No such file or directory'
1 error generated.
make: *** [Parser/pegen/pegen.o] Error 1Lots of build processes depend on this, like for putting out a release.
Looks like the build changes do not work with a build directory outside of the source directory:
Opened #19667. Ned, could you review?
bpo-40334: Rename PyConfig.use_peg to _use_peg_parser (GH-19670)
This change removes sys.flags.use_peg which was only used in tests. If someone sees a good reason, we may add it back. In the meanwhile, test.support.use_old_parser() can be used.
I didn't like the idea of having a new sys.flags.use_peg flag appears in 3.9 but disappears in 3.10.
FYI sys.flags still supports the tuple API! Example:
>>> sys.flags[9] 0I have no idea what is this 10th member of sys.flags :-)
test_peg_generator emits compiler warnings:
https://buildbot.python.org/all/#/builders/612/builds/283
0:08:01 load avg: 1.40 [423/423/1] test_peg_generator passed (7 min 4 sec)
/tmp/tmp0vbqe8gp/parse.c: In function ‘start_rule’:
/tmp/tmp0vbqe8gp/parse.c:32:35: warning: passing argument 2 of ‘_PyPegen_lookahead’ from incompatible pointer type [-Wincompatible-pointer-types]
32 | _PyPegen_lookahead(1, _PyPegen_name_token, p)
| ^~~~~~~~~~~~~~~~~~~
| |
| struct _expr * ()(Parser *)
In file included from /tmp/tmp0vbqe8gp/parse.c:2:
/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-aarch64.lto-pgo/build/Parser/pegen/pegen.h:90:36: note: expected ‘void * ()(Parser *)’ but argument is of type ‘struct _expr * ()(Parser *)’
90 | int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
| ~~~~~~~^~~~~~~~~~~~~~~
/tmp/tmp54o68k3n/parse.c: In function ‘start_rule’:
/tmp/tmp54o68k3n/parse.c:32:35: warning: passing argument 2 of ‘_PyPegen_lookahead’ from incompatible pointer type [-Wincompatible-pointer-types]
32 | _PyPegen_lookahead(0, _PyPegen_name_token, p)
| ^~~~~~~~~~~~~~~~~~~
| |
| struct _expr * ()(Parser *)
In file included from /tmp/tmp54o68k3n/parse.c:2:
/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-aarch64.lto-pgo/build/Parser/pegen/pegen.h:90:36: note: expected ‘void * ()(Parser *)’ but argument is of type ‘struct _expr * ()(Parser *)’
90 | int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
| ~~~~~~~^~~~~~~~~~~~~~~test_peg_generator emits compiler warnings
These are expected. Is this a problem?
91 remaining items
One minor nit: We're getting a nuisance compiler warning:
test_peg_generator passed (2 min 40 sec)
/var/folders/1b/3499qp8s7xv5w0fvjcgl45100000gn/T/tmp90rifd5z/parse.c:97:19: warning: code will never be executed [-Wunreachable-code]
p->mark = _mark;
^~~~~
1 warning generated.I'm not getting any compiler warnings on macOS (clang) and on Ubuntu (gcc) and I can't find any related warnings on the Windows Github Actions logs either. Could you maybe post a verbose log of test_peg_generator, Raymond?
All parts of the implementation are now in. New issues should be opened for any potential bugs.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: