Compare commits

...

14 Commits

Author SHA1 Message Date
Anatol Belski
c6a2644a57 Prepare 2.2.0beta2 2019-02-11 22:09:08 -08:00
Anatol Belski
9ffa736cbc Update bison to 3.3.2 2019-02-11 21:59:18 -08:00
Anatol Belski
79fbcfee08 Upgrade bundled PHP to 7.3.2 2019-02-11 09:51:30 -08:00
Anatol Belski
f84b056d1c Make the major number optional and care about 8 2019-02-04 23:31:01 -08:00
Anatol Belski
0ab9b8ddc6 Add error check 2019-02-04 20:00:05 -08:00
Anatol Belski
794ef96470 Add 8.0 configs for PGO 2019-02-04 15:33:26 -08:00
Anatol Belski
cecf3df7f3 Back to dev 2019-01-12 22:05:55 +01:00
Anatol Belski
1e6ee7afaa Prepare 2.2.0beta1 2019-01-12 22:04:56 +01:00
Anatol Belski
05af1a3b06 Upgrade bundled PHP to 7.3.1 2019-01-12 18:41:21 +01:00
Anatol Belski
c748916f5c Back to dev
Also raise the version to 2.2.0 as some essential tool upgrades are to expect.
2019-01-12 16:17:01 +01:00
Anatol Belski
bebb84afd7 Prepare 2.1.10 2019-01-12 16:08:52 +01:00
Anatol Belski
841065efd4 One more version update 2019-01-08 17:57:31 +01:00
Anatol Belski
c726890170 Update versions in README 2019-01-08 17:55:26 +01:00
Anatol Belski
b2e52e36d8 Back to dev 2018-12-26 13:51:10 +01:00
29 changed files with 7766 additions and 26 deletions

View File

@@ -33,7 +33,7 @@ All the tools included are either scripts or 32-bit binaries. They are therefore
## Other tools
- `bison` 3.0.5, `re2c` 1.0.3, `lemon`
- `bison` 3.2.4, `re2c` 1.1.1, `lemon`
- `awk`, `gawk`, `sed`, `grep`
- `diff`, `diff3`, `patch`
- `md5sum`, `sha1sum`, `sha224sum`, `sha256sum`, `sha384sum`, `sha512sum`
@@ -62,7 +62,7 @@ It is not required to hold the source in the PHP SDK directory. It could be usef
- `git clone https://github.com/Microsoft/php-sdk-binary-tools.git c:\php-sdk`
- `cd c:\php-sdk`
- `git checkout php-sdk-2.0.12` or later
- `git checkout php-sdk-2.1.9` or later
- invoke `phpsdk-vc15-x64.bat`
- `phpsdk_buildtree phpmaster`
- `git clone https://github.com/php/php-src.git && cd php-src`, or fetch a zipball

View File

@@ -1 +1 @@
2.1.10beta1
2.2.0beta2

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

BIN
bin/php/libcrypto-1_1.dll Normal file

Binary file not shown.

Binary file not shown.

Binary file not shown.

BIN
bin/php/libssl-1_1.dll Normal file

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View File

@@ -41,7 +41,7 @@ class PGO
$dll = array_merge($dll, glob($this->php->getExtRootDir() . DIRECTORY_SEPARATOR . "php*.dll"));
/* find out next index */
$tpl = glob($this->php->getRootDir() . DIRECTORY_SEPARATOR . "php7{ts,}.dll", GLOB_BRACE)[0];
$tpl = glob($this->php->getRootDir() . DIRECTORY_SEPARATOR . "php{7,8,}{ts,}.dll", GLOB_BRACE)[0];
if (!$tpl) {
throw new Exception("Couldn't find php7[ts].dll in the PHP root dir.");
}

View File

@@ -66,6 +66,9 @@ class Lock
} else {
$this->fd = fopen($this->fn, "wb");
}
if (false === $this->fd) {
throw new Exception("Failed to open lock under '$this->fn'");
}
$this->locked = flock($this->fd, $flags, $this->wouldBlock);
return $this->locked;
}/*}}}*/

Binary file not shown.

View File

@@ -1,7 +1,7 @@
# bison-i18n.m4 serial 2
dnl Copyright (C) 2005-2006, 2009-2015, 2018 Free Software Foundation,
dnl Inc.
dnl Copyright (C) 2005-2006, 2009-2015, 2018-2019 Free Software
dnl Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,

View File

@@ -1,8 +1,9 @@
This directory contains data needed by Bison.
* Skeletons
Bison skeletons: the general shapes of the different parser kinds,
that are specialized for specific grammars by the bison program.
# Directory content
## Skeletons
Bison skeletons: the general shapes of the different parser kinds, that are
specialized for specific grammars by the bison program.
Currently, the supported skeletons are:
@@ -22,19 +23,18 @@ Currently, the supported skeletons are:
- glr.cc
A Generalized LR C++ parser. Actually a C++ wrapper around glr.c.
These skeletons are the only ones supported by the Bison team.
Because the interface between skeletons and the bison program is not
finished, *we are not bound to it*. In particular, Bison is not
mature enough for us to consider that "foreign skeletons" are
supported.
These skeletons are the only ones supported by the Bison team. Because the
interface between skeletons and the bison program is not finished, *we are
not bound to it*. In particular, Bison is not mature enough for us to
consider that "foreign skeletons" are supported.
* m4sugar
This directory contains M4sugar, sort of an extended library for M4,
which is used by Bison to instantiate the skeletons.
## m4sugar
This directory contains M4sugar, sort of an extended library for M4, which
is used by Bison to instantiate the skeletons.
* xslt
This directory contains XSLT programs that transform Bison's XML output
into various formats.
## xslt
This directory contains XSLT programs that transform Bison's XML output into
various formats.
- bison.xsl
A library of routines used by the other XSLT programs.
@@ -48,13 +48,132 @@ into various formats.
- xml2xhtml.xsl
Conversion into XHTML.
# Implementation note about the skeletons
"Skeleton" in Bison parlance means "backend": a skeleton is fed by the bison
executable with LR tables, facts about the symbols, etc. and they generate
the output (say parser.cc, parser.hh, location.hh, etc.). They are only in
charge of generating the parser and its auxiliary files, they do not
generate the XML output, the parser.output reports, nor the graphical
rendering.
The bits of information passing from bison to the backend is named
"muscles". Muscles are passed to M4 via its standard input: it's a set of
m4 definitions. To see them, use `--trace=muscles`.
Except for muscles, whose names are generated by bison, the skeletons have
no constraint at all on the macro names: there is no technical/theoretical
limitation, as long as you generate the output, you can do what you want.
However, of course, that would be a bad idea if, say, the C and C++
skeletons used different approaches and had completely different
implementations. That would be a maintenance nightmare.
Below, we document some of the macros that we use in several of the
skeletons. If you are to write a new skeleton, please, implement them for
your language. Overall, be sure to follow the same patterns as the existing
skeletons.
## Symbols
### `b4_symbol(NUM, FIELD)`
In order to unify the handling of the various aspects of symbols (tag, type
name, whether terminal, etc.), bison.exe defines one macro per (token,
field), where field can `has_id`, `id`, etc.: see
`prepare_symbols_definitions()` in `src/output.c`.
The macro `b4_symbol(NUM, FIELD)` gives access to the following FIELDS:
- `has_id`: 0 or 1.
Whether the symbol has an id.
- `id`: string
If has_id, the id (prefixed by api.token.prefix if defined), otherwise
defined as empty. Guaranteed to be usable as a C identifier.
- `tag`: string.
A representation of the symbol. Can be 'foo', 'foo.id', '"foo"' etc.
- `user_number`: integer
The external number as used by yylex. Can be ASCII code when a character,
some number chosen by bison, or some user number in the case of
%token FOO <NUM>. Corresponds to yychar in yacc.c.
- `is_token`: 0 or 1
Whether this is a terminal symbol.
- `number`: integer
The internal number (computed from the external number by yytranslate).
Corresponds to yytoken in yacc.c. This is the same number that serves as
key in b4_symbol(NUM, FIELD).
In bison, symbols are first assigned increasing numbers in order of
appearance (but tokens first, then nterms). After grammar reduction,
unused nterms are then renumbered to appear last (i.e., first tokens, then
used nterms and finally unused nterms). This final number NUM is the one
contained in this field, and it is the one used as key in `b4_symbol(NUM,
FIELD)`.
The code of the rule actions, however, is emitted before we know what
symbols are unused, so they use the original numbers. To avoid confusion,
they actually use "orig NUM" instead of just "NUM". bison also emits
definitions for `b4_symbol(orig NUM, number)` that map from original
numbers to the new ones. `b4_symbol` actually resolves `orig NUM` in the
other case, i.e., `b4_symbol(orig 42, tag)` would return the tag of the
symbols whose original number was 42.
- `has_type`: 0, 1
Whether has a semantic value.
- `type_tag`: string
When api.value.type=union, the generated name for the union member.
yytype_INT etc. for symbols that has_id, otherwise yytype_1 etc.
- `type`
If it has a semantic value, its type tag, or, if variant are used,
its type.
In the case of api.value.type=union, type is the real type (e.g. int).
- `has_printer`: 0, 1
- `printer`: string
- `printer_file`: string
- `printer_line`: integer
If the symbol has a printer, everything about it.
- `has_destructor`, `destructor`, `destructor_file`, `destructor_line`
Likewise.
### `b4_symbol_value(VAL, [SYMBOL-NUM], [TYPE-TAG])`
Expansion of $$, $1, $<TYPE-TAG>3, etc.
The semantic value from a given VAL.
- `VAL`: some semantic value storage (typically a union). e.g., `yylval`
- `SYMBOL-NUM`: the symbol number from which we extract the type tag.
- `TYPE-TAG`, the user forced the `<TYPE-TAG>`.
The result can be used safely, it is put in parens to avoid nasty precedence
issues.
### `b4_lhs_value(SYMBOL-NUM, [TYPE])`
Expansion of `$$` or `$<TYPE>$`, for symbol `SYMBOL-NUM`.
### `b4_rhs_data(RULE-LENGTH, POS)`
The data corresponding to the symbol `#POS`, where the current rule has
`RULE-LENGTH` symbols on RHS.
### `b4_rhs_value(RULE-LENGTH, POS, SYMBOL-NUM, [TYPE])`
Expansion of `$<TYPE>POS`, where the current rule has `RULE-LENGTH` symbols
on RHS.
-----
Local Variables:
mode: outline
mode: markdown
fill-column: 76
ispell-dictionary: "american"
End:
Copyright (C) 2002, 2008-2015, 2018 Free Software Foundation, Inc.
Copyright (C) 2002, 2008-2015, 2018-2019 Free Software Foundation, Inc.
This file is part of GNU Bison.

View File

@@ -3,7 +3,7 @@
<!--
bison.xsl - common templates for Bison XSLT.
Copyright (C) 2007-2015, 2018 Free Software Foundation, Inc.
Copyright (C) 2007-2015, 2018-2019 Free Software Foundation, Inc.
This file is part of Bison, the GNU Compiler Compiler.

View File

@@ -3,7 +3,7 @@
<!--
xml2dot.xsl - transform Bison XML Report into DOT.
Copyright (C) 2007-2015, 2018 Free Software Foundation, Inc.
Copyright (C) 2007-2015, 2018-2019 Free Software Foundation, Inc.
This file is part of Bison, the GNU Compiler Compiler.

View File

@@ -3,7 +3,7 @@
<!--
xml2text.xsl - transform Bison XML Report into plain text.
Copyright (C) 2007-2015, 2018 Free Software Foundation, Inc.
Copyright (C) 2007-2015, 2018-2019 Free Software Foundation, Inc.
This file is part of Bison, the GNU Compiler Compiler.

View File

@@ -3,7 +3,7 @@
<!--
xml2html.xsl - transform Bison XML Report into XHTML.
Copyright (C) 2007-2015, 2018 Free Software Foundation, Inc.
Copyright (C) 2007-2015, 2018-2019 Free Software Foundation, Inc.
This file is part of Bison, the GNU Compiler Compiler.

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff