Java: Avoid higher-numbered dataflow configs that depend on lower-numbered ones #8748
Conversation
…numbered ones Since usually we have DataFlow3::Configurations that stand alone, DataFlow2::Configurations that depend on them, and finally DataFlow::Configurations that produce a top-level query result (for example), qll files where the reverse pattern holds will usually not be concurrently importable due to dataflow configuration recursion prevention.
Is this documented somewhere or would it make sense to document this somewhere? (I did not know this pattern before) |
It's not documented, and we don't intend to, as it will hopefully soon be a thing of the past. |
|
Ignored qldoc complaints since they (a) are shared with existing TaintTracking instances and (b) don't really matter, being requests for a file-level doc block in a file that declares one, documented, entity. |
While trying to enumerate sinks as perceived by various queries, #8742 noticed that some of our qll files that define sinks can't be imported concurrently. This turned out to be because some QLLs defy the usual pattern that lower-numbered dataflow configs are defined in terms of higher ones, not the reverse. By flipping the dataflow instance numbers here, it becomes possible to import all of the
java/ql/lib/semmle/code/java/securitydirectory concurrently.