* Split apart UnrecognizedEOF error variant from UnrecognizedToken
* Factor out fmt_expected function
* Initial attempt at fixing codegen
- Match on lookahead when returning error
- Use last fixed symbol as location of UnrecognizedEOF
- Use `Default::default()` when there are no fixed symbols (?)
* Initial implementation of finding latest optional location
* Fix UnrecognizedToken errors in `Some` test cases
* Fix UnrecognizedEOF test cases
* Fix parentheses around pattern error for 1.26 compatibility
* Add basic test for UnrecognizedEOF (and hopefully trigger Travis build)
* Fix emitted indentation and use travis_wait when testing
On Rust 1.33, the current generated code emits a warning because hidden lifetime parameters in types are deprecated. This occurs in the `impl Display for Token`, and happens because `fmt::Formatter` has a lifetime parameter.
This PR adds an explicit lifetime parameter `'f` to the generated code, so it will work on all supported versions of Rust.
In gluon's parser I have a lalrpop symbol type that ends up at 400Kb
which is expensive to copy around. By moving the `push` call into each
reduction instead we make it easier for LLVM to elide memcpys and I
observed a reduction in memcpy uses from 27% to 18% of of the total
parse time.
Cargo allows build scripts to emit directives to specify their
dependencies, so that modifying other files does not cause them to be
rerun. This adds a configuration option to emit those directives,
defaulting to false to avoid interfering with other parts of the build
script and leading to hard-to-debug issues.
On Windows, some files cannot be represented in the UTF-8 used by Cargo,
and a build warning is emitted instead.
I've tested this change manually, but didn't see an easy way to test
it programmatically as part of the codebase, especially because
`to_string_lossy()` can never return `None` on Unix platforms.
Instead we use --all-features to enable a special `test` feature to run tests with a freshly generated lrgrammar.rs. Since we also have a test to check that the saved lrgrammar.rs is identical to what lalrpop generates we should be ok with this approach.
Closes#436
