spicy
spicy copied to clipboard
Field hooks suppress useful errors about unknown IDs
Forgot to use a ASN1::
prefix for a field with a hook and it took a bit to figure out the problem...
The crux is that when a "field hook" exists, the following useful/actionable error message:
[error] test.spicy:8:3: unknown ID 'ASN1Messup'
[error] spicy-driver: aborting after errors
instead turns into the following (trying to access the field):
$ echo "X" | spicy-driver test.spicy
[error] test.spicy:9:11: type does not have field 'm'
[error] spicy-driver: aborting after errors
$ cat test.spicy
module Test;
type ASN1Message = unit(x: bool) {
tag: uint8;
};
public type X = unit() {
m: ASN1Messup(True) {
print self.m;
}
};
In this case it's still pretty easy to spot. With the LDAP analyzer, it triggered a bunch of more confusing diagnostics.
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:614:30: unsupported operator: <const LDAP::SearchFilter>.<FILTER_SUBSTR>
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:615:39: unsupported operator: <const LDAP::SearchFilter>.<FILTER_SUBSTR>
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:684:31: type does not have field 'substring_header'
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:687:48: type does not have field 'substring_header'
[error] zeek/src/analyzer/protocol/ldap/ldap.spicy:727:35-728:80: not a parseable type (auto)
This looks like another facet of #1316.