Forward declarations of events don't work inside a module namespace

[jsiwek]

Moved from https://bro-tracker.atlassian.net/browse/BIT-71

Created by Robin Sommer at 2009-02-20T13:43:57.000-0600:

Forward declarations of events aren't correctly resolved when used inside a module namespace. The worst thing about this is that they fail silently: there's no error message, the handler is just not executed.

The example below never prints anything. Once the module statement is removed, everything works fine though.

module Foo;

global bar: event();

event bar()
    {
    print "bar";
    }

event new_connection(c: connection)
    {
    event bar();
    }

Comment by Jon Siwek at 2015-03-16T14:38:28.976-0500:

Other examples of the problem referenced in BIT-984.

Comment by Robin Sommer at 2016-07-08T18:46:57.988-0500:

I don't see an easy fix for this. Unfortunately event IDs are handled somewhat differently than other IDs, but the global prototype cannot adjust to that because the parser doesn't know that it's an event before it's too late.

Closing, as there's a work-around by using fully scoped event names (see BIT-984).

[jsiwek]

Other pitfall examples which are sort of the reverse problem from original:

http://mailman.icsi.berkeley.edu/pipermail/bro-dev/2018-September/013057.html

So assuming the main source of confusion is that event declarations implicitly add module prefixes to names, an idea would be to try to make event handler names also implicitly add module prefixes when they are not ambiguous with a name already in the global namespace. The name resolution process for things like event calling sites may also need adjusting -- e.g. if no ambiguous event declaration in the global namespace, then instead raise an event prefixed by current module name.

[timwoj]

At least we're now getting a warning for the test case in the first post, thanks to Vern's recent work:

warning in ./test.zeek, line 3: handler for non-existing event cannot be invoked (Foo::bar)

[vpax]

Good to hear, as that was in fact exactly the use case (which I ran across in a different context) that made me think "geez we need to find these"!