* origin/topic/vern/emphasize-IDPtrs:
fixup! fixup! shift much of the internal use of ID* identifier pointers over to IDPtr objects
fixup! shift much of the internal use of ID* identifier pointers over to IDPtr objects
fixup! shift much of the internal use of ID* identifier pointers over to IDPtr objects
fixup! shift much of the internal use of ID* identifier pointers over to IDPtr objects
annotate a number of BTests as unsuited for -O gen-C++ testing due to multiple Zeek runs
BTest baseline updates for -O gen-C++ - all minor tweaks
BTest updates for script optimization tracking of BiFs
regression test for former ASAN issue with script optimization of lambdas
shift much of the internal use of ID* identifier pointers over to IDPtr objects
maintenance update for script optimization's knowledge of BiFs
logger fix for interoperability with -O gen-C++ code
Parameters relied on is_record for a couple of validations, but they are
not records and should not be treated as such. This way we can validate
&optional better.
Closes#4173
This allows types to be used in expressions, but they can't be
reassigned. Note that this was meant to be a special "type expression" -
but that is unnecessary complexity.
Type expressions would allow access to the type without going through
its constant value, but the constant value is never changed, so it's
simply a few more checks if necessary when functionality gets expanded.
This way, ZAM and other code will not need updates, so the potential for
increased work in the future is probably not worth caring about.
When Spicy defines an event through EVT, it would end up with
more-or-less random, stale Zeek-side location information. Now making
sure it's unset, plus then using any script-side prototype we may
encounter later to update it.
Also fixing a couple location comparisons that I believe were broken
because we do sometimes copy location objects and hence can't compare
by pointer.
This is based on the discussion in zeek/zeek#2668. Using &default with tables
can be confusing as the default value is not inserted. The following example
prints an empty table at the end even new Service records was instantiated.
type Service: record {
occurrences: count &default=0;
last_seen: time &default=network_time();
};
global services: table[string] of Service &default=Service();
event zeek_init()
{
services["http"]$occurrences += 1;
services["http"]$last_seen = network_time();
print services;
}
Changing above &default to &default_insert will insert the newly created
default value upon a missed lookup and act less surprising.
Other examples that caused confusion previously revolved around table of sets
or table of vectors and `add` or `+=` not working as expected.
tbl_of_vector["http"] += 1
add tbl_of_set["http"][1];
Ad-hoc include module names in the global_ids() table. Table values will
have the type_name field set to "module" and their key in the table is
prefixed with "module " to avoid clashes with existing global identifiers
shadowing module names (Management::Node being an existing example).
Closes#3136
Removes a bit of reliance around the magic DoLog() rendering at the
cost of needing to open-code some of it. The new obj_desc_short()
helper makes that acceptable, though.
This was marked to be done in Zeek 5.1, so do it now. The message
didn't include a version, unfortunately, but minimally there was
a comment when it should happen.
It's happening regularly to me that I forget the type specifier when redef'ing
records or enums and usually it takes me a while to figure out what's going
on as the errors are not descriptive. Improve the error reporting and just
bail as there's no sensible way to continue.
Closes#2777
Python, Ruby, Javascript, Go, ..., allow use of trailing commas and is even
recommended in some style-guides as it keeps diffs smaller. The black formatter
for Python even goes as far to take a trailing comma as an indication to
format a list one-item on a line.
It has been a bit unusual to not be able to put trailing commas in Zeek
scripts, so this change allows for it.
It explicitly prevents trailing commas in list expressions on the left
hand side. Concretely, this disallows trailing commas in the key list
expression during table initializations.
It probably allows for commas in more places that I haven't fully grasped.
Maybe we should tighten those down again if we find them surprising.
Seemed easiest to do it via the traversal infrastructure as we do not
otherwise track enough context/scope when instantiating break or next
statements.
Might be worth moving this out of src/parse.y, but didn't exactly know
where. Or maybe we wait until there's more such trivial validations
popping up
Fixes#2440
This started with reverting commit 52cd02173d
and then rewriting it to be per handler rather than handler identifier
and adding support for hooks as well as adding implicit module groups.
Mostly: Do not instantiate variables within for loops and allow
reusing differently typed blanks which previously wasn't possible.
This may be missing some corner-cases, but the added tests seem
to work as expected and nothing else fell apart it seems.
Avoid the issue outlined in #2289 where the @if or @else is taken as the
statement of an `if`, `for` or `while` by rejecting such constructs.
Effectively this means the following scripts are now rejected:
# Print's "cond true" with Zeek 5.0 even though the `if ( F )`
# should be in effect.
if ( F )
@if ( T )
print "cond true";
@else
print "cond false";
@endif
or
# Print's "hello" once with Zeek 5.0
local v = vector( 1, 2, 3 );
for ( i in v )
@if ( T )
print("hello")
@endif
To make above work as intended, additional braces can be used.
if ( T )
{
@if ( cond )
print "cond true";
@else
print "cond false";
@endif
}
for ( i in v )
{
@if ( T )
print("hello")
@endif
}
The change to the capture-loss test is actually a fix for a bug exposed by the
code change. Previously it wasn't firing the scheduled event because of a failed
name lookup. Now that the lookup has been fixed, the event happens twice.
Add new syntax for adding and removing attributes from record fields:
redef RecordType$field_name += { &log };
redef RecordType$field_name -= { &log };
For now this only allowed for the &log attribute as the semantics are clear.
For &default and &optional the semantics aren't obvious and no use-cases have
been identified where those would make sense to change.
This enables a mechanism to add potentially interesting fields to the typical
Info records in base scripts, but letting users opt-into actually including
them into their log. At the same time, users that find specific fields in a
standard log uninteresting can opt-out without using `Log::Filter$exclude`
which can be difficult to use correctly. Patching or forking external packages
to remove columns from a log can also be avoided with this mechanism.
Closes#2000.
