The documentation is now up-to-date with the new and more relaxed rules
that allow overapproximating the results. I have also attempted to make
a clearer distinction between the requirements of the specification and
the behaviour of the implementation.
It's better to join with the range expression first since that will only
multiply tuple counts by the number of lines in an average source/sink.
Joining with `restrictAlertsToStartLine` first would multiply tuple
counts by the number of sources/sinks in a given file.
Previously the Source tag was required if the source and alert did not
have the exact same location. This relaxes the restriction to being on
the same line.
Note that in order to be "on the same line" both start and end lines
have to match.
It's still possible for a given line to expect both Alert and Source
tags, in case the source pairs up with another alert on a different
line.
This commit introduces a new extensible predicate
restrictAlertsToExactLocation, which is similar to the existing
restrictAlertsTo predicate but matches alert locations exactly.
This commit rephrases the documentation for the restrictAlertsTo
predicate and renames the predicate columns for clarity. The new
documentation should be equivalent to the old documentation, except
allowing for the possibility that there may be multiple alert filtering
predicates.
This documentation-only commit clarifies that a query should either
ignore restrictAlertsTo completely or apply restrictAlertsTo filtering
to all alerts. This update eliminates the ambiguity on whether a query
may choose to apply restrictAlertsTo filtering to only some alerts but
not others (it may not).