Code context extraction method and device, storage medium and electronic equipment

Abstract

The application relates to the technical field of artificial intelligence and software development, and provides a code context extraction method and device, a storage medium and an electronic device, which comprise the following steps: obtaining a symbolic propagation graph constructed based on syntax and semantic analysis of code, the symbolic propagation graph comprising a plurality of symbolic nodes and propagation relationship edges representing propagation relationships between symbols; determining a starting node and a target node in the symbolic propagation graph based on a current editing position and an input prompt; performing bidirectional graph traversal in the symbolic propagation graph with the starting node and the target node as end points, determining a semantic reachable path connecting the starting node and the target node; and extracting a corresponding code context based on the symbolic nodes involved in the semantic reachable path. The application effectively eliminates redundant code, reduces context volume and reasoning overhead, and improves code generation accuracy and interpretability.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and software development technology, and more specifically, to a code context extraction method and apparatus, storage medium and electronic device. Background Technology

[0002] In AI-assisted programming, code generation models typically require project source code as context input for code completion or generation. Existing technologies often employ methods such as keyword matching, call graph traversal, or file path similarity judgment to filter candidate files, or concatenate a large range of source code files before feeding them into the model for processing.

[0003] However, the above methods lack accurate identification of the actual data flow and control flow dependencies between code segments, resulting in a large amount of redundant information in the code segments included in the context that is not substantially related to the current editing task. This not only increases the consumption of server computing resources and response latency, but also makes it difficult to accurately reflect the propagation path at the variable level or expression level, making the context selection result lack deterministic guarantee. Summary of the Invention

[0004] To address the problems of severe code context redundancy and lack of deterministic guarantees in existing technologies, this application provides a code context extraction method, apparatus, storage medium, and electronic device to achieve accurate context extraction and trimming based on symbol propagation graphs.

[0005] According to a first aspect of this application, a code context extraction method is provided, the method comprising: obtaining a symbol propagation graph constructed based on the syntax and semantic analysis of the code, the symbol propagation graph including multiple symbol nodes and propagation relationship edges representing propagation relationships between symbols; determining a starting node and a target node in the symbol propagation graph based on the current editing position and input prompts; performing a bidirectional graph traversal in the symbol propagation graph with the starting node and the target node as endpoints to determine a semantically reachable path connecting the starting node and the target node; and extracting the corresponding code context based on the symbol nodes involved in the semantically reachable path.

[0006] According to a second aspect of this application, a code context extraction apparatus is provided, the apparatus comprising: a graph acquisition module, configured to acquire a symbol propagation graph constructed based on the syntax and semantic analysis of code, the symbol propagation graph including multiple symbol nodes and propagation relationship edges representing propagation relationships between symbols; a node determination module, configured to determine a starting node and a target node in the symbol propagation graph based on the current editing position and input prompts; a traversal module, configured to perform a bidirectional graph traversal in the symbol propagation graph with the starting node and the target node as endpoints, and determine a semantically reachable path connecting the starting node and the target node; and a context extraction module, configured to extract the corresponding code context based on the symbol nodes involved in the semantically reachable path.

[0007] According to a third aspect of this application, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the code context extraction method described above.

[0008] According to a fourth aspect of this application, an electronic device is provided, including a processor; and a memory for storing one or more programs, which, when executed by the processor, cause the processor to implement the code context extraction method described above.

[0009] The technical solution provided in this application transforms deep dependencies between codes into a graph structure containing symbol nodes and propagation relationship edges by acquiring a symbol propagation graph constructed based on syntactic and semantic analysis. This overcomes the limitations of traditional methods that rely solely on text matching or shallow call relationships. Based on this, the starting and target nodes are determined by combining the current editing position and input prompts, and a bidirectional graph traversal is performed to determine semantically reachable paths. This mechanism utilizes the intersection of forward influence exploration and reverse dependency tracing to theoretically guarantee the dual connectivity and necessity of the extracted context in both data flow and control flow. Finally, based on semantically reachable paths, the code context is accurately extracted, effectively eliminating redundant code that is not substantially related to the current task. Without relying on the long-term context understanding capabilities of large models, this significantly reduces the context volume and inference computation overhead, while simultaneously improving the accuracy of code generation and the interpretability of results.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating a code context extraction method according to an exemplary embodiment of this application is shown schematically; Figure 2 The flowchart illustrating the determination of target nodes based on a correlation score calculation formula according to an exemplary embodiment of this application is shown in the illustration. Figure 3 The flowchart illustrating the determination of semantically reachable paths and pruning operations based on bidirectional graph traversal according to an exemplary embodiment of this application is shown in the illustration. Figure 4 The flowchart illustrating the construction of a simplified code context based on source file set loading and simplification operations according to an exemplary embodiment of this application is shown in the illustration. Figure 5 A block diagram of a code context extraction apparatus according to an exemplary embodiment of this application is illustrated schematically; Figure 6 The schematic diagram illustrates a module diagram of an electronic device according to an exemplary embodiment of this application. Detailed Implementation

[0012] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of the embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced with one or more of the specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this application.

[0013] Furthermore, the accompanying drawings are merely illustrative of this application and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0014] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all steps. For example, some steps may be broken down, while others may be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances. Furthermore, all the terms "first" and "second" used below are for distinction purposes only and should not be construed as limiting the scope of this application.

[0015] Example 1 like Figure 1 As shown in the figure, this application provides a code context extraction method. This method achieves high-precision code context extraction by constructing a deep dependency graph structure and combining it with a bidirectional traversal mechanism. Specifically, the method includes the following steps: Step S110: Obtain the symbol propagation graph constructed based on code syntax and semantic analysis. The symbol propagation graph includes multiple symbol nodes and propagation relationship edges representing the propagation relationship between symbols.

[0016] Specifically, a Symbol Propagation Graph (SPG) is an abstract data structure that reflects the deep logical connections within code. Unlike traditional text indexes or simple abstract syntax trees, it treats symbols such as functions, variables, and types as nodes and models the actual propagation relationships between them under control and data flow constraints as directed edges. The foundation for this graph structure is syntax and semantic analysis. In practice, this analysis can be achieved through static program analysis of the source code, such as using the compiler's front-end parsing capabilities to capture the dependencies between symbol definitions and usage points; or by analyzing intermediate representations or bytecode to obtain unified semantic information across languages.

[0017] It should be understood that although this embodiment may be described using compile-time analysis of the C++ language as an example, the construction method of the symbol propagation graph is not limited to a specific programming language or a specific analysis time, as long as it can accurately represent the propagation relationship between symbols. Through this step, the system transforms unstructured code text into a structured dependency graph, providing a deterministic data foundation for subsequent accurate retrieval and avoiding semantic ambiguity problems caused by relying solely on keyword matching.

[0018] In one alternative implementation, the propagation relationship edge includes at least one of the following: a call relationship edge, a data flow relationship edge, a parameter binding relationship edge, a return relationship edge, and a type implementation relationship edge.

[0019] Specifically, these five types of propagation relationship edges together form the skeleton of the symbolic propagation graph that represents the deep semantic relationships of the code, enabling the graph structure to go beyond simple text indexes or shallow call chains and accurately reflect the real data flow and control dependencies during program execution.

[0020] Among them, the call relationship edge is used to represent the control flow transfer between the function definition and its call point. For example, in C++ code, when function A explicitly calls function B, a directed call edge is established between the symbol nodes of the two.

[0021] Data flow relation edges are used to depict the numerical transfer path between variable declaration and its assignment and reading operations. For example, if a global variable is written and then read in a subsequent expression, this read-write dependency is connected by data flow edges.

[0022] The parameter binding relationship specifically describes the value passing or reference binding between actual and formal parameters during function calls, ensuring that data propagation across function boundaries can be traced.

[0023] The return relationship edge indicates that the function's return value flows from the return statement to the receiving variable at the calling point, completing the data loop of function interaction.

[0024] The type implementation relationship edge covers the reference relationship from subtype to parent type in object-oriented features such as class inheritance and interface implementation, supporting the analysis of polymorphism and abstract dependencies.

[0025] It should be understood that although this embodiment lists the five specific edge types mentioned above, in practical applications, other types of propagation relationship edges can be extended according to the syntactic characteristics of the target programming language, as long as they can represent the semantic propagation between symbols. By finely modeling these propagation relationships, the system can accurately distinguish the strength and direction of different types of dependencies during subsequent traversal, thereby providing a high-fidelity structured basis for context extraction.

[0026] In one specific implementation, the set of edges in the symbolic propagation graph can be formally represented as: (1) Formula (1) is used to define the set of labeled directed edges in the Symbolic Propagation Graph (SPG). Where, Let be the set of labeled directed edges that exist between nodes. and It serves as a unique identifier for the symbol (i.e., a vertex in the graph). The set of unique identifiers for all identifiable symbol nodes. , For relation types, It is a set of five basic types of propagation relationships: (2) Formula (2) is used to define the set of five basic propagation relationship types in the Symbolic Propagation Graph (SPG). Where, Represents calling relation edges, Represents data flow relationship edges, Represents the parameter binding relationship edge, Represents returning the relation edge, The representative type implements the relationship edge.

[0027] As an optional implementation, symbol nodes are identified by globally unique identifiers. The encoding rule for the globally unique identifiers is to concatenate the source file relative path, scope chain, and symbol name using a preset separator. The symbol name is then processed by name reorganization to eliminate overload ambiguity.

[0028] Specifically, this three-stage coding rule design aims to solve the problems of symbol naming conflicts and ambiguous positioning in large projects. The relative path of the source file provides the physical storage location of the symbol, the scope chain (such as namespace, class name nesting level) defines the logical scope of the symbol, and the symbol name after name reorganization transforms the originally potentially duplicated function names into unique strings containing parameter type information.

[0029] For example, for two overloaded functions with the same name but different parameters, void process(int) and void process(string), their symbolic names will be reorganized into forms like _process_i and _process_s, thereby completely eliminating ambiguity at the level of globally unique identifiers.

[0030] This identification mechanism not only ensures the absolute uniqueness of each node in the graph, but also provides a standardized key-value basis for subsequent cross-file retrieval and matching. Compared to simple identification methods that rely solely on function names or line numbers, this encoding rule can effectively address the risk of identification failure caused by code refactoring, file movement, or namespace adjustments, significantly improving the robustness and traceability of the symbol propagation graph in long-term maintenance projects.

[0031] The encoding rules for this globally unique identifier can be formally expressed as: (3) Formula (3) defines a globally unique identifier for symbols in the SPG, ensuring that the same logical symbol in different compilation units can be correctly merged, avoiding duplicate or misplaced references. Where: For program symbol nodes, This is a relative path to the source file. For the scope chain, The symbol name (mangling is used to eliminate overloading ambiguity).

[0032] Furthermore, the symbol propagation graph is constructed in the following way: based on a single definition rule, the symbol nodes corresponding to the same logical symbol appearing across compilation units are deduplicated and relinked to merge the propagation relationship edges in different compilation units.

[0033] Specifically, in languages ​​that support separate compilation, such as C++, the same header file may be included by multiple source files, causing the same function declaration or class definition to appear repeatedly in the abstract syntax trees of multiple compilation units. If these repeated symbols are directly stored as independent nodes in the graph, it will lead to graph bloat and broken dependencies.

[0034] Therefore, this application introduces a single definition rule as the theoretical basis for merging symbols across compilation units. During the graph construction stage, all candidate nodes are compared globally. When multiple nodes are detected to have the same globally unique identifier, they are regarded as different instances of the same logical symbol, and a deduplication operation is performed to retain only one canonical node. At the same time, the propagation relationship edges scattered in each compilation unit are relinked to the canonical node.

[0035] This mechanism ensures that regardless of how many files a symbol is referenced or defined in, it always corresponds to a unique vertex in the symbol propagation graph, where all related calls, data flows, and other relationships converge. This not only significantly compresses the graph's storage space but, more importantly, achieves project-wide dependency connectivity. This allows traversal starting from a source file to seamlessly cross compilation unit boundaries and trace the actual dependency targets located in other modules, laying a complete and consistent data foundation for subsequent bidirectional traversal and context extraction.

[0036] Step S130: Based on the current editing position and input prompts, determine the starting node and target node in the symbol propagation graph.

[0037] Specifically, this step is a crucial step in mapping the user's real-time editing behavior and natural language intent to a graph space. The current editing position typically corresponds to the code region where the user's cursor is located in the integrated development environment. The system parses this into a specific symbol node in the symbolic propagation graph as the starting node, such as the function body or class member where the cursor is located.

[0038] Input prompts are natural language descriptions or completion requests provided by the user. The system extracts semantic features from these prompts and retrieves matching candidate nodes in the graph as target nodes. These target nodes represent the user's intended function to modify or reference. In this way, the originally vague user intent is transformed into clear start and end constraints in the graph. This makes subsequent contextual searches no longer blind global scans, but rather a pathfinding task with clear direction, thus significantly improving the targeting of context extraction.

[0039] Specifically, such as Figure 2 The diagram shown is a flowchart illustrating a method for determining target nodes based on a relevance score calculation formula, as provided in an embodiment of this application. The method includes: Step S210: Determine the function body corresponding to the current editing position as the starting node.

[0040] The current editing position refers to the location of the cursor in the source code within the integrated development environment (IDE). This position uniquely points to the code area being written or modified. By parsing the abstract syntax tree of the current source file, the smallest function scope containing this editing position is located, and the function body is determined as the starting node.

[0041] This function body serves as the logical starting point for subsequent semantic path tracing, representing the execution context in which the current editing operation takes place. Taking the `void HttpServer::handleRequest(Request&req)` function in the `src / network / server.cpp` file as an example, the system uses the symbol node corresponding to this function body as the starting node. This node contains all the function's local variables, parameters, and call information, ensuring that subsequent graph traversal is based on the actual code execution state.

[0042] Step S230: Extract the keyword set from the input prompts, and retrieve the matching candidate node set in the symbol propagation graph based on the preset mapping relationship between keywords and symbol types.

[0043] First, the input prompts are segmented and stop words are removed to extract a set of keywords that represent the user's intent. A pre-built semantic lookup table establishes the mapping between keywords and symbol types, creating associations between natural language vocabulary and code symbols such as class names, function names, and method names.

[0044] The process of forming this mapping relationship can be as follows: during the system initialization phase, collect all symbol names and their corresponding comment documents in the project code library, and build an inverted index table and store it as a key-value pair structure by statistically analyzing the co-occurrence frequency of natural language verbs such as parse, validate, and serialize with specific symbol types such as Parser class, Validator function, and toJSON method.

[0045] This mapping relationship is used to map the keyword set to the corresponding symbol type in the symbol propagation graph. Then, matching nodes are searched in the global symbol nodes to form a candidate node set. This candidate node set contains all potential targets that may be semantically related to user intent, providing a foundation for subsequent precise filtering.

[0046] Specifically, this step achieves a quantized mapping from fuzzy natural language intent to precise graph nodes. Let K be the set of keywords extracted from the input prompts, and M be the mapping function from keywords to the symbol set, then the candidate node set is: (4) This operation means merging the set of symbols corresponding to each keyword in the prompt to obtain a set of all candidate nodes that may be related to the current task.

[0047] Step S250: Calculate the number of shortest path edges from the starting node to each candidate node in the candidate node set, and calculate the relevance score based on the number of shortest path edges.

[0048] After determining the set of candidate nodes, the closeness between each candidate node and the starting node is quantified. The shortest path edge count can refer to the minimum number of propagation relationship edges required to reach a candidate node from the starting node in the symbol propagation graph. This value reflects the distance between symbols in the code logic structure.

[0049] Based on this, the formula for calculating the relevance score is: (5) Formula (5) is used to calculate the relevance score of candidate functional intent nodes in the symbol propagation graph to support distance-weighted sorting and filtering.

[0050] In the formula, Candidate nodes The relevance score, Starting node to candidate node The number of edges in the shortest path. , This is a preset smoothing constant.

[0051] Among them, the preset smoothing constant To prevent the denominator from being zero, its value can be set to 0.1 or other extremely small positive numbers. The calculation process of the above relevance score can be formalized as the following decision function: by calculating the number of shortest path edges from the starting node to each candidate node, and using its reciprocal as the scoring criterion, the closer the distance, i.e., the fewer the edges, the higher the score.

[0052] This formula embodies the design principle that closer proximity equates to stronger relevance, allowing semantically tightly coupled code modules to receive higher recommendation weights. The edges in the symbolic propagation graph record relationships such as calls, data flows, and parameter passing. The shortest path calculated based on the graph structure accurately reflects the actual dependency depth between code segments, thus achieving a more precise relevance assessment than text matching.

[0053] Step S270: Select the preset number of candidate nodes with the highest relevance scores as target nodes.

[0054] Based on the relevance scores calculated in the above steps, all nodes in the candidate node set are sorted in descending order. The preset number can refer to the upper limit of the target nodes set by the system, i.e., the Top-K value. This value can be set to 5 or 10, etc., depending on the context window size or performance requirements of the AI ​​model. The top preset number of candidate nodes are selected from the sorted list as the final target nodes. These target nodes will be used in the subsequent bidirectional graph traversal process as the endpoints for semantic path tracing.

[0055] This distance-weighted scoring filtering mechanism can quickly identify the core functional modules most relevant to the current editing task from a massive amount of bullet points, effectively filtering out noisy nodes with large semantic distances, and ensuring that the extracted code context is both concise and highly semantically relevant.

[0056] Step S150: Using the starting node and the target node as endpoints, perform a bidirectional graph traversal in the symbolic propagation graph to determine the semantically reachable path connecting the starting node and the target node.

[0057] Specifically, bidirectional graph traversal is a deterministic path search mechanism that connects the starting point of editing with the endpoint of intent. Unlike traditional unidirectional search, this mechanism simultaneously explores the downstream influence range forward along the propagation relationship edges from the starting node, and traces the upstream dependency source backward from the target node. The intersection of the two constitutes the semantically reachable path.

[0058] Each intermediate node on this path is both influenced by the starting node and a necessary dependency for reaching the target node, thus logically forming an indispensable context chain for the current editing task. This graph traversal-based judgment method theoretically guarantees the semantic connectivity and necessity of the extracted content, effectively eliminating code segments that are adjacent in text but logically unrelated, and solving the problem of excessive context noise in existing technologies.

[0059] Specifically, such as Figure 3 The diagram shown is a flowchart illustrating a method for determining semantically reachable paths and performing pruning operations based on bidirectional graph traversal, as provided in an embodiment of this application. The method includes: Step S310: Starting from the initial node, extend forward along the propagation relationship edge to explore the downstream influence path.

[0060] The starting node typically corresponds to the function or code block where the user is currently editing. Downstream impact paths refer to the set of paths in the symbolic propagation graph that originate from the starting node and can be directly or indirectly reached from other symbolic nodes based on the direction of data flow or the order of control flow execution. This process simulates the forward progression logic of program execution, that is, identifying which subsequent functions will be activated, which variables will be modified, or which outputs will be generated by the execution of the current code segment.

[0061] By querying the list of outgoing edges from the starting node in the symbol propagation graph, an iterative approach using either breadth-first search or depth-first search strategies is employed. Each new node visited indicates that the current editing content may influence the symbol represented by that node or that a call relationship exists. If the starting node is a function that processes a request, its downstream impact path will encompass utility functions called within that function, database objects written to, and exception types thrown. Constructing the downstream impact path comprehensively covers the radiating scope of the current editing action within the project, laying a directional foundation for subsequently identifying truly relevant contexts.

[0062] Specifically, each node maintains a list of outgoing edges as follows: (6) Formula (6) is used to construct the forward adjacency list structure of nodes in the Symbolic Propagation Graph (SPG) to support efficient forward graph traversal.

[0063] In the formula, The unique identifier for the current symbol node. Indicates from node The set of all forward propagation paths that originate from this point. To and Successor symbol nodes that have a direct propagation relationship, For connection and The relationship type belongs to one of the following: call, data stream, binding, return, or type implementation. The edges are accompanied by metadata, including the source file path, AST node location, whether it is an indirect call, and whether the data stream has been dereferenced by pointers. Let be the set of all labeled directed edges in the graph.

[0064] Step S330: Starting from the target node, trace back along the propagation relationship edge to explore the upstream dependency path.

[0065] A target node can refer to a functional intent node parsed from user input prompts. For example, when a user mentions in a comment that they need to call the serialization function, the target node is the corresponding serialization class or method node. An upstream dependency path can refer to the set of paths in the symbolic propagation graph that trace back from the target node, against the direction of the propagation relationship edges—that is, from the callee to the caller, or from the written variable to the read variable—tracing its input source, dependencies, and initialization process.

[0066] This process simulates the reverse reasoning logic of the prerequisites or supporting components required to achieve the target function. It recursively searches for its dependency chain by traversing the list of incoming edges in the symbolic propagation graph that terminate at the target node. For the JSON serialization method of the target node, its upstream dependency path may include the method's parameter object, the class definition of the parameter object, and the call stack that passed the parameter. Exploring the upstream dependency path can pinpoint the key logic branches supporting the implementation of the target function, thereby accurately locating indispensable dependency sources within a large codebase.

[0067] To support reverse tracing operations, an inverted index is also created: (7) Formula (7) is used to construct the reverse index in the symbolic propagation graph SPG to maintain pointers to nodes. It supports efficient reverse tracing operations for all reverse dependency sources.

[0068] In the formula: For the current symbol node, Let be the set of reverse edges pointing to this node. For the predecessor symbol node, For relation types, The accompanying metadata for the edges, Let be the set of all labeled directed edges in the graph.

[0069] By maintaining the node All forward propagation paths originating from and pointing to nodes All reverse dependencies are the core data organization method for bidirectional graph traversal, supporting efficient forward exploration and backward traversal operations.

[0070] Step S350: Determine the semantically reachable path based on the intersection of the downstream influence path and the upstream dependency path.

[0071] A semantically reachable path can be defined as a continuous sequence of symbols that is both reachable from the current editing position and essential to the target functional intent. The core of determining this path lies in calculating the overlapping portion of the path sets obtained from the two steps mentioned above; that is, finding those symbol nodes and their connecting edges that are both affected by the current editing and contribute to the target intent.

[0072] This determination process can be formalized as the following set operation: Let To start from the node Start by traversing the set of nodes reachable in a forward direction. To start from the target node Starting from the set of nodes reachable by tracing backwards, the set of semantically reachable symbols is obtained. The intersection of the two .

[0073] All nodes belonging to this set and the connected subgraphs they form in the graph constitute the final semantically reachable path. This intersection-based filtering mechanism can effectively exclude side nodes that are affected by the current edit but are irrelevant to the target intent, as well as static code that is dependent on the target intent but has not been triggered by the current edit, thereby extracting a minimal and highly focused code context.

[0074] Step S370: Perform pruning operations during the traversal. Pruning operations include ignoring the internal paths of preset boundary nodes and limiting the maximum expansion depth of loop call paths.

[0075] To prevent performance issues caused by an excessively large search space during bidirectional graph traversal, and to avoid introducing a large amount of external code unrelated to the current task, the system performs pruning operations during the traversal.

[0076] For predefined boundary nodes, these include external symbols such as standard library functions, third-party software development kit interfaces, and system application programming interfaces. The internal implementation of such nodes does not provide information gain for project-level context understanding, and traversing their interiors in depth would lead to an exponential expansion of the graph search space. Therefore, the system marks these nodes as boundary nodes and stops expanding into their interiors when traversing to such nodes, only recording the mapping relationship of the boundary node referenced by the current path, without expanding other symbols involved in its internal implementation.

[0077] For propagation paths that cross header file boundaries, if the header file traversed by the current propagation path is not within the current project's working directory, the propagation of that branch is interrupted. This pruning rule ensures that the context extraction scope is always constrained to the source code currently accessible to the developer, avoiding the introduction of uneditable code segments from system header files or external dependency libraries.

[0078] For circular calls or circular dependencies in the propagation path, the system sets a maximum expansion depth threshold for each propagation path, with a default value of 5 levels. When the search depth of a path reaches this threshold, the extension of that branch is forcibly stopped regardless of whether there are any subsequent propagation relationships. This threshold can be preset based on the code size and call depth distribution of the target project or configured by the user.

[0079] It should be understood that although this embodiment uses a function call chain in C++ as an example, the bidirectional traversal, score calculation, and pruning mechanisms described above are also applicable to other programming languages ​​that support static analysis, such as Java, Go, and Rust, as long as they can construct a symbolic propagation graph containing the corresponding propagation relationships. Through the complete search algorithm system described above, the system can lock the code subgraph related to the current editing intent within a preset time threshold, providing a deterministic path basis for the subsequent construction of a simplified context.

[0080] Furthermore, intermediate symbol nodes on a semantically reachable path satisfy the semantic reachability condition, which is that the intermediate symbol node can be reached from the starting node and can also reach the target node. The judgment logic of the semantic reachability condition is: if there is a first path from the starting node to the intermediate symbol node and a second path from the intermediate symbol node to the target node, then the intermediate symbol node is determined to satisfy the semantic reachability condition, wherein both the first path and the second path are composed of propagation relationship edges.

[0081] Specifically, this dual constraint is a key criterion for ensuring the completeness of the contextual logic. In actual code completion scenarios, nodes reachable only from the starting point may be side-effect code that is called but unrelated to the current modification intention, while nodes reachable only from the end point may be globally common basic library functions that are disconnected from the current editing context. Only intermediate nodes that simultaneously satisfy bidirectional connectivity can truly serve as a bridge carrying the complete data flow or control transfer between the "current editing point" and the "expected functional point".

[0082] For example, in a C++ project, if the starting node is the HttpServer::handleRequest function and the target node is the RequestValidator::validate method, then the RequestParser::parse function, located between the two, is considered semantically reachable because it is called by handleRequest (i.e., the first path exists) and also called validate (i.e., the second path exists). However, another function in the same file, Logger::log, which is called by handleRequest but is unrelated to the validation logic, will be automatically excluded from the semantically reachable path because it cannot reach the target node.

[0083] The above logic for determining propagation reachability can be formally expressed as: (8) Formula (8) is used to determine whether there is a propagation path consisting of edges between any two symbol nodes in a symbolic propagation graph (SPG), and is the theoretical basis for judging the semantic relevance of context. In the formula, The starting symbol node, For the target symbol node, This indicates that a reachable path exists. This indicates that there is no reachable path. Indicates from arrive The path, Let represent a set of vectors consisting of n edges. This represents the starting node of path p. This indicates the end node of path p.

[0085] Based on the above reachability determination, the set of semantically reachable symbols is: (9) Formula (9) is used to determine the set of semantically reachable symbols, that is, to filter out intermediate symbols that can be reached from the current editing function and also lead to the functional intent node, as the context range that should be retained.

[0086] In the formula, For a set of semantically reachable symbols, The set of unique identifiers for all identifiable symbol nodes. This is the functional intent node, i.e., the endpoint of target propagation. For a set of functional intent nodes, This is the starting point of the current function. In the symbolic propagation graph, from node To the node Does a transmission path exist?

[0087] Only intermediate symbols that can be reached from the current function and also lead to a certain functional intent node are considered semantically reachable and belong to the context scope that should be preserved.

[0088] Step S170: Extract the corresponding code context based on the symbol nodes involved in the semantically reachable path.

[0089] Specifically, the code context is based on graph path extraction, rather than simple file concatenation or fixed window truncation. The system reverse-maps back to the original source code files based on all symbol nodes recorded on the semantically reachable paths, loading only the code snippets to which these symbols belong. During this process, further simplification operations can be performed, such as retaining necessary function signatures while removing irrelevant implementation details, or removing class definitions not referenced by the paths, thereby constructing a highly condensed, streamlined context.

[0090] Because the extraction scope is strictly limited to semantically reachable paths, the final generated code context contains all necessary dependency information while minimizing redundant content. This not only reduces the computational overhead and transmission latency of subsequent model inference but also indirectly improves the accuracy and interpretability of code generation or completion by increasing the signal-to-noise ratio of the input information.

[0091] Specifically, such as Figure 4 The diagram shown is a flowchart illustrating a method for constructing a simplified code context based on source file set loading and simplification operations, as provided in an embodiment of this application. The method includes: Step S410: Determine the set of source files to which the symbol nodes involved in the semantically reachable path belong.

[0092] After determining the semantically reachable path connecting the starting and target nodes, the abstract graph structure needs to be mapped back to the concrete physical code carrier. The system traverses all symbol nodes on the semantically reachable path, extracting the source file path information contained in each symbol node. This path information is stored in the form of a relative path to the source file in the symbol's unique identifier, such as src / network / server.cpp or include / utils / json_parser.h. All path information is collected and deduplication is performed to form a set containing all source files that carry the relevant symbol definitions or usages.

[0093] This collection of source files can be formally represented as: (10) In the formula, The set of source file paths to which semantically reachable symbols belong. To obtain symbols The mapping function for the relative path of the corresponding source file. It is a set of intermediate symbols that can be reached from the current function and also lead to a certain functional intent node. It is a minimal but complete collection of files that ensures that all code that has a substantial impact on the current task is overwritten, forming the scope boundary for subsequent code loading and simplification operations, and limiting the maximum range of context data from the perspective of physical storage.

[0094] Step S430: Load only the contents of the source files in the source file set, and trim other files not included in the source file set.

[0095] Based on the defined set of source files, the system performs precise file loading operations. According to the list of file paths in the source file set, it reads and loads only the complete source file content corresponding to those files from the storage medium. For the numerous other source files present in the project that are not included in the source file set, they are directly removed during this context extraction process and are not read or loaded.

[0096] Unlike existing technologies that load all files based on file directory structure or recent access records, this embodiment only loads files containing at least one semantically reachable symbol. This on-demand loading mechanism blocks the introduction of irrelevant module files at the source, avoiding the linear expansion of context size due to project growth, while significantly reducing input / output operations, completing the first round of noise filtering at the data source. The loaded source file content is temporarily stored in a memory buffer, preparing the data foundation for the next simplification operation.

[0097] Step S450: Perform a simplification operation on the loaded source file content. The simplification operation includes: deleting function bodies that are not semantically reachable while retaining function signatures, removing unreferenced class definitions, and retaining dependency import statements that maintain syntactic integrity, in order to construct a simplified code context.

[0098] For the source file content loaded into memory, the system performs a deep simplification operation to compress the code size to the maximum extent while preserving necessary semantic information. This simplification operation specifically includes the following three coordinated processing actions: First, for function-level code entities, identify and remove function bodies that are irrelevant to the semantically reachable path. Only functions whose internal logic participates in the propagation of the semantically reachable path are considered relevant. For functions that exist in the source file but whose internal logic is not substantially related to the current context extraction task, their function bodies are completely removed; at the same time, to maintain the structural integrity of the code and the definition of the external interface, the function signatures of these functions, including the return type, function name, and parameter list, are forcibly retained.

[0099] The underlying technical mechanism of this design is as follows: When generating code, the large language model needs to understand the available interfaces and type constraints within the current scope. Function signatures provide complete type information and calling contracts, which are sufficient to support the model's inference needs. However, if the specific implementation logic within the function body has no data flow or control flow relationship with the current editing intent, it is purely noise information, and retaining it would only dilute the signal-to-noise ratio of the input information. Through the processing strategy of "deleting the body and retaining the signature," the system compresses the context volume to the maximum extent while preserving the necessary interface contracts.

[0100] Second, for class definitions, remove unreferenced class definitions. The system analyzes the loaded source file content and checks whether each class definition is referenced or inherited in the semantically reachable path. If a class definition does not appear as a member variable type, nor is it used as a function parameter or return type, it is removed from the source file content, thereby eliminating invalid type declarations occupying the context window.

[0101] Third, to ensure the syntactic validity of the pruned code snippets, dependency import statements necessary for maintaining syntactic integrity are retained. Even after removing parts of function bodies and class definitions, certain header file import statements, such as the `#include` directive in C++ or the `import` statement in Java, remain crucial for the valid parsing of the remaining code. The system identifies and retains all dependency import statements necessary for maintaining syntactic integrity, preventing compilation errors or parsing interruptions due to missing type definitions.

[0102] After the above simplification process, the system assembles the processed source file content to generate the final simplified code context. This simplified code context physically represents a series of cropped text fragments, fully preserving the semantic dependency chains and syntactic structure information related to the current editing task.

[0103] It should be understood that all the above pruning actions are strictly performed according to semantically reachable paths, which is a deterministic pruning strategy based on program analysis results, completely different from heuristic rules based on line count limits, keyword density, or regular expression matching. Through this structure-aware simplification operation, this application can significantly compress the size of the input data while ensuring the semantic completeness of the context. In actual engineering verification, compared with traditional full-text splicing or simple truncation methods, the simplified code context constructed using this embodiment can typically be reduced to 10% to 30% of the original complete project context, and the corresponding number of tokens also decreases proportionally. This not only directly reduces network transmission bandwidth usage and server-side inference computational overhead, but more importantly, it improves the signal-to-noise ratio of the input information, enabling the model to focus its limited attention resources on truly relevant code logic, thereby obtaining accurate and interpretable code generation results without relying on the ability of an ultra-long context window.

[0104] It should be noted that although this embodiment uses the function body and class definition of C++ as an example, the above simplification operation is also applicable to other programming languages ​​that support static analysis, such as Java, Go, and Rust, as long as their syntax structure supports function signature preservation and class definition resolution.

[0105] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0106] Furthermore, this example embodiment also provides a code context extraction device.

[0107] Figure 5 A block diagram illustrating an exemplary embodiment of the code context extraction apparatus of this application is shown schematically. References Figure 5 The code context extraction device 500 according to an exemplary embodiment of this application may include: a graph acquisition module 510, a node determination module 530, a traversal module 550, and a context extraction module 570.

[0108] Specifically, the graph acquisition module 510 can be used to acquire a symbol propagation graph constructed based on the syntax and semantic analysis of the code. The symbol propagation graph includes multiple symbol nodes and propagation relationship edges representing the propagation relationship between symbols. The node determination module 530 can be used to determine the starting node and the target node in the symbol propagation graph based on the current editing position and input prompts. The traversal module 550 can be used to perform bidirectional graph traversal in the symbol propagation graph with the starting node and the target node as endpoints to determine the semantically reachable path connecting the starting node and the target node. The context extraction module 570 can be used to extract the corresponding code context based on the symbol nodes involved in the semantically reachable path.

[0109] Since the functional modules of the code context extraction device in this application are the same as those in the above method implementation, they will not be described again here.

[0110] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this application.

[0111] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0112] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0113] In an exemplary embodiment of this application, an electronic device capable of implementing the above-described method is also provided.

[0114] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: entirely in hardware, entirely in software (including firmware, microcode, etc.), or in a combination of hardware and software, collectively referred to herein as “circuit,” “module,” or “system.”

[0115] The following reference Figure 6 To describe an electronic device 600 according to this embodiment of the present invention. Figure 6 The electronic device 600 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0116] like Figure 6 As shown, the electronic device 600 is manifested in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), and a display unit 640.

[0117] The storage unit 620 stores program code that can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform the method steps shown in the figure, etc.

[0118] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0119] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0120] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0121] Electronic device 600 can also communicate with one or more external devices 670 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. As shown, network adapter 660 communicates with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0122] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this application.

[0123] In exemplary embodiments of this application, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the present invention can also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0124] The program product for implementing the above-described method according to embodiments of the present invention can employ a portable compact disc read-only memory (CD-ROM) and include program code, and can run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0125] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0126] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0127] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0128] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0129] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0130] Other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0131] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for extracting code context, characterized in that, The method includes: Obtain a symbol propagation graph constructed based on code syntax and semantic analysis, wherein the symbol propagation graph includes multiple symbol nodes and propagation relationship edges representing the propagation relationships between symbols; Based on the current editing position and input prompts, the starting node and target node are determined in the symbol propagation graph; Using the starting node and the target node as endpoints, a bidirectional graph traversal is performed in the symbol propagation graph to determine the semantically reachable path connecting the starting node and the target node; Based on the symbol nodes involved in the semantically reachable path, the corresponding code context is extracted.

2. The method according to claim 1, characterized in that, The propagation relationship edge includes at least one of the following: Call relationship edges, data flow relationship edges, parameter binding relationship edges, return relationship edges, and type implementation relationship edges.

3. The method according to claim 1, characterized in that, The symbol nodes are identified by a globally unique identifier. The encoding rule of the globally unique identifier is to concatenate the source file relative path, scope chain, and symbol name through a preset separator. The symbol name is processed by name reorganization to eliminate overload ambiguity. The symbol propagation graph is constructed in the following way: based on a single definition rule, the symbol nodes corresponding to the same logical symbol appearing across compilation units are deduplicated and relinked to merge the propagation relationship edges in different compilation units.

4. The method according to claim 1, characterized in that, The process of determining the starting node and target node in the symbol propagation graph based on the current editing position and input prompts includes: The function body corresponding to the current editing position is determined as the starting node; Extract a set of keywords from the input prompts, and based on the preset mapping relationship between keywords and symbol types, retrieve a set of matching candidate nodes from the symbol propagation graph; Calculate the number of shortest path edges from the starting node to each candidate node in the candidate node set, and calculate a relevance score based on the number of shortest path edges. The formula for calculating the relevance score is as follows: in, Candidate nodes The relevance score, The starting node to candidate node The number of edges in the shortest path. This is a preset smoothing constant; Select the preset number of candidate nodes with the highest relevance scores as the target nodes.

5. The method according to claim 1, characterized in that, The step of performing a bidirectional graph traversal in the symbol propagation graph to determine the semantically reachable path connecting the starting node and the target node includes: Starting from the initial node, extend forward along the propagation relationship edge to explore the downstream influence path; Starting from the target node, trace back along the propagation relationship edge to explore the upstream dependency path; The semantically reachable path is determined based on the intersection of the downstream influence path and the upstream dependency path; Pruning operations are performed during the traversal, including ignoring the internal paths of preset boundary nodes and limiting the maximum expansion depth of loop call paths.

6. The method according to claim 1, characterized in that, The intermediate symbol nodes on the semantically reachable path satisfy the semantic reachability condition, which is: The intermediate symbol node can be reached from the starting node and also leads to the target node; The semantic reachability condition determination logic is as follows: if there exists a first path from the starting node to the intermediate symbol node and a second path from the intermediate symbol node to the target node, then the intermediate symbol node is determined to satisfy the semantic reachability condition, wherein the first path and the second path are both composed of the propagation relationship edges.

7. The method according to claim 1, characterized in that, The step of extracting the corresponding code context based on the symbol nodes involved in the semantically reachable path includes: Determine the set of source files to which the symbol nodes involved in the semantically reachable path belong; Load only the content of source files in the source file set, and trim other files not included in the source file set; The loaded source file content is subjected to a simplification operation, which includes: deleting function bodies that are not related to the semantically reachable path while retaining function signatures, removing unreferenced class definitions, and retaining dependency import statements that maintain syntactic integrity, in order to construct a simplified code context.

8. A code context extraction device, characterized in that, The device includes: The graph acquisition module is used to acquire a symbol propagation graph constructed based on the syntax and semantic analysis of the code. The symbol propagation graph includes multiple symbol nodes and propagation relationship edges representing the propagation relationship between symbols. The node determination module is used to determine the starting node and the target node in the symbol propagation graph based on the current editing position and input prompts. The traversal module is used to perform bidirectional graph traversal in the symbol propagation graph with the starting node and the target node as endpoints, and to determine the semantically reachable path connecting the starting node and the target node; The context extraction module is used to extract the corresponding code context based on the symbol nodes involved in the semantically reachable path.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the code context extraction method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: processor; A memory for storing one or more programs, which, when executed by the processor, cause the processor to implement the code context extraction method as described in any one of claims 1 to 7.

Images