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.
Edits: Slight tweaking, plus a simple test.
* 'topic/amazingpp/modifiable-const-via-loops' of ssh://github.com/AmazingPP/zeek:
Add help function to check loop variable
Fix local const variables can be modified via loops
An adequate error message was previously reported for duplicate enum
definitions, this just now prevents trying to access it as a constant in
subsequent parsing and further generating a coredump.
* origin/topic/jsiwek/type-alias-introspection:
Add enum_names() BIF to return names of an enum type's values
Add type_aliases() BIF for introspecting type-names of types/values
Change Type::type_aliases map to store IntrusivePtr
Fix lookup_ID() BIF to return enum values
For `|x|`, where `x` is an expression with an integral result, an
implicit coercion of that result into signed `int` type no longer takes
place.
This was actually the behavior before Zeek 3.0 as well, but the attempt
to prevent mistakes that easily result from integer literals in Zeek
being unsigned like `|5 - 9|` causing an overflow/wraparound and
yielding a very large number is not generally consistent since overflows
are still generally able to happen in other ways and also in other
contexts besides just absolute-values. So the preference was to revert
to a behavior that favors consistency. For reference, see
https://github.com/zeek/zeek/pull/251#issuecomment-713956976
