[greetingsuniverse]

compiling function constraints has not been tested (function constraints are not implemented in ndnd yet)

[tianyuan129]

I used LLM to produce rules and it reported the the code behaves differently than python-ndn in the following cases. Can you verify?

1. A misspelled constraint silently removes the restriction

#key: "key"
#data: a & { typo: "allowed" } <= #key

python-ndn: rejects compilation: Pattern typo never occurs before.
Go: compiles; Check("/forbidden", "/key") returns true.

2. A function constraint changes the compiled model

#key: "key"
#data: a/b & { b: $eq(a) } <= #key

Result	python-ndn	Go PR
Compiles	Yes	Yes
$eq argument tag	1, referring to a	0, incorrect
Allowed signer for #data	#key	Signer constraint disappears
Check /x/x under /key	true with DEFAULT_USER_FNS	Panics: functions unsupported
Check /x/y under /key	false	Panics

3. A signing cycle passes Go’s model validation

#a: "a" <= #b
#b: "b" <= #a

python-ndn: constructing Checker rejects the signing cycle.
Go: NewLvsSchema accepts it; Check("/a", "/b") returns true.

5. A trailing comment breaks Go parsing

#key: "key"
#data: "data" <= #key // comment

python-ndn: compiles; check("/data", "/key") returns true.
Go: compilation panics with Expected NEWLINE, got EOF.

[greetingsuniverse]

I fixed 1 4 and 5

2. and 3. are in the LvsSchema class

to fix 2 (adding function constraint support) would break existing implementations that use it because of adding user functions list as an argument, or I can just add a separate function such as NewLvsSchemaFns that does the same thing but accepts user functions list also

3 is caused by the python-ndn checker sanity check which constructs the tree and traverses to detect this loop, ndnd doesn't but I'm not sure if allowing this behavior is really a big issue (the python-ndn compiler even allows it to compile)

[tianyuan129]

I still found two small issues. For the schema below

#base: "site"
#_: #base/"data"
#r: "bogus=foo"

Syntax wise,#_ should have been allowed, while #r should have been rejected for its invalid content (currently the code seem to ignore the parsing errors).

We are almost there. In this round most generated edge cases are really minor compatibility cases that we can rarely see in practice.