|
|
|
/* global peg */
|
|
|
|
|
|
|
|
"use strict";
|
|
|
|
|
|
|
|
describe("compiler pass |removeProxyRules|", function() {
|
|
|
|
var pass = peg.compiler.passes.transform.removeProxyRules;
|
|
|
|
|
|
|
|
describe("when a proxy rule isn't listed in |allowedStartRules|", function() {
|
|
|
|
it("updates references and removes it", function() {
|
|
|
|
expect(pass).toChangeAST(
|
|
|
|
[
|
|
|
|
'start = proxy',
|
|
|
|
'proxy = proxied',
|
|
|
|
'proxied = "a"'
|
|
|
|
].join("\n"),
|
|
|
|
{
|
|
|
|
rules: [
|
|
|
|
{
|
|
|
|
name: "start",
|
|
|
|
expression: { type: "rule_ref", name: "proxied" }
|
|
|
|
},
|
|
|
|
{ name: "proxied" }
|
|
|
|
]
|
Regularize Jasmine custom matcher signatures
The "toParse" matcher in generated-parser-behavior.spec.js effectively
had these signatures:
toParse(input)
toParse(input, expected)
toParse(input, options, expected)
This commit regularizes them to:
toParse(input)
toParse(input, expected)
toParse(input, expected, options)
Similarly, the "toFailToParse" matcher in
generated-parser-behavior.spec.js effectively had these signatures:
toFailToParse(input)
toFailToParse(input, details)
toFailToParse(input, options, details)
This commit regularizes them to:
toFailToParse(input)
toFailToParse(input, details)
toFailToParse(input, details, options)
Finally, the "toChangeAST" matcher in helpers.js effectively had these
signatures:
toChangeAST(grammar, details)
toChangeAST(grammar, options, details)
This commit regularizes them to:
toChangeAST(grammar, details)
toChangeAST(grammar, details, options)
The overall purpose of these changes is to avoid different parameters
appearing at the same position, which is hard to manage without using
"arguments".
9 years ago
|
|
|
},
|
|
|
|
{ allowedStartRules: ["start"] }
|
|
|
|
);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
describe("when a proxy rule is listed in |allowedStartRules|", function() {
|
|
|
|
it("updates references but doesn't remove it", function() {
|
|
|
|
expect(pass).toChangeAST(
|
|
|
|
[
|
|
|
|
'start = proxy',
|
|
|
|
'proxy = proxied',
|
|
|
|
'proxied = "a"'
|
|
|
|
].join("\n"),
|
|
|
|
{
|
|
|
|
rules: [
|
|
|
|
{
|
|
|
|
name: "start",
|
|
|
|
expression: { type: "rule_ref", name: "proxied" }
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "proxy",
|
|
|
|
expression: { type: "rule_ref", name: "proxied" }
|
|
|
|
},
|
|
|
|
{ name: "proxied" }
|
|
|
|
]
|
Regularize Jasmine custom matcher signatures
The "toParse" matcher in generated-parser-behavior.spec.js effectively
had these signatures:
toParse(input)
toParse(input, expected)
toParse(input, options, expected)
This commit regularizes them to:
toParse(input)
toParse(input, expected)
toParse(input, expected, options)
Similarly, the "toFailToParse" matcher in
generated-parser-behavior.spec.js effectively had these signatures:
toFailToParse(input)
toFailToParse(input, details)
toFailToParse(input, options, details)
This commit regularizes them to:
toFailToParse(input)
toFailToParse(input, details)
toFailToParse(input, details, options)
Finally, the "toChangeAST" matcher in helpers.js effectively had these
signatures:
toChangeAST(grammar, details)
toChangeAST(grammar, options, details)
This commit regularizes them to:
toChangeAST(grammar, details)
toChangeAST(grammar, details, options)
The overall purpose of these changes is to avoid different parameters
appearing at the same position, which is hard to manage without using
"arguments".
9 years ago
|
|
|
},
|
|
|
|
{ allowedStartRules: ["start", "proxy"] }
|
|
|
|
);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
});
|