From 1649ec7cd75abff0b2d10951ac80b31ccc11a20d Mon Sep 17 00:00:00 2001 From: Rasmus Lerchedahl Petersen Date: Wed, 7 Sep 2022 12:18:42 +0200 Subject: [PATCH] Python: Describe current naming scheme In the hope that this will enable a better one. It looks like - type tracking should currently be mutually recursive with data flow (this needs investigation) - type tracking already supports special methods (we should probably have a test for this) --- .../new/internal/FlowSummaryImplSpecific.qll | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/python/ql/lib/semmle/python/dataflow/new/internal/FlowSummaryImplSpecific.qll b/python/ql/lib/semmle/python/dataflow/new/internal/FlowSummaryImplSpecific.qll index 10a42a466d6..3aa01a0a39e 100644 --- a/python/ql/lib/semmle/python/dataflow/new/internal/FlowSummaryImplSpecific.qll +++ b/python/ql/lib/semmle/python/dataflow/new/internal/FlowSummaryImplSpecific.qll @@ -1,5 +1,25 @@ /** * Provides Python specific classes and predicates for defining flow summaries. + * + * Flow summaries are defined for callables that are not extracted. + * Such callables go by different names in different parts of our codebase: + * + * - in `FlowSummary.qll`, which is user facing, they are called `SummarizedCallable`s. + * These contain summaries, implemented by the user via the predicates `propagatesFlow` and `propagatesFlowExt`. + * + * - in the data flow layer, they are called `LibraryCallable`s (as in the Ruby codebase). + * These are identified by strings and has predicates for finding calls to them. + * + * Having both extracted and non-extracted callables means that we now have three types of calls: + * - Extracted calls to extracted callables, either `NonLibraryNormalCall` or `SpecialCall`. These are handled by standard data flow. + * - Extracted calls to non-extracted callables, `LibraryCall`. These are handled by summaries. + * - Non-extracted calls, `SummaryCall`. These are synthesised by the flow summary framework. + * + * The first two can be referred to as `DataFlowSourceCall`. They have been split up for the benefit of call resolutiuon. + * Resolving a call to a non-extracted callable goes via `LibraryCallable::getACall`, which may involve type tracking. + * To avoid that type tracking becomes mutualy recursive with data flow, type tracking must use a call graph not including summaries. + * + * We do not support summaries of special methods. */ private import python