Code detection method, apparatus, device, medium, and product

Abstract

This invention discloses a code detection method, apparatus, device, medium, and product. The method includes: identifying at least one asynchronous function in the code to be detected; identifying at least one call statement from the code to be detected that calls the asynchronous function without using a preset asynchronous call operator; performing contextual semantic analysis on the call statement to be verified to determine its execution type; and performing compliance detection on the call statement to be verified based on its execution type to obtain a detection result. The technical solution provided by this invention improves the accuracy and robustness of asynchronous code detection, avoids misjudging legitimate programming patterns as violations, ensures code quality, reduces false positives for developers, and improves development efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer processing, and in particular to a code detection method, device, equipment, medium and product. BACKGROUND

[0002] Asynchronous programming often relies on coroutine mechanism. When an asynchronous function is called, if a keyword is not used, only a coroutine object is returned without executing the function body. Such omission of keywords may cause logic not to be executed or a program to be wrong, so compliance detection needs to be performed on asynchronous calls.

[0003] The existing detection method mainly checks whether an asynchronous function call lacks a keyword through a rule. However, this method often misjudges compliant usage as a violation, resulting in false positives. SUMMARY

[0004] The present application provides a code detection method, device, equipment, medium and product to avoid misjudging a compliant asynchronous programming mode as a violation, improve the accuracy and robustness of asynchronous code detection, guarantee code quality, reduce development false positive interference, and improve development efficiency.

[0005] According to an aspect of the present application, a code detection method is provided, which includes: determining at least one asynchronous function in to-be-detected code; identifying, from the to-be-detected code, at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls the asynchronous function; performing context semantic analysis on the to-be-verified calling statement to determine an execution type of the to-be-verified calling statement; the execution type includes at least one of a reuse variable type, a return variable type, a loop variable collection type, and a task collection type; performing compliance detection on the to-be-verified calling statement according to the execution type to obtain a detection result.

[0006] According to another aspect of the present application, a code detection device is provided, which includes: an asynchronous function determination module configured to determine at least one asynchronous function in to-be-detected code; a to-be-verified calling statement determination module configured to identify, from the to-be-detected code, at least one to-be-verified calling statement that uses a preset asynchronous calling operator and calls the asynchronous function; an execution type determination module configured to perform context semantic analysis on the to-be-verified calling statement to determine an execution type of the to- be-verified calling statement; the execution type includes at least one of a reuse variable type, a loop variable collection type, and a task collection type; A detection result determination module is configured to perform compliance detection on the to-be-verified calling statement according to the execution type, and obtain a detection result.

[0007] According to another aspect of the present application, there is provided an electronic device comprising: at least one processor; and a memory connected to the at least one processor in communication; wherein The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the code detection method according to any one of the embodiments of the present application.

[0008] According to another aspect of the present application, there is provided a computer readable storage medium storing computer instructions for enabling a processor to perform the code detection method according to any one of the embodiments of the present application when executed by the processor.

[0009] According to another aspect of the present application, there is provided a computer program product comprising a computer program for implementing the code detection method according to any one of the embodiments of the present application when executed by a processor.

[0010] The technical solution of the embodiments of the present application determines at least one asynchronous function in the to-be-detected code, identifies at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls an asynchronous function from the to-be-detected code, performs context semantic analysis on the to-be-verified calling statement to determine the execution type of the to-be-verified calling statement, and performs compliance detection on the to-be-verified calling statement according to the execution type to obtain a detection result, thereby solving the problem in the prior art that a legal programming mode is misjudged as a violation by checking whether an asynchronous function call is missing a keyword, resulting in false positives, and achieving the following: after at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls an asynchronous function is identified from the to-be-detected code, the to-be-verified calling statement is further subjected to multi-dimensional analysis of context semantics to accurately determine the execution type (such as a reuse variable type, a return variable type, a loop variable collection type, or a task collection type), so that whether the calling is compliant is determined in combination with the specific execution type, the accuracy and robustness of asynchronous code detection are improved, a legal programming mode is avoided from being misjudged as a violation, the code quality is guaranteed, the false positives of the developer are reduced, and the development efficiency is improved.

[0011] It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of the present application, nor is it used to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to make the technical solution in the embodiments of the present application clearer, the accompanying drawings needed in the embodiments description will be briefly introduced. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0013] Figure 1 is a flow chart of a code detection method according to an embodiment of the present application; Figure 2 is a flow chart of a code detection method according to an embodiment of the present application; Figure 3 is a structural schematic diagram of a code detection device according to an embodiment of the present application; Figure 4 is a structural schematic diagram of an electronic device implementing the code detection method according to an embodiment of the present application. DETAILED DESCRIPTION

[0014] In order to make the technical solution in the embodiments of the present application clearer, the accompanying drawings needed in the embodiments description will be briefly introduced. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0015] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned accompanying drawings are used to distinguish similar objects, and do not necessarily mean a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0016] It should be noted that in the technical solutions of the present disclosure, the collection, collection, updating, analysis, processing, use, transmission, storage and the like of user personal information comply with relevant laws and regulations, are used for legal purposes, and do not violate public order and good customs. Necessary measures are taken for user personal information to prevent illegal access to user personal information data and maintain user personal information security and network security. It should also be noted that in the technical solutions of the present disclosure, the collection, collection, updating, analysis, processing, use, transmission, storage and the like of user personal information are carried out with the knowledge and permission of the user, in compliance with relevant privacy protection regulations.

[0017] Before introducing the technical solutions, the application scenarios can be explained first. The technical solutions provided in this embodiment can be applied to various scenarios that need to detect the compliance or rationality of asynchronous programming code.

[0018] For example, when developing a high-concurrency network service (such as a web server, a microservice interface, or a real-time communication system), developers usually use an asynchronous programming model (such as an async / await, Promise, or coroutine-based mechanism) for coding to improve the throughput and response performance of the system. After coding, in order to ensure the correctness and stability of the code, it is necessary to detect whether the calling manner of the asynchronous function complies with the preset specification. At this time, based on the technical solutions provided in this embodiment, the asynchronous calling logic in a single code file or the entire project can be statically or dynamically analyzed to identify potential compliance problems, such as not waiting for asynchronous results, incorrectly calling asynchronous functions in a synchronous context, or violating asynchronous calling chain constraints.

[0019] In a complex business system, asynchronous logic is often scattered in multiple modules or across multiple source code files (for example, in scenarios such as front-end and back-end collaborative development, plug-in architecture, or layered service design). When compliance review needs to be carried out before system integration to ensure that asynchronous function calls across files meet uniform programming specifications and safety policies, the technical solutions provided in this embodiment can also be used to track asynchronous calling relationships across files and modules and verify compliance.

[0020] Figure 1 is a flowchart of a code detection method according to an embodiment of the present disclosure. The embodiment can be applied to any situation involving asynchronous programming and code specification detection. The method can be executed by a code detection device, which can be implemented in the form of hardware and / or software, and can be configured in a computing device. As shown in Figure 1 The method comprises: S110, determining at least one asynchronous function in the code to be detected.

[0021] The to-be-detected code refers to source code that needs to be analyzed for compliance or statically checked. It can be a program fragment, module, or complete project written by a developer using a programming language that supports the asynchronous programming paradigm, such as Python, JavaScript, C#, TypeScript, etc. It can contain function definitions, variable declarations, assignment operations, and function calls, etc. Asynchronous functions are functions that are explicitly declared to be executed asynchronously. For example, asynchronous functions can be defined using specific keywords such as async, and their calls will not block the main thread, and may return an object representing the future result (such as coroutines, promises, tasks, etc.). For example, asynchronous functions can be coroutine functions defined in Python using the async def syntax; they can also be functions declared in JavaScript / TypeScript using the async function or arrow function with the async modifier; they can also be functions in C# modified with the async keyword and returning Task or Task <t>TypeScript, JavaScript, and C#) are all asynchronous functions. These asynchronous functions have the common characteristics of non-blocking execution and the need to be used in conjunction with the corresponding asynchronous calling mechanism (such as await).

[0022] It should be noted that each code to be detected can be a complete code file, or a part of code segment in the code file, or a plurality of associated code files. The technical solution provided in the embodiment supports unified cross-file compliance detection on a plurality of code files, and the detection logic for each code file is basically consistent. For ease of description, the overall detection process of the code to be detected (whether it is a single file, a file segment, or a multi-file set) is taken as an example for introduction.

[0023] In the embodiment, the code to be detected can be subjected to abstract syntax tree (AST) construction according to the lexical and syntactic specifications of the target programming language corresponding to the code to be detected, and then each node in the abstract syntax tree is traversed to find nodes that conform to the asynchronous function syntax or have the asynchronous function declaration feature. These nodes correspond to asynchronous functions. For example, asynchronous functions can be used in at least one of the following situations: used for concurrently requesting multiple remote APIs to efficiently obtain user data; used for non-blockedly processing a large number of client connections in a web server to improve throughput; used for asynchronously reading and writing a database or a file system to avoid I / O operation blocking the main thread; used for continuously listening to and responding to message events in a real-time communication system while maintaining the execution of other tasks; used for coordinating the calling of multiple downstream services and aggregating the results to return uniformly in a micro-service architecture; and can also be used for asynchronously loading components or resources in a front-end application to achieve smooth user experience.

[0024] In order to accurately identify all functions with asynchronous behavior in the code to be detected, thereby ensuring the reliability and comprehensiveness of subsequent asynchronous calling compliance analysis, the function defined in the code to be detected by the preset asynchronous definition identifier can be determined as an asynchronous function in the process of determining at least one asynchronous function in the code to be detected.

[0025] The preset asynchronous definition identifier refers to a keyword, modifier, or syntax marker that is explicitly defined in a programming language by language specifications or development conventions to explicitly declare that a function has asynchronous behavior. For example, in Python, the preset asynchronous definition identifier is the async keyword or the async def keyword.

[0026] In the embodiment, complete lexical analysis and syntax parsing can be performed on the code to be detected, an abstract syntax tree (AST) is constructed, and function definition nodes therein are traversed to check whether the declaration part contains a preset asynchronous definition identifier; if so, the function node is marked as an asynchronous function. A lightweight method can also be used to scan the text content of the code to be detected line by line, and a preset text pattern (such as matching async function, async def, and other fixed syntax combinations) is used to identify possible asynchronous function declarations. In addition, a semantic analysis interface provided by the language (such as the AST module or analyzer of Python) can be called to obtain the semantic attributes of the function declaration in the code to be detected, and it is determined whether the function declaration carries the preset asynchronous definition identifier; if so, the function is determined to be an asynchronous function.

[0027] For example, if the function definition in the code to be detected has an async def header (i.e., contains the preset asynchronous definition identifier of the async keyword), it is determined to be an asynchronous function; if the function is declared as async function or appears as an async arrow function, it is also determined to be an asynchronous function. It should be noted that the preset asynchronous definition identifier can be different for different versions or different programming languages, and should be determined according to the programming language and its version used by the code to be detected.

[0028] The technical solution provided in the embodiment determines the asynchronous function by identifying whether the preset asynchronous definition identifier is used in the code to be detected, and directly determines the function defined by the identifier as an asynchronous function, so that all declared asynchronous functions in the code can be efficiently, accurately and unambiguously captured.

[0029] It should be noted that in code development, a code module often references an asynchronous function defined in another code module, and an import statement (such as import) is used in the code at this time. That is, the code to be detected can also include at least one import statement.

[0030] In order to ensure the completeness and accuracy of the asynchronous function recognition, and to avoid missing external asynchronous behaviors due to only analyzing the local definitions of the current module, when the function defined by the preset asynchronous definition identifier in the code to be detected is determined to be an asynchronous function, the external module referenced by the import statement should also be parsed; the function type of the function corresponding to the function name imported in the import statement in the external module is determined; if the function type is asynchronous, the function referenced by the function name in the current module is determined to be an asynchronous function.

[0031] The import statement refers to a syntax structure in the code to be detected for introducing functions, classes or variables defined in other source code modules. For example, the import or from... import... syntax in Python is used as an import statement; the import... from... syntax in JavaScript / TypeScript is used as an import statement. The external module refers to the other source code module referenced by the import statement and different from the current module of the code to be detected, i.e., the external module is a source code module different from the current module of the import statement in the code to be detected; the external module and the current module are code units located in different files or namespaces. The function name refers to an identifier explicitly specified or introduced by an alias in the import statement, which is used to refer to a function defined in the external module in the current module. The function type refers to the category attribute of the function at the language type system or semantic level, which includes the asynchronous type; the asynchronous type refers to the function having an asynchronous behavior feature, such as being declared by a preset asynchronous definition mark or having a return value of a waitable object (such as Promise, Task, coroutine, etc.).

[0032] In this embodiment, the code to be detected can be syntax analyzed to extract all or part of the import statements and the function names introduced thereby. According to the module parsing rules of the language (such as file path, package structure, export declaration, etc.), the corresponding external module source code is located and loaded; if the function corresponding to the function name is declared as an asynchronous function in the external module, or its return type indicates that it has an asynchronous behavior, i.e., the function type is asynchronous, then the function referred to by the function name in the current module is also determined as an asynchronous function.

[0033] For example, assuming that the code to be detected is a T file code containing an import statement from B import C, the import statement and the function name C introduced thereby are extracted; according to the module parsing, the external module D.py is located and loaded, and it is found that async def C (url: str) -> dict:... is defined therein, i.e., the function is declared using the async keyword and returns a dictionary (actually a coroutine object), which belongs to the asynchronous type. Although C is not defined in the T file code, the function referred to by the function name C is still determined as an asynchronous function, so that the compliance check (such as whether await is omitted) of the subsequent C (...) call can accurately cover this cross-module reference scenario.

[0034] In addition, the external module can also be attached with a structured type description file. The type description file can be directly read to obtain the signature and return type information of the imported function, and then determine whether it belongs to the asynchronous type (for example, the return value Promise <t>(Or it may be annotated with async semantics). The advantage of this setting is that it eliminates the need to parse the complete implementation source code of external modules. It relies on the function type recorded for each asynchronous function to determine whether the function referenced by the function name is an asynchronous function, thus improving identification efficiency.

[0035] Furthermore, a dependency graph of all asynchronous functions in the code to be tested can be pre-built, establishing function call relationships and dependencies based on import statements. The dependency graph can be used to quickly locate the function types of external modules and the functions corresponding to the imported function names in those external modules, using these function types as the function types of the functions referenced by the function names in the current module.

[0036] The technical solution provided in this embodiment can accurately identify asynchronous functions used indirectly through references in the current module by parsing import statements and tracing the function types of corresponding functions in external modules. This enables unified identification of asynchronous functions across modules, effectively avoiding the risk of missing cross-module asynchronous calls due to analyzing only local definitions, and improving the comprehensiveness, completeness, and accuracy of asynchronous call compliance detection.

[0037] S120. Identify at least one call statement from the code to be tested that does not use the preset asynchronous call operator and calls an asynchronous function.

[0038] The default asynchronous call operator refers to a syntax element in a programming language used to explicitly handle the results of asynchronous function calls. For example, it's `await` in JavaScript and TypeScript, `await` in Python (requires a coroutine context), and `await` in C# (requires the `async` method). The default asynchronous call operator pauses the current execution flow, waits for the asynchronous operation to complete, and then retrieves its result. The statement to be verified refers to a statement in the code to be tested that calls an asynchronous function, and this statement needs to undergo compliance checks to verify whether it correctly uses the default asynchronous call operator.

[0039] In this embodiment, after constructing the abstract syntax tree of the code to be tested, all function call nodes are traversed. For each call node, symbol resolution is used to determine whether the function it calls is a known asynchronous function (including locally defined or imported asynchronous functions). Then, it is checked whether the call node is within the scope of a preset asynchronous call operator (such as await). If the call target is an asynchronous function, but the call statement is not modified by await, then the call statement is marked as a call statement to be verified.

[0040] In addition, the return type of each function call can also be obtained through type deduction; if the return type is an asynchronous type, but the call expression is not wrapped by the preset asynchronous call operator, it can be inferred that the call statement has the risk of non-compliant use of asynchronous functions, thereby identifying it as a to-be-verified call statement.

[0041] For example, the target function called by a certain function call statement has been determined to be an asynchronous function, but the call statement does not use the corresponding await operator in syntax, which may constitute non-compliant behaviors such as non-waiting asynchronous call, and the function call statement should be regarded as a to-be-verified call statement.

[0042] The technical solution provided by the embodiment can effectively find the common omissions in asynchronous programming, i.e., starting an asynchronous task without correctly waiting for its completion, by identifying the to-be-verified call statement that does not use the preset asynchronous call operator and calls an asynchronous function. Such problems often lead to logical errors (such as data not ready), resource leaks (such as not closing the connection), or unreliable testing (such as asynchronous side effects not synchronized). By accurately identifying these call statements, the reliability of asynchronous code detection can be improved.

[0043] In order to accurately identify the potential non-compliant behavior of indirectly calling an asynchronous function through a variable, if there is an assignment operation in the to-be-detected code that assigns an asynchronous function to a target variable, the target variable is marked as an asynchronous function reference, so that the call statement in the to-be-detected code that calls the target variable and does not use the preset asynchronous call operator is determined as a to-be-verified call statement.

[0044] The assignment operation refers to a statement that binds the value of an expression to a variable name, such as x=some_function, where the right side can be a function object itself (not the call result). The target variable refers to the variable identifier on the left side in the assignment operation that receives the assigned content. The asynchronous function reference refers to the value held by the target variable, which is a direct reference to a certain asynchronous function (i.e., the variable stores the asynchronous function itself, not the call result), which preserves the asynchronous semantic properties of the original function.

[0045] In the embodiment, an abstract syntax tree is constructed for the code to be detected, and all assignment operations are identified; for an assignment with a function name (or resolvable as a function object) on the right side, it is determined through a symbol table resolution whether the function is an asynchronous function; if yes, the target variable on the left side is marked as an asynchronous function reference. In the analysis of a function call, if it is found that the operation object of a certain call statement is a target variable that has been marked, and the call does not use a preset asynchronous call operator, the call statement is identified as a to-be-verified call statement. At this time, the to-be-verified call statement is a statement for calling the target variable, and the call does not use the preset asynchronous call operator. Since the target variable actually points to an asynchronous function, such a call may have compliance problems and needs to be further verified as a to-be-verified call statement.

[0046] For example, when an asynchronous function is assigned to a target variable, its asynchronous type is automatically propagated to the variable; subsequent calls to the variable will inherit the asynchronous property of its return type. If await is not used in the call and the context does not explicitly handle Promise / Task types, the call is determined to be a potential violation and is classified as a to-be-verified call statement.

[0047] In complex code, asynchronous functions may be assigned, passed as parameters, or bound to properties (such as obj.handler = async Func) multiple times, forming multiple layers of aliases. Therefore, a variable alias map can be maintained within the scope to record which variables in the current context are equivalent to known asynchronous function references. When a call to these alias variables is detected, even if it does not directly use the original function name, as long as it does not use the preset asynchronous call operator, it should still be considered a to-be-verified call statement. This setting can enhance the coverage of indirect reference scenarios, ensure the comprehensiveness of the check, and avoid missing detection.

[0048] The technical solution provided in the embodiment identifies operations that assign asynchronous functions to target variables and marks the target variables as asynchronous function references, so that calls to these variables can also be included in the asynchronous compliance detection range, effectively solving the asynchronous call detection blind spot caused by common programming patterns such as function aliasing, callback encapsulation, or high-order function passing, ensuring that whether the original asynchronous function is called directly or indirectly through variables, as long as the preset asynchronous call operators such as await are not used correctly, it can be included in the compliance analysis range, thereby improving the integrity, comprehensiveness, and reliability of the asynchronous programming specification check, and reducing the risk of logical errors caused by "implicit asynchronous call missing await".

[0049] S130, performing context semantic analysis on the to-be-verified call statement to determine the execution type of the to-be-verified call statement.

[0050] The execution type refers to an execution behavior mode of the to-be-verified calling statement corresponding to a program runtime inferred according to context semantics. The execution type includes at least one of a reuse variable type, a return variable type, a loop variable collection type, and a task collection type.

[0051] The reuse variable type refers to that a calling result is assigned to a variable, and the variable is explicitly used in subsequent code (such as being passed as a parameter, participating in expression calculation, etc.), indicating that the asynchronous call has an explicit data dependency intention. For example, the reuse variable type refers to that although the to-be-verified calling statement itself does not use await, the generated coroutine object is intentionally saved and correctly awaited in the subsequent, indicating that the call is a delayed reuse rather than a missed processing, and belongs to a legal mode with an explicit reuse intention.

[0052] The return variable type refers to that a calling result is directly or indirectly used as a return value of a current function, for passing the result of an asynchronous operation to a caller. That is, the return variable type indicates that a coroutine object is passed as a return value of a function to a calling party, and the calling party decides when and how to wait for its completion.

[0053] The loop variable collection type refers to that in a loop structure (such as a for or while loop), an asynchronous function is called multiple times, and returned coroutine objects are collected into a list, array or other container for subsequent batch processing. That is, the loop variable collection type indicates that the to-be-verified calling statement is located in the loop body, the generated coroutine object is collected into an iterable list, and is uniformly awaited in the subsequent, belonging to a legal mode of batch asynchronous task collection and delayed execution.

[0054] The task collection type can be understood as follows: the purpose of calling an asynchronous function is to start a background concurrent task, and the returned awaitable object is explicitly collected into a task list, and is uniformly awaited or scheduled through mechanisms such as Promise.all, asyncio.gather, etc. in the subsequent. That is, the task collection type indicates that the execution intention of the to-be-verified calling statement is to pass the generated coroutine object as a parameter to a preset task collection function, so as to participate in batch concurrent execution and unified result processing.

[0055] In the embodiment, after the to-be-verified calling statement is identified, whether the return value of the calling expression is bound to a certain variable is analyzed. If there is an assignment operation, the subsequent use of the variable in its scope is further tracked. If the variable is used for function return, passed as a parameter into another function, or participates in expression calculation, it is determined that the execution type is the reuse variable type; if the variable appears in the return statement, it is classified as the return variable type. Through accurate variable life cycle and data flow path analysis, the execution intention of the calling statement can be accurately reflected.

[0056] In addition, when the to-be-verified calling statement is located in a loop body, it can be checked whether the return value of the to-be-verified calling statement is appended (such as through push, append, +=, and the like) to a collection class variable (such as a list, an array, or a Set, and the like). If there is such a collection mode, and the collection is used or returned after the loop ends, the execution type of the calling statement is determined as a loop variable collection type; if the collection is used to store an asynchronous task object (such as a Promise, a Task, or a coroutine), and there is subsequent unified waiting or concurrent scheduling logic (such as calling Promise.all or asyncio.gather), the calling statement is further classified as a task collection type.

[0057] A plurality of context mode templates can also be predefined, for example, "variable assignment return", "calling an asynchronous function in a list comprehension", "storing the calling result in a tasks list", and the like. The local code segment in which the to-be-verified calling statement is located is structurally compared, and if the context of the to-be-verified calling statement matches a template to a preset threshold, the execution type label corresponding to the to-be-verified calling statement can be determined based on the matched template.

[0058] S140, performing compliance detection on the to-be-verified calling statement according to the execution type, to obtain a detection result.

[0059] The detection result refers to a determination conclusion obtained after performing compliance detection on the to-be-verified calling statement, for example, including "compliant" or "non-compliant", and can be accompanied by auxiliary information such as a violation reason, a recommended repair method, and a confidence level.

[0060] In the embodiment, a corresponding compliance determination condition can be predefined for each execution type: for example, "task collection type" and "loop variable collection type" are considered compliant, because the coroutine object will be uniformly awaited in subsequent code or processed through a task aggregation mechanism; "return variable type" is considered compliant when the return value type of the function declaration is an asynchronous type (such as Promise <t>, Task <t>Or coroutine) also belongs to the compliance case. In the detection process, according to the identified execution type, the compliance judgment condition can be looked up and matched, and the corresponding detection result is output.

[0061] However, for the to-be-verified call statement classified as the reuse variable type or the loop variable collection type, only the execution type label may not be enough to completely confirm its compliance. For this purpose, it can be further verified whether the generated coroutine object is correctly used in the subsequent code (such as being awaited, being passed into a task collection function, or being used in other legal asynchronous contexts). Through data flow tracking, it is checked whether there is a break in the complete path from the coroutine object generation to the final use. If the path is complete and meets the asynchronous management requirements, it is determined to be compliant; otherwise, even if the type matches, it should be marked as non-compliant.

[0062] It should be noted that a comprehensive evaluation model can also be constructed, taking the execution type as the core feature, while integrating other context information of the to-be-verified call statement (such as variable scope life, whether it is located in test code, whether it belongs to a white list module, whether there is an annotation exemption mark, etc.), and obtaining a compliance confidence degree through weighted calculation. When the confidence degree is higher than a preset threshold, it is determined that the to-be-verified call statement is compliant; otherwise, it is marked as a potential violation.

[0063] The present embodiment realizes multi-level and high-precision judgment of asynchronous call compliance by combining execution type rules, data flow integrity verification, and context-aware confidence evaluation, and improves code quality.

[0064] In order to guarantee the specification of asynchronous programming while accurately distinguishing between legal advanced asynchronous modes and truly risky omissions, the to-be-verified call statement is detected for compliance according to the execution type, and the detection result can include: determining whether the execution type is any one of the reuse variable type, the return variable type, the loop variable collection type, and the task collection type; if yes, determining that the detection result for the to-be-verified call statement is a detection result containing call compliance; if no, determining that the detection result for the to-be-verified call statement is a detection result containing a call violation.

[0065] Among them, the detection result containing call compliance means that the to-be-verified call statement conforms to the asynchronous programming specification and belongs to the legal asynchronous use mode intentionally, without error or warning. The detection result containing a call violation is to determine that the to-be-verified call statement has a "missing await" risk, which may cause logic errors, resource leaks, or race conditions, and is marked as a violation.

[0066] It should be noted that the execution type includes but is not limited to four preset legal modes: a multiplex variable type (the coroutine object is assigned to a variable and is correctly used subsequently), a return variable type (the coroutine object is passed to the caller as a function return value), a loop variable collection type (the coroutine object is collected to an iterable list in a loop, and is uniformly awaited in subsequent traversal), and a task collection type (the coroutine object is passed as a parameter into a preset task collection function).

[0067] In the embodiment, it can be judged whether the execution type of the to-be-verified calling statement belongs to one of the four preset compliance modes, i.e., a multiplex variable type, a return variable type, a loop variable collection type, or a task collection type; if yes, it indicates that the calling does not use await at the calling point, but the context semantics embody an explicit asynchronous task management intention (such as delay multiplexing, interface transparent transmission, batch collection, or concurrent scheduling), which belongs to a legal usage conforming to asynchronous programming, and therefore it is determined that the detection result for the to-be-verified calling statement is a detection result containing calling compliance; if no, i.e., the execution type cannot be classified into any of the above categories, it indicates that the coroutine object is neither correctly awaited nor explicitly included in any controlled asynchronous processing flow, and there is a risk of missing await, which may cause logical errors, resource leaks, or race conditions, and therefore it is determined that the detection result for the to-be-verified calling statement is the detection result containing calling violation.

[0068] The advantage of such a setting is that semantic-level understanding of asynchronous calling intention is achieved, avoiding the one-size-fits-all approach of regarding all asynchronous calls without await as errors, effectively distinguishing between the two essentially different programming behaviors of reasonable omission of await and inadvertent omission of await, avoiding misjudgment of the asynchronous paradigm, accurately capturing real code defects with risks, and improving detection accuracy and reliability.

[0069] In some boundary cases, the identification of the execution type may be uncertain (such as ambiguous symbol resolution due to dynamic language characteristics). At this time, a confidence score can be assigned to each execution type; only when the confidence is higher than a set threshold and the type belongs to one of the four execution types, it is determined to be compliant. If the confidence is insufficient, or although there is a type label, but it lacks key context support (such as being marked as "multiplex variable type" but the variable is never used), it is conservatively classified as non-compliant.

[0070] It should be noted that, in order to further verify the robustness of the compliance determination, or to provide developers with practical repair suggestions, after determining the to-be-verified calling statement corresponding to the detection result containing the call compliance, the to-be-verified calling statement can be modified semantically (for example, explicitly adding await, encapsulating it into a task collection function, or adjusting its context structure), and the modified calling statement is analyzed again in the context semantics, and its execution type is determined again; according to the new execution type, the compliance is detected, and the updated detection result is obtained. The process can be iterated until the to-be-verified calling statement is determined to be clearly compliant in the current context, thereby forming a closed-loop verification and optimization mechanism.

[0071] In addition, the original statement in the to-be-detected code can also not be directly modified, but the modified recommended version is attached in the form of a comment, a quick fix prompt or an inline reference to the associated position of the original to-be-verified calling statement, for clearly showing the recommended compliant writing to the developer. For example, a comment is added below the code line: "Suggestion: If the result needs to be obtained here, please use await f()"; or an operation option of "automatic repair for task collection mode" is provided. In this way, the integrity of the original code is preserved, and intuitive and operable improvement guidance is provided for the developer, which helps to improve the code quality while reducing the risk of misrepair, and enhances the user experience.

[0072] The technical solution provided by the embodiment determines at least one asynchronous function in the to-be-detected code; identifies at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls the asynchronous function from the to-be-detected code; performs context semantic analysis on the to-be-verified calling statement to determine the execution type of the to-be-verified calling statement; and performs compliance detection on the to-be-verified calling statement according to the execution type to obtain a detection result, thereby solving the problem in the prior art that a keyword is missed in asynchronous function calling, and a compliant usage is mistakenly judged as a violation, resulting in false positives. After at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls an asynchronous function is identified from the to-be-detected code, the to-be-verified calling statement is further analyzed in the context semantics in multiple dimensions to accurately determine its execution type (such as a reuse variable type, a return variable type, a loop variable collection type or a task collection type), so that whether the calling is compliant is determined in combination with the specific execution type, the accuracy and robustness of asynchronous code detection are improved, legal programming modes are avoided from being mistakenly judged as violations, the code quality is guaranteed, the false positives of the developer are reduced, and the development efficiency is improved.

[0073] In order to accurately distinguish the asynchronous call behavior of "intentional delay processing" and "inadvertent omission of await", avoid misjudging the asynchronous mode conforming to the specification as a violation, the context semantic analysis is performed on the to-be-verified call statement, and the execution type of the to-be-verified call statement is determined, including: when it is detected that the coroutine object generated by the to-be-verified call statement is stored in the iterable dictionary, and the iterable dictionary is traversed in the first postcode associated with the iterable dictionary, and the preset asynchronous call operator operation is performed on the coroutine object in the traversal process, it is confirmed that the execution type of the to-be-verified call statement is the reuse variable type.

[0074] Wherein, the coroutine object refers to the object returned after the asynchronous function is called (such as the coroutine object in Python, the Promise object in JavaScript, etc.), which represents an asynchronous computing task that has not been completed, and needs to be obtained through a preset asynchronous call operator (such as await) to obtain its final result. The iterable dictionary refers to a dictionary structure supporting traversal operation (such as Python's dict, JavaScript's Map or ordinary object), the value or key-value pair of which can be accessed in the subsequent code through a loop (such as for...in, for...of, dict.items(), etc.). The first postcode refers to the program code after the to-be-verified call statement, which is in the same scope or control flow path, and can include subsequent processing logic of the coroutine object generated by the call.

[0075] In the embodiment, whether the coroutine object generated by the to-be-verified call statement is stored as a value in a certain dictionary variable can be identified; if yes, the subsequent use of the dictionary variable in its scope is analyzed, and the subsequent code is regarded as the first postcode. Further, it is judged whether there is a traversal operation (such as for loop, spread operator, or explicit items() / values() call, etc.) on the dictionary in the first postcode. If the preset asynchronous call operator operation is performed on the element (i.e. the original coroutine object) taken out from the iterable dictionary inside the traversal body, it indicates that the coroutine object has not been used with await at the call point, but has been intentionally saved and correctly consumed subsequently, and has an explicit data reuse intention, so the execution type of the to-be-verified call statement can be confirmed as the reuse variable type.

[0076] For example, if the function in the code to be detected contains the following logic: tasks = {}; tasks['user'] = f(user_id), where f is an asynchronous function defined by async def; in the subsequent code of the function, there is a traversal structure of for key in tasks: result = await tasks[key]. It is identified that the f(user_id) call does not use await and belongs to the to-be-verified call statement; further detection finds that the coroutine object returned by it is stored in the dictionary variable tasks, and in the first subsequent code, the dictionary is traversed through a for loop, and an await operation is explicitly performed on each value. This indicates that the coroutine object is not waiting at the call site, but has been intentionally collected and correctly used in the subsequent code. The execution type of the to-be-verified call statement can be confirmed as the reuse variable type.

[0077] In addition, the basic block where the to-be-verified call statement is located can be located in combination with the control flow graph and the abstract syntax tree, and the traversal nodes of the associated dictionary can be searched along the subsequent control flow path. In the traversal node, it is checked whether the loop body contains an await operation on the dictionary value, and whether the value can be traced back to the original coroutine object is verified through symbol resolution or data flow analysis. If the conditions are met, it is inferred that the developer's intention is to collect coroutine objects in batches first and then execute them uniformly, which belongs to the delayed reuse mode, and thus the execution type is classified as the reuse variable type.

[0078] A concurrent mode template can also be pre-configured, for example: "coroutine assignment -> store in dict -> subsequent for loop traversal dict.values() -> await in loop body". When the structure of the to-be-verified call statement and its first subsequent code matches the template, the execution type can be determined as the reuse variable type.

[0079] The technical solution provided in the embodiment can accurately identify the to-be-verified call statement that has an explicit reuse intention on the surface but does not use await in essence, and reasonably classify its execution type as the reuse variable type, by detecting whether the coroutine object is stored in an iterable dictionary and correctly applied to a preset asynchronous call operator in the traversal process of the first subsequent code. This setting effectively avoids misjudging the legal delayed processing or batch concurrency mode as a violation, improves the accuracy of asynchronous compliance detection, and provides developers with more accurate and less intrusive code quality feedback.

[0080] To accurately identify the semantic intention of the asynchronous call as a reasonable pass-through part of the interface contract or hierarchical abstraction in the program, and avoid misjudging a reasonable design pattern as a violation, context semantic analysis needs to be performed on the to-be-verified call statement to determine the execution type of the to-be-verified call statement, including: when it is detected that the to-be-verified call statement is located in a return variable statement, and the return value thereof is a coroutine object generated by an asynchronous function call, it is confirmed that the execution type of the to-be-verified call statement is a return variable type.

[0081] The return variable statement refers to a statement for returning the value of an expression as the execution result of the current function, which can be guided by the return keyword.

[0082] In this embodiment, syntax analysis can be performed on the to-be-detected code to identify whether the to-be-verified call statement is located in a return variable statement. If the call statement constitutes the return expression of a return statement, and the called function has been determined to be an asynchronous function, it indicates that the call generates a coroutine object as the return value of the function, and the intention is to pass the asynchronous task to the upper calling party, rather than executing or waiting in the current function. At this time, it can be confirmed that the execution type of the to-be-verified call statement is a return variable type. Alternatively, when it is detected that the to-be-verified call statement is located in a return variable statement, and the return value thereof is a coroutine object generated by an asynchronous function call, it can also be determined that the current function is not used to execute the asynchronous operation, but returns it as a result, and it is up to the calling party to decide when to wait or schedule, which belongs to the compliant usage conforming to the asynchronous programming specification, and therefore the execution type thereof is confirmed to be a return variable type.

[0083] For example, the implementation of function g is return f(), where f is an asynchronous function defined by async def; when analyzing function g, it is identified that the f() call does not use await, and belongs to the to-be-verified call statement; further analysis finds that the call constitutes the return value of the return statement, and the return value thereof is a coroutine object (i.e., the result of the asynchronous function call); it can be judged that the call is not an oversight of missing await, but intentionally returns the asynchronous task as a result for subsequent processing by the calling party, and therefore the execution type thereof is classified as a return variable type.

[0084] It should be noted that the return statement can include conditional branches (such as if-else, ternary expressions) or multiple nested calls. In such scenarios, it can be tracked along the control flow path whether the to-be-verified call statement is ultimately the return value of a valid return path; if the coroutine object is originally passed to the return statement without being converted or used by intermediate logic, it can be confirmed that the execution type thereof is a return variable type.

[0085] The technical solution provided by the embodiment can accurately identify the design intention of the developer to transparently pass the asynchronous task to the calling party, and confirm the execution type of the calling statement as the return variable type, thereby effectively avoiding the misjudgment of reasonable and compliant code as a violation, so as to ensure the normativity of asynchronous calling while improving the accuracy of code analysis, development efficiency and user experience.

[0086] In order to support legal asynchronous programming mode in the batch concurrent task scenario, and avoid misjudging efficient parallel collection logic as an unhandled asynchronous call, context semantic analysis needs to be performed on the calling statement to be verified to determine the execution type of the calling statement to be verified, including: when it is detected that the calling statement to be verified is located in a loop body, and the coroutine object generated by the calling statement to be verified is stored in an iterable list, and the iterable list is iterated in the second postcode associated with the iterable list, and the preset asynchronous call operator operation is performed on the coroutine object in the iteration process, it is confirmed that the execution type of the calling statement to be verified is the loop variable collection type.

[0087] The loop body refers to a code block surrounded by a loop control structure (such as for, while, etc.), which is repeatedly executed in each iteration. The iterable list refers to an ordered container (such as Python's list, JavaScript's Array, etc.) that supports iteration operations, and its elements can be accessed one by one in the subsequent code through a loop structure. The second postcode refers to the program code after the loop ends and is logically followed in the same scope, which may include processing logic for the iterable list.

[0088] In the embodiment, it can be determined whether the calling statement to be verified is located inside a certain loop body; if so, it is further analyzed whether the coroutine object generated by the calling is added as an element to a certain list variable (such as through append, push or list comprehension, etc.). The subsequent use of the list variable in its scope is detected, and this part of the code is regarded as the second postcode, and the list corresponding to the list variable is the iterable list. If there is an iteration operation (such as for item in list) on the iterable list in the second postcode, and the preset asynchronous call operator (such as await) is explicitly executed on each element in the iteration body, it indicates that the developer adopts the "first collect coroutine object, then uniformly await" concurrent strategy, and the execution type of the calling statement to be verified can be confirmed as the loop variable collection type.

[0089] For example, if a function in the code to be detected contains a for loop: async_tasks = [], the loop body executes async_tasks.append(f(url)), where f is an asynchronous function defined by async def; after the loop ends, there is the following code in the same scope: for task in async_tasks: result = await task. It is judged that f(url) is called inside the loop body, and the coroutine object returned by f(url) is added to the list variable async_tasks; the traversal code after the loop is regarded as the second postorder code, and it is identified that the iterable list async_tasks is explicitly used with the await operation for each element in the traversal process, so the execution type of the call statement to be verified can be confirmed as the loop variable collection type.

[0090] In addition, the basic block where the call statement to be verified is located can be located, the loop structure and its exit node to which the call statement belongs can be identified, the list variable written by the coroutine object generated in the loop body can be recorded, and the use point of the list after the loop ends can be searched forward along the control flow path. If the traversal of the list is found in a successor basic block, the traversal body contains the await operation for the element, and the element is proved to be the original coroutine object through the data dependency chain, it can be confirmed that the execution type is the loop variable collection type.

[0091] A loop mode template can also be pre-configured, for example: "call asynchronous function in loop body -> append result to list -> for loop to traverse the list after the loop ends -> await element in the loop body". When the structure of the call statement to be verified and the second postorder code matches the loop mode template, it is considered that the coroutine call is reasonable, and the execution type is determined as the loop variable collection type.

[0092] The technical solution provided in the embodiment can accurately identify the "batch collection-unified execution" asynchronous mode intentionally used by the developer by detecting whether the call statement to be verified is located in the loop body, whether the coroutine object generated by the call statement is stored in the iterable list, and whether the list is traversed in the second postorder code and correctly applied to the preset asynchronous call operator. Such calls are classified as the loop variable collection type, which effectively avoids misjudging reasonable and efficient concurrent logic as a violation, thereby ensuring the normality of asynchronous calls.

[0093] In order to accurately identify the legal asynchronous mode that the developer intentionally uses the concurrent task aggregation mechanism, and avoid misjudging the normal batch task scheduling as an unprocessed asynchronous call, context semantic analysis needs to be performed on the to-be-verified calling statement to determine the execution type of the to-be-verified calling statement, including: when it is detected that the to-be-verified calling statement contains any function name in the preset task collection function set, it is confirmed that the execution type of the to-be-verified calling statement is a task collection type.

[0094] The preset task collection function set refers to a set of function names that are predefined and used to explicitly collect and manage multiple coroutine objects (or asynchronous tasks). For example, the preset task collection function set includes batch await functions (batch_await_functions) and task creation functions (task_creation_function). The batch await function refers to a function used to batch or conditionally manage multiple coroutine executions. The task creation function refers to a function that directly or indirectly submits a coroutine object to an event loop for scheduling and execution. Even if await is not explicitly used, the coroutine will be activated and run. The function name is used to indicate the specific function called.

[0095] The preset task collection function set can be pre-configured. Optionally, the batch await function includes but is not limited to: Gather ("concurrent collection" or "parallel await", used to start multiple coroutines at the same time and wait for them to complete, return the results in the original order), wait ("wait for a set of tasks", used to wait for multiple coroutines or tasks to complete (the completion condition can be specified, such as all completed, any completed, etc.), return the set of completed and incomplete tasks), wait_for ("timeout waiting", used to wait for a single coroutine to complete, but if it does not complete within the specified time, a TimeoutError is thrown, used to prevent indefinite blocking), as_completed ("iterate in completion order", used to return an asynchronous iterator, and whenever one of the coroutines completes, its result is provided), and the like.

[0096] The task creation functions include but are not limited to: create_task ("create task", which is used to wrap a coroutine into a Task object and submit it to the event loop for scheduling and execution), ensure_future ("ensure future object" (or "ensure Task"), which is used to convert a coroutine, Future or Task into a Task; if the input is already a Task, it is returned directly), gather ("gather", which is used for batch waiting, but it automatically encapsulates the input coroutine as a Task and schedules it for execution, so it has a task creation behavior), wait ("wait for a set of tasks", which is used to receive multiple coroutines or Tasks, and internally converts the coroutines into Tasks and submits them to the event loop, and then waits for their completion according to the conditions), wait_for ("wait with timeout", which internally encapsulates the input coroutine as a Task and starts it, and sets up a timeout monitoring, so it also involves task creation), run_until_complete ("run until complete", an event loop method, which is used to start a coroutine or Future in a non-asynchronous context, and blocks until it is completed; it implicitly schedules the task), run ("run main coroutine", which is used to create a new event loop, run the input coroutine until completion, and clean up resources; internally, the coroutine is scheduled as a task), and new ("new coroutine / task", which is used to start a new coroutine).

[0097] Since the batch waiting functions and the task creation functions both involve explicit management of multiple asynchronous tasks in terms of function, there is a functional overlap or complementary relationship between the two, and therefore the union of the batch waiting functions and the task creation functions can be used as the preset task collection function set.

[0098] In this embodiment, the syntax of the to-be-verified calling statement can be parsed to extract the function name directly called by the to-be-verified calling statement; and the function name is compared with the preset task collection function set. If there is a match, it indicates that the purpose of the call is to pass multiple coroutine objects or asynchronous tasks as parameters into a unified aggregation or scheduling function, which is executed concurrently by the runtime system and coordinates the results. Although such a call does not use await for each asynchronous function individually, its overall behavior belongs to explicit and controlled task collection and scheduling, which conforms to the asynchronous programming specification. Therefore, it is confirmed that the execution type of the to-be-verified calling statement is the task collection type.

[0099] It should be noted that in actual code, the functions in the preset task collection function set can be renamed, given an alias when imported, or called through property access. At this time, relying only on the literal function name matching may lead to missed judgment. Therefore, the real binding target of the function name in the current scope can also be parsed in combination with the symbol table and the import statement; if the target finally points to a function in the preset task collection function set, it can be confirmed that the execution type is the task collection type.

[0100] In addition, the function name can also be the same as the preset task collection function but different in semantics (for example, a user customizes a normal function named gather). To avoid misjudgment, the parameter characteristics of the call can be further analyzed: if the parameters contain multiple coroutine objects or awaitable objects, and the return value is used for subsequent await operations or task management logic, the confidence of the judgment can be enhanced. By combining function name matching and parameter semantic consistency verification, the false positive rate can be effectively reduced while maintaining a high recall rate, making the identification result more accurate and reliable.

[0101] The technical solution provided by the embodiment can effectively identify the concurrent task aggregation mode intentionally adopted by the developer by detecting whether the to-be-verified call statement contains a function name in the preset task collection function set and combining the activation domain analysis and context semantic verification. Confirming such a call as a task collection type not only accurately reflects its legal and efficient asynchronous programming intention, but also avoids misjudgment due to the surface "not using wait", so that the compliance detection can cover the basic call specification and improve the accuracy of detection while ensuring the safety of the code.

[0102] As an optional embodiment of the above embodiment, in order to make those skilled in the art further clear the technical solutions of the embodiments of the present application, specific application scenario examples are given. Specifically, refer to the following specific content.

[0103] Reference is made to Figure 2 The technical solution provided by the embodiment can realize compliance detection of asynchronous function calls based on multi-pass abstract syntax tree analysis and context semantic awareness analysis. The specific implementation manner can be: inputting a code to be detected; constructing an abstract syntax tree of the code to be detected. The abstract syntax tree is scanned for the first time to perform annotation analysis and line number mapping, and so on, to identify asynchronous functions in the code to be detected. Whether a function referenced by a function name in a current module in the code to be detected is an asynchronous function can be determined through cross-module import relationship analysis. Whether there is an assignment operation of assigning an asynchronous function to a target variable can be determined through class method asynchronous attribute mapping and variable type derivation. If there is, the target variable is marked as an asynchronous function reference. And a call to the target variable in the code to be detected and a call statement without using await are determined as a call to be verified. And an asynchronous function call without using a preset asynchronous call operator and calling an asynchronous function in the code to be detected is taken as a call to be verified, so as to construct a global call to be verified knowledge base. The execution type of the call to be verified is identified through detection of reuse variable types, return variable types, loop variable collection types and task collection types. If the execution type of the call to be verified is any one of the reuse variable types, the return variable types, the loop variable collection types and the task collection types, the detection result of the call to be verified is determined as a detection result containing a call compliance. If the execution type of the call to be verified is not any one of the reuse variable types, the return variable types, the loop variable collection types and the task collection types, the detection result of the call to be verified is determined as a detection result containing a call violation.

[0104] It should be noted that context semantic analysis of the call to be verified can be performed to determine the execution type of the call to be verified as soon as one call to be verified is identified.

[0105] Next, the abstract syntax tree can be scanned again to perform context-aware coroutine call detection on the call to be verified with the detection result containing a call violation. Through maintenance of a plurality of execution states such as return statement context, task creation context, asyncwith context and lambda function context, the rationality of the coroutine call is verified again to realize false positive filtering. If the detection result is still the detection result containing a call violation, the detection result is output. The detection result can include but is not limited to application annotation control rules, detailed error reports and statistical analysis results, and so on. Thus, high-precision and low-false-positive asynchronous function call error detection is realized. The technical solution also supports fine-grained detection control through annotations, and provides flexible false positive suppression.

[0106] Figure 3 is a structural schematic diagram of a code detection device according to an embodiment of the application. As shown in Figure 3 As shown, the device comprises: an asynchronous function determination module 210, a to-be-verified calling statement determination module 220, an execution type determination module 230, and a detection result determination module 240.

[0107] The asynchronous function determination module 210 is configured to determine at least one asynchronous function in the to-be-detected code; the to-be-verified calling statement determination module 220 is configured to identify at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls the asynchronous function from the to-be-detected code; the execution type determination module 230 is configured to perform context semantic analysis on the to-be-verified calling statement to determine an execution type of the to-be-verified calling statement; the execution type comprises at least one of a multiplexing variable type, a return variable type, a loop variable collection type, and a task collection type; and the detection result determination module 240 is configured to perform compliance detection on the to-be-verified calling statement according to the execution type to obtain a detection result.

[0108] The technical scheme of the embodiment determines at least one asynchronous function in the to-be-detected code, identifies at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls the asynchronous function from the to-be-detected code, performs context semantic analysis on the to-be-verified calling statement to determine an execution type of the to-be-verified calling statement, and performs compliance detection on the to-be-verified calling statement according to the execution type to obtain a detection result, thereby solving the problem in the prior art that a legal programming mode is misjudged as a violation due to missing a keyword in asynchronous function calling, resulting in false positives, and achieving the following: after identifying at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and that calls an asynchronous function from the to-be-detected code, further performing multi-dimensional analysis on the to-be-verified calling statement in terms of context semantics to accurately determine an execution type (such as a multiplexing variable type, a return variable type, a loop variable collection type, or a task collection type) of the to-be-verified calling statement, and then determining whether calling is compliant in combination with the specific execution type, thereby improving the accuracy and robustness of asynchronous code detection, avoiding misjudgment of a legal programming mode as a violation, ensuring code quality, reducing false positives for developers, and improving development efficiency.

[0109] On the basis of the device described above, optionally, the asynchronous function determination module 210 is configured to determine a function defined by a preset asynchronous definition identifier in the to-be-detected code as an asynchronous function.

[0110] On the basis of the device described above, optionally, the to-be-detected code further comprises at least one import statement, and the asynchronous function determination module 210 further comprises: An external module determination unit is configured to parse an external module referenced by the import statement; the external module is a source code module different from a current module of the import statement in the to-be-detected code. The function type determination unit is configured to determine a function type of a function corresponding to the function name imported in the external module. The reference determination unit is configured to determine the function referenced by the function name in the current module as an asynchronous function if the function type is the asynchronous type.

[0111] On the basis of the apparatus, optionally, the apparatus further comprises: The type transmission unit is configured to mark the target variable as an asynchronous function reference if the assignment operation of assigning the asynchronous function to the target variable exists in the to-be-detected code, so as to determine a calling statement of the target variable in the to-be-detected code and not using the preset asynchronous calling operator as a to-be-verified calling statement.

[0112] On the basis of the apparatus, optionally, the execution type determination module 230 is configured to determine that the execution type of the to-be-verified calling statement is the reuse variable type when it is detected that the coroutine object generated by the to-be-verified calling statement is stored in the iterable dictionary, the iterable dictionary is iterated in the first post-order code associated with the iterable dictionary, and the preset asynchronous calling operator operation is performed on the coroutine object in the iteration process.

[0113] On the basis of the apparatus, optionally, the execution type determination module 230 is configured to determine that the execution type of the to-be-verified calling statement is the return variable type when it is detected that the to-be-verified calling statement is located in a return variable statement.

[0114] On the basis of the apparatus, optionally, the execution type determination module 230 is configured to determine that the execution type of the to-be-verified calling statement is the loop variable collection type when it is detected that the to-be-verified calling statement is located in a loop body, the coroutine object generated by the to-be-verified calling statement is stored in the iterable list, the iterable list is iterated in the second post-order code associated with the iterable list, and the preset asynchronous calling operator operation is performed on the coroutine object in the iteration process.

[0115] On the basis of the apparatus, optionally, the execution type determination module 230 is configured to determine that the execution type of the to-be-verified is the task collection type when it is detected that the to-be-verified calling statement contains any function name in the preset task collection function set.

[0116] On the basis of the above device, the detection result determination module 240 is specifically configured to determine whether the execution type is any one of a multiplex variable type, a return variable type, a loop variable collection type, and a task collection type; if yes, it is determined that the detection result for the to-be-verified call statement is a detection result containing a call compliance; and if no, it is determined that the detection result for the to-be-verified call statement is a detection result containing a call violation.

[0117] The code detection device provided in the embodiments of the present application can execute the code detection method provided in any of the embodiments of the present application, and has the corresponding function modules and beneficial effects of the execution method.

[0118] Figure 4 is a structural schematic diagram of an electronic device implementing the code detection method of the embodiments of the present application. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular telephones, smart phones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit the implementations of the present application described and / or claimed in this document.

[0119] As shown in Figure 4 The electronic device 10 includes at least one processor 11, and a memory, such as a read-only memory 12, a random access memory 13, etc., which is communicatively connected to the at least one processor 11, wherein the memory stores a computer program that can be executed by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory 12 or loaded from the storage unit 18 into the random access memory 13. In the random access memory 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the read-only memory 12, and the random access memory 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0120] The plurality of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, a loudspeaker, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0121] The processor 11 can be various general and / or special purpose processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, and the like. The processor 11 performs various methods and processes described above, such as the code detection method.

[0122] In some embodiments, the code detection method can be implemented as a computer program tangibly embodied in a computer readable storage medium, such as the storage unit 18. In some embodiments, parts or all of the computer program can be loaded and / or installed onto the electronic device 10 via the read-only memory 12 and / or the communication unit 19. One or more steps of the code detection method described above can be performed when the computer program is loaded onto the random access memory 13 and executed by the processor 11. Alternatively, in other embodiments, the processor 11 can be configured, by way of firmware or software, to execute the code detection method.

[0123] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0124] Computer programs used to implement the methods of the application can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program, when executed by the processor of the machine, implements the functions / acts specified in the flowcharts and / or block diagrams. The computer program can be executed entirely on a machine, partially on a machine, partially on a machine and partially on a remote machine or entirely on a remote machine or server.

[0125] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. A computer-readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of a machine-readable storage medium will include one or more lines of a program of instructions in a transitory signal, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0126] To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0127] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0128] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. Servers can be cloud servers, also known as cloud computing servers or cloud hosts, which are a host product in the cloud computing service system to solve the defects of large management difficulty and weak business scalability in traditional physical hosts and VPS services.

[0129] In particular, the processes described above with reference to the flowcharts can be implemented as a computer software program in accordance with embodiments of the present application. For example, embodiments of the present application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program comprising program code for executing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via the communication unit 19, or installed from the storage unit 18, or installed from the read-only memory 12. When the computer program is executed by the processor 11, the above-described functions defined in the methods of the embodiments of the present application are performed.

[0130] Embodiments of the present application also provide a computer program product comprising a computer program which, when executed by a processor, implements the code detection method as provided by any of the embodiments of the present application.

[0131] The computer program code implementing the present application can be written in one or more programming languages or combinations of languages including object oriented languages such as Java, Smalltalk, C++ or the like and conventional procedural programming languages such as "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0132] It should be understood that various forms of flow shown above can be re-ordered, added to, or deleted from without departing from the spirit of the present application. For example, the steps recited in the present application can be performed in parallel, in series, or in different orders, as long as the desired results of the technical solutions of the present application are achieved, which are not limited herein.

[0133] The above detailed description does not limit the scope of the application. Various modifications, combinations, sub-combinations and alternatives can be made to the detailed embodiment within the scope of the application. Any modification, equivalent replacement and improvement made without departing from the spirit and principle of the application shall fall within the scope of the application.< / t> < / t> < / t> < / t>

Claims

1. A code detection method characterized by, The method comprises the steps of: determining at least one asynchronous function in the code to be detected; identifying, from the code to be detected, at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls the asynchronous function; performing context semantic analysis on the to-be-verified calling statement to determine the execution type of the to-be-verified calling statement; the execution type comprises at least one of a multiplexing variable type, a return variable type, a loop variable collection type, and a task collection type; performing compliance detection on the to-be-verified calling statement according to the execution type to obtain a detection result.

2. The method of claim 1, wherein, The method comprises the steps of: determining a function defined by a preset asynchronous definition identifier in the code to be detected as an asynchronous function.

3. The method of claim 2, wherein, The code to be detected further comprises at least one import statement, and when the function defined by the preset asynchronous definition identifier in the code to be detected is determined as an asynchronous function, the method further comprises the steps of: parsing an external module referenced by the import statement; the external module is a source code module different from a current module of the import statement in the code to be detected; determining the function type of a function corresponding to a function name imported in the import statement in the external module; if the function type is an asynchronous type, determining a function referenced by the function name in the current module as an asynchronous function.

4. The method of claim 1, wherein, The method further comprises the steps of: if there is an assignment operation of assigning the asynchronous function to a target variable in the code to be detected, marking the target variable as an asynchronous function reference, so as to determine a calling statement that calls the target variable and does not use the preset asynchronous calling operator in the code to be detected as a to-be-verified calling statement.

5. The method of claim 1, wherein, The method further comprises the steps of: when it is detected that a coroutine object generated by the to-be-verified calling statement is stored in an iterable dictionary, and the iterable dictionary is traversed in a first post-order code associated with the iterable dictionary, and the preset asynchronous calling operator is executed on the coroutine object during the traversal, it is determined that the execution type of the to-be-verified calling statement is a multiplexing variable type.

6. The method of claim 1, wherein, The method further comprises the steps of: when it is detected that the to-be-verified calling statement is located in a return variable statement, it is determined that the execution type of the to-be-verified calling statement is a return variable type.

7. The method of claim 1, wherein, The method further comprises the steps of: when it is detected that the to-be-verified calling statement is located in a loop body, and a coroutine object generated by the to-be-verified calling statement is stored in an iterable list, and the iterable list is traversed in a second post-order code associated with the iterable list, and the preset asynchronous calling operator is executed on the coroutine object during the traversal, it is determined that the execution type of the to-be-verified calling statement is a loop variable collection type.

8. The method of claim 1, wherein, The method further comprises the steps of: When it is detected that the function name of any function in the preset task collection function set is contained in the to-be-verified calling statement, it is confirmed that the execution type of the to-be-verified calling statement is a task collection type.

9. The method of claim 1, wherein, The compliance detection of the to-be-verified calling statement according to the execution type is performed to obtain a detection result, including: It is determined whether the execution type is any one of a multiplex variable type, a return variable type, a loop variable collection type and a task collection type; If yes, it is determined that the detection result for the to-be-verified calling statement is a detection result containing calling compliance; If no, it is determined that the detection result for the to-be-verified calling statement is a detection result containing calling violation.

10. A code detection apparatus characterized by comprising: including: An asynchronous function determination module is configured to determine at least one asynchronous function in the to-be-detected code; A to-be-verified calling statement determination module is configured to identify at least one to-be-verified calling statement that does not use a preset asynchronous calling operator and calls the asynchronous function from the to-be-detected code; An execution type determination module is configured to perform context semantic analysis on the to-be-verified calling statement to determine an execution type of the to-be-verified calling statement; wherein the execution type includes at least one of a multiplex variable type, a return variable type, a loop variable collection type and a task collection type; A detection result determination module is configured to perform compliance detection of the to-be-verified calling statement according to the execution type to obtain a detection result.

11. An electronic device, comprising: The electronic device includes: at least one processor; and a memory connected with the at least one processor in communication; wherein The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the code detection method of any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for enabling the processor to execute the code detection method of any one of claims 1-9 when executed.

13. A computer program product comprising a computer program, characterized in that, The computer program, when executed by the processor, implements the code detection method of any one of claims 1-9.

Images