Determining method and device of destructive change, computing equipment and storage medium

Abstract

The invention provides a destructive change determination method and device, computing equipment and a storage medium. The destructive change determination method comprises the steps of determining a first application program interface and a second application program interface which have function changes; determining a first calling position and a first context according to the first application program interface; the first calling position refers to a position for calling the first application program interface in the user program; the first context refers to the context of the first calling part; determining a second calling position and a second context according to the second application program interface; respectively performing program analysis on the first context and the second context, and judging whether the behavior of the first application program interface at the first calling position and the behavior of the second application program interface at the second calling position are equivalent or not; if yes, determining that the first application program interface and the second application program interface do not have destructive changes; according to the scheme, the false alarm rate of destructive change of the version dependency library can be reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, apparatus, computing device, and storage medium for determining destructive changes. Background Art

[0002] In software project management, dependent library versions often need to change. However, different versions of dependent libraries may have functionality changes that may be incompatible with the currently used version. Therefore, project maintainers need to modify the application programming interfaces (APIs) of the dependent libraries to address these breaking changes. To mitigate the impact of breaking changes between versions on the project code, project managers and codebase maintainers mark the specific versions of the project's dependent libraries. The versions of the libraries that depend on different versions of the project may vary.

[0003] Existing library management software often encounters dependency version conflicts. For example, a project depends on both version 1.0 of library A and version 2.0 of library B, and version 1.0 of library A depends on version 1.0 of library B. Therefore, project managers need to adjust the calls to the API of library B in the project and re-implement the corresponding business logic using version 1.0 of library B. This process requires additional engineering costs and may introduce new bugs due to code modifications. Project managers can also try to find a suitable version of library B so that the API functions called by this project are the same as version 2.0, and the API functions called by library A are the same as version 1.0. However, this requires reviewing each version of library B and comparing their corresponding APIs one by one to ensure that they have the same functions, which is also tedious and prone to errors.

[0004] One approach to resolving dependency version conflicts automatically is to detect whether different versions of the dependency library code have breaking changes compared to the baseline version, thereby identifying the dependency library version that is compatible with the project. For example, if version 1.0 of library A depends on version 1.0 of library B, and there are no breaking changes between version 1.0 and version 1.3 of library B, then version 1.0 of library A is also compatible with version 1.3 of library B.

[0005] There are two main approaches to detecting breaking changes. One involves regression testing the project's code. If different versions of the same library produce different test results, the change is considered a breaking change. The other involves program analysis of different versions of the library code, using results such as symbolic execution to determine whether the two versions are equivalent.

[0006] Existing solutions for detecting destructive changes have a high false positive rate and will report errors for some changes that do not affect actual calls.

[0007] So, how to reduce the false positive rate of destructive changes in version-dependent libraries remains to be solved. Summary of the Invention

[0008] The present application provides a method, apparatus, computing device, and storage medium for determining destructive changes, which can reduce the false positive rate of destructive changes in version-dependent libraries.

[0009] In a first aspect, an embodiment of the present application provides a method for determining destructive changes, which can be executed by a destructive change determination device, which can be a terminal device or a module for a terminal device, or a server or a module for a server. This application does not limit the execution subject of the method. The method includes: determining a first application program interface (API) and a second application program interface (API) with functional changes; the first application program interface and the second application program interface (API) belong to the same application program interface corresponding to different versions of the same dependency library; according to the first application program interface, determining a first call point and a first context; the first call point refers to the location in the user program where the first application program interface is called; the first context refers to the context of the first call point; according to the second application program interface, determining a second call point and a second context; the second call point refers to the location in the user program where the second application program interface is called; the second context refers to the context of the second call point; performing program analysis on the first context and the second context respectively to determine whether the behavior of the first application program interface at the first call point and the behavior of the second application program interface at the second call point are equivalent; if equivalent, determining that there is no destructive change between the first application program interface and the second application program interface.

[0010] The above solution, combined with the context of calling the application program interface, can more accurately determine the compatibility of the dependent library version, thereby reducing the false positive rate of destructive changes in the version of the dependent library.

[0011] In one possible implementation method, program analysis is performed on the first context and the second context respectively to extract characteristic information of parameter instances passed into the first application interface and the second application interface; a first execution result of the first application interface is determined based on the characteristic information of the parameter instance passed into the first application interface; a second execution result of the second application interface is determined based on the characteristic information of the parameter instance passed into the second application interface; and based on the first execution result and the second execution result, it is determined whether the behavior of the first application interface at the first call and the behavior of the second application interface at the second call are equivalent.

[0012] The above scheme, on the one hand, performs program analysis on the context, can accurately extract the characteristic information of the parameter instances passed into the application interface, obtain accurate execution results, and then accurately judge the compatibility of the dependent library version based on the execution results, thereby reducing the false alarm rate of destructive changes in the version dependent library; on the other hand, based on the characteristic information of the parameter instances passed into the application interface, it can filter out destructive changes that do not affect the execution results, so that while ensuring the correctness of the execution results, more compatible dependent library versions can be found, thereby improving the success rate of resolving version conflict problems.

[0013] In a possible implementation method, the characteristic information of the parameter instance includes: whether the value of the parameter instance is a null value, and / or the specific type of the parameter instance.

[0014] The above solution can accurately filter out destructive changes that do not affect the execution results. This allows us to find more compatible versions of dependent libraries while ensuring the correctness of the execution results, thereby improving the success rate of resolving version conflict issues.

[0015] In one possible implementation method, the implementation code of the first application interface is symbolically executed based on the characteristic information of the parameter instance passed into the first application interface to obtain the first symbolic result of the first application interface; the first symbolic result is substituted into the first context to obtain the first execution result of the first application interface.

[0016] In the above solution, symbolic execution can improve the coverage of code testing, generate accurate test inputs for each independent execution path, and automatically identify execution paths affected by code changes, thereby enabling accurate and efficient execution results of different application interfaces.

[0017] In one possible implementation method, the functional change includes one or more of the following: different number of overloads, different number of parameters, different parameter types, different return value types, and different implementation codes.

[0018] The above solution can accurately and effectively determine whether different application program interfaces have functional changes.

[0019] In a possible implementation method, whether the implementation codes of the first application program interface and the second application program interface are the same is determined through an abstract syntax tree.

[0020] The above solution can accurately and effectively determine whether the implementation codes of the first application program interface and the second application program interface are the same.

[0021] In one possible implementation method, if there is a functional change between the application interface on which the first application interface depends and the application interface on which the second application interface depends, then there is a functional change between the first application interface and the second application interface.

[0022] The above solution can accurately and effectively determine whether different application program interfaces have functional changes.

[0023] In the second aspect, an embodiment of the present application provides a device for determining destructive changes, including: a determination unit and a judgment unit; the determination unit is used to determine a first application program interface and a second application program interface with functional changes; the first application program interface and the second application program interface belong to the same application program interface corresponding to different versions of the same dependent library; based on the first application program interface, a first call point and a first context are determined; the first call point refers to the location where the first application program interface is called in the user program; the first context refers to the context of the first call point; based on the second application program interface, a second call point and a second context are determined; the second call point refers to the location where the second application program interface is called in the user program; the second context refers to the context of the second call point; the judgment unit is used to perform program analysis on the first context and the second context respectively, and determine whether the behavior of the first application program interface at the first call point and the behavior of the second application program interface at the second call point are equivalent; if they are equivalent, it is determined that there is no destructive change between the first application program interface and the second application program interface.

[0024] In one possible implementation method, the judgment unit is used to perform program analysis on the first context and the second context respectively, extract characteristic information of parameter instances passed into the first application interface and the second application interface; determine a first execution result of the first application interface based on the characteristic information of the parameter instance passed into the first application interface; determine a second execution result of the second application interface based on the characteristic information of the parameter instance passed into the second application interface; and judge whether the behavior of the first application interface at the first call and the behavior of the second application interface at the second call are equivalent based on the first execution result and the second execution result.

[0025] In a possible implementation method, the characteristic information of the parameter instance includes: whether the value of the parameter instance is a null value, and / or the specific type of the parameter instance.

[0026] In one possible implementation method, the judgment unit is used to perform symbolic execution on the implementation code of the first application interface based on the characteristic information of the parameter instance passed into the first application interface to obtain the first symbolic result of the first application interface; and substitute the first symbolic result into the first context to obtain the first execution result of the first application interface.

[0027] In one possible implementation method, the functional change includes one or more of the following: different number of overloads, different number of parameters, different parameter types, different return value types, and different implementation codes.

[0028] In a possible implementation method, the determining unit is configured to determine, through an abstract syntax tree, whether the implementation codes of the first application program interface and the second application program interface are the same.

[0029] In a possible implementation method, the determining unit is configured to determine that if there is a functional change between the application program interface on which the first application program interface depends and the application program interface on which the second application program interface depends, then there is a functional change between the first application program interface and the second application program interface.

[0030] In a third aspect, an embodiment of the present application further provides a computing device, including:

[0031] a memory for storing program instructions;

[0032] The processor is configured to call the program instructions stored in the memory and execute any method for implementing the first aspect according to the obtained program instructions.

[0033] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, in which computer-readable instructions are stored. When a computer reads and executes the computer-readable instructions, any method of the above-mentioned first aspect is implemented.

[0034] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising a computer program executable by a computer device, wherein when the program is run on the computer device, the computer device executes any method for implementing the above-mentioned first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 A flowchart of a method for determining a destructive change provided in an embodiment of the present application;

[0036] Figure 2 A code diagram of a dependency library provided in an embodiment of the present application;

[0037] Figure 3A code diagram of a dependency library provided in an embodiment of the present application;

[0038] Figure 4 A schematic diagram of a user program code provided in an embodiment of the present application;

[0039] Figure 5 A flowchart of a method for determining a destructive change provided in an embodiment of the present application;

[0040] Figure 6 A schematic diagram of the structure of a device for determining destructive changes provided in an embodiment of the present application;

[0041] Figure 7 A schematic diagram of the structure of a device for determining destructive changes provided in an embodiment of the present application. DETAILED DESCRIPTION

[0042] Figure 1 This is a flowchart of a method for determining destructive changes provided in an embodiment of the present application. This method can be performed by a destructive change determination device, which can be a terminal device or a module for a terminal device, or a server or a module for a server. This application does not limit the execution entity of this method.

[0043] The method comprises the following steps:

[0044] Step 101: Determine a first application programming interface and a second application programming interface with functional changes.

[0045] The first application program interface and the second application program interface are the same application program interface corresponding to different versions of the same dependent library.

[0046] An Application Programming Interface (API) is a computing interface that defines the interaction protocol between multiple software or software components.

[0047] The first application interface and the second application interface belong to the same application interface corresponding to different versions of the same dependent library. For example, there is a dependent library A, and the dependent library includes different versions, such as version 1.0, version 2.0 and version 3.0. The application interface is interface 1, then the first application interface refers to interface 1 in version 1.0 of dependent library A, the second application interface refers to interface 1 in version 2.0 of dependent library A, and the third application interface refers to interface 1 in version 3.0 of dependent library A.

[0048] An API functionality change refers to a change in its functionality, response mode, or operating method after an API update or upgrade. This change may affect the normal operation of applications that rely on the API. Functional changes include one or more of the following: a different number of overloads, a different number of parameters, a different parameter type, a different return value type, or a different implementation code.

[0049] Among them, functional changes may also include one or more of the following: response format changes: the structure or field name of the API return data changes; parameter requirement changes: certain parameters become required or optional, or the parameter value range changes; error handling changes: the error code or error message format changes; performance characteristics changes: API response time or throughput changes; functional logic changes: the business logic behind the API changes.

[0050] Step 102: Determine a first call location and a first context according to the first application program interface.

[0051] The first calling location refers to the location in the user program where the first application program interface is called; and the first context refers to the context of the first calling location.

[0052] The API call point refers to the location in the application code where the API request is actually initiated and the response is processed. These call points are the key points where the application interacts with external services or internal modules. The program context refers to the relevant information and state in the current execution environment, which determines the behavior and results of the system or code. The context can be explicit (directly passed parameters) or implicit (environment variables, global state, etc.). Figure 2 、 Figure 3 and Figure 4 As shown, Figure 2 The open interface and Figure 3 The open interfaces in the code are two application interfaces with functional changes. Figure 2 The open interface in is the first API, Figure 3 The open interface in is the second API; Figure 4 The in represents the calling location and context of the first application program interface and the second application program interface, which will be described in detail later and will not be repeated here.

[0053] Step 103: Determine a second calling location and a second context according to the second application program interface.

[0054] The second calling location refers to the location in the user program where the second application program interface is called; and the second context refers to the context of the second calling location.

[0055] Optionally, the first calling location and the second calling location are the same, which is not limited in this application.

[0056] Optionally, the first context and the second context are the same, which is not limited in this application.

[0057] Step 104 : Perform program analysis on the first context and the second context respectively to determine whether the behavior of the first application program interface at the first call location is equivalent to the behavior of the second application program interface at the second call location.

[0058] Step 105: If they are equivalent, determine that there is no destructive change between the first application program interface and the second application program interface.

[0059] Optionally, if the behaviors of the first application interface and the second application interface at the corresponding call locations are equivalent, it is determined that there are no destructive changes between the first application interface and the second application interface; if the behaviors of the first application interface and the second application interface at the corresponding call locations are not equivalent, it is determined that there are destructive changes between the first application interface and the second application interface.

[0060] API behavioral equivalence means that two or more APIs have the same functional performance, even though their implementation methods, interface designs, or internal structures may be different.

[0061] Optionally, the behavioral equivalence of the APIs is reflected in one or more of the following aspects: input-output consistency: for the same input, behaviorally equivalent APIs will produce the same output or effect; the same side effects: in addition to the return value, the changes to the system state are also the same; consistent error handling: the handling of abnormal situations is the same.

[0062] The above solution, combined with the context of calling the application program interface, can more accurately determine the compatibility of the dependent library version, thereby reducing the false positive rate of destructive changes in the version of the dependent library.

[0063] In one possible implementation method, in step 101, determining whether the first and second application programming interfaces (APIs) have undergone functional changes includes: obtaining the first and second application programming interfaces (APIs); and determining whether the first and second application programming interfaces (APIs) have one or more of the following changes: a different number of overloads, a different number of parameters, a different parameter type, a different return value type, or a different implementation code. If at least one of the above changes exists between the first and second application programming interfaces (APIs), it is determined that there has been a functional change between the first and second application programming interfaces (APIs); if none of the above changes exist between the first and second application programming interfaces (APIs), it is further determined whether there has been a functional change between the APIs on which the first and second application programming interfaces depend and the APIs on which the second and first application programming interfaces depend. If there has been a functional change between the APIs on which the first and second application programming interfaces depend, then there has been a functional change between the first and second application programming interfaces.

[0064] Optionally, the method for determining whether there is a functional change between the API on which the first API depends and the API on which the second API depends is the same as above and will not be repeated here.

[0065] Optionally, whether the implementation codes of the first application program interface and the second application program interface are the same is determined through an abstract syntax tree.

[0066] For example, S1.1, after the user specifies the two API library versions that need to be compared, the interface definition and implementation code of each API in the two versions are compared one by one. Specifically, first compare whether the number of overloads of the API interface is the same. If the number of overloads is the same, then compare whether the number of parameters, parameter types, and return value types in the corresponding overloaded interface definitions are the same. If the interface definitions are the same, then further recursively compare whether the abstract syntax trees AST of the function body codes implemented by the interface are the same. If the interface definition or implementation code of the library API is different between the two versions, it is considered that there is a functional change.

[0067] S1.2. For APIs whose interface definitions and implementation code have not been directly modified, analyze the implementation code to determine if other APIs directly or indirectly called by them may have had functional changes. Specifically, construct an API call graph based on all API implementation code calls to other APIs. If a downstream API called by an API includes an API with functional changes identified in the above steps, that API is also considered to have had functional changes.

[0068] In a possible implementation method, the specific implementation method of the above step 104 is as follows: Figure 5 As shown, the method includes the following steps:

[0069] Step 501 : Perform program analysis on the first context and the second context respectively, and extract feature information of parameter instances passed into the first application program interface and the second application program interface.

[0070] The characteristic information of the parameter instance includes: whether the value of the parameter instance is a null value, and / or the specific type of the parameter instance.

[0071] Alternatively, null analysis can determine that a parameter instance must be null, must not be null, or both.

[0072] Optionally, the specific type of the parameter instance can be determined by using data flow analysis, which can statically infer the flow and changes of data during program execution. This application does not limit the specific method of data flow analysis.

[0073] Step 502: Determine a first execution result of the first application program interface based on characteristic information of the parameter instance passed into the first application program interface.

[0074] In one possible implementation method, the implementation code of the first application interface is symbolically executed based on the characteristic information of the parameter instance passed into the first application interface to obtain the first symbolic result of the first application interface; the first symbolic result is substituted into the first context to obtain the first execution result of the first application interface.

[0075] Symbolic execution is an important program analysis technique that simulates program execution by using symbolic values ​​instead of concrete values. This allows for systematic exploration of program execution paths and the discovery of potential errors. This application does not limit the specific algorithm used in symbolic execution.

[0076] Step 503: Determine a second execution result of the second application program interface based on the characteristic information of the parameter instance passed into the second application program interface.

[0077] In one possible implementation method, the implementation code of the second application interface is symbolically executed based on the characteristic information of the parameter instance passed into the second application interface to obtain the second symbolic result of the second application interface; the second symbolic result is substituted into the second context to obtain the second execution result of the second application interface.

[0078] Step 504: Determine, based on the first execution result and the second execution result, whether the behavior of the first application program interface at the first call location is equivalent to the behavior of the second application program interface at the second call location.

[0079] The above scheme, on the one hand, performs program analysis on the context, can accurately extract the characteristic information of the parameter instances passed into the application interface, obtain accurate execution results, and then accurately judge the compatibility of the dependent library version based on the execution results, thereby reducing the false alarm rate of destructive changes in the version dependent library; on the other hand, based on the characteristic information of the parameter instances passed into the application interface, it can filter out destructive changes that do not affect the execution results, so that while ensuring the correctness of the execution results, more compatible dependent library versions can be found, thereby improving the success rate of resolving version conflict problems.

[0080] Below Figure 2 、 Figure 3 and Figure 4 The above steps 101 to 105 and the above steps 501 to 504 are described in detail by taking an example.

[0081] in, Figure 2 and Figure 3 There are two versions of the FileSystem API library. Figure 2 Version A of the FileSystem API library. Figure 3 This is version B of the FileSystem API library. Both version A and version B include three APIs: FileSystem.File#read(), FileSystem.open(), and FileSystem.readFile(). The analysis results of these three APIs in this step are as follows:

[0082] FileSystem.File#read() has only one implementation in both versions. Its interface definition does not accept parameters and returns a String. The AST of its implementation code is also the same. Therefore, according to the steps in S1.1, it is not marked as an API with functional changes. According to the steps in S1.2, it is determined that this API does not call other APIs that may have functional changes. Figure 2 and Figure 3 There is no functional change in the FileSystem.File#read() interface.

[0083] The interface definition and implementation code of FileSystem.open() are different in the two versions. In version A, the API has only one implementation, which accepts a parameter of type Object and returns a File; in version B, the API is overloaded and has two implementations, which accept parameters of type String and Integer respectively, and return File's derived classes FileOpenedWithPath and FileOpenedWithFD. At the same time, there is a null value check in the implementation of version A. When the file value is null, the return result is also null, and the corresponding processing is performed within the implementation according to the specific type of the parameter. There is no relevant code in the implementation of version B. Therefore Figure 2 and Figure 3 There is a functionality change in the FileSystem.open() interface in .

[0084] FileSystem.readFile() has only one implementation in both versions. Its interface definition accepts a parameter of type String and returns a String. The AST of the implementation code is also the same. Therefore, according to the steps in S1.1, it is not marked as an API with functional changes. According to the steps in S1.2, the code is analyzed and it is found that it calls two APIs, FileSystem.open() and FileSystem.File#read(). Since the aforementioned FileSystem.open() is considered to have functional changes, Figure 2 and Figure 3 The FileSystem.readFile() interface in .

[0085] Therefore, for this example, the APIs with changed functionality are FileSystem.open() and FileSystem.readFile().

[0086] Optionally, after determining that there is an API with a changed function, the user program is traversed to check node by node whether the API with a changed function is called. If so, the location information of the call is recorded.

[0087] like Figure 4 In the user program shown, there are two calls to the API with a changed function, FileSystem.open(): FileSystem.open(Integer.valueOf(userInput)) on line 10 and FileSystem.open(userInput) on line 12.

[0088] Since fileContent = FileSyetem.open(Integer.valueOf(userInput)).read(), the open interface of the first application interface can be called, and the open interface of the second application interface can also be called, that is, the positions of the first call point and the second call point are the same. Then when fileContent = FileSyetem.open(Integer.valueOf(userInput)).read() belongs to the call point of the first application interface, it is called the first call point, and the context of the first call point is the first context; when fileContent = FileSyetem.open(Integer.valueOf(userInput)).read() belongs to the position which can also be the call point of the second application interface, it is called the second call point, and the context of the second call point is the second context.

[0089] Similarly, fileContent = FileSyetem.open(userInput).read() can call the open interface of the first application program interface or the open interface of the second application program interface. That is to say, the first call site and the second call site are at the same location. In order to distinguish it from the above, we put Figure 4 When line 12 in the code is used as the calling site for calling the first application program interface, it is called the third calling site, and the context corresponding to the third calling site is called the third context. Figure 4 When line 12 is used as the calling site for calling the second application program interface, it is called the fourth calling site, and the context corresponding to the fourth calling site is called the fourth context.

[0090] Optionally, the two APIs with changed functions may be called in the same user program, or in different user programs, and this application does not limit this.

[0091] Optionally, the context of the first and second call locations is analyzed to extract characteristic information of the parameter instance passed into the API from the user program context. Specifically, two types of static analysis—null value analysis and data flow analysis—are used to extract characteristic information: "whether the value of the parameter instance is null" and "the specific type of the parameter instance." Null value analysis can determine whether a parameter instance must be null, must not be null, or both; data flow analysis can determine the specific type of the parameter instance. The comprehensiveness and accuracy of the extracted information are crucial for refining the symbolic execution results and proving the equivalence of two different versions.

[0092] like Figure 4In the user program shown, the parameter instance of the call to FileSystem.open(Integer.valueOf(userInput) on line 10 is Integer.valueOf(userInput). According to null value analysis, the return value returned by the Integer.valueOf() function must not be null, so the parameter instance must not be null. According to data flow analysis, the return value type of the Integer.valueOf() function is Integer, so the specific type of the parameter instance in this call is Integer.

[0093] The parameter instance of the call to FileSystem.open(userInput) on line 12 of the user program is userInput. According to null value analysis, the value stored in the variable userInput on line 12 comes from the assignment userInput = getUserInput() on line 3. The return value of GetUserInput() may or may not be null. However, in the if statement on line 4, between the assignment on line 3 and the call on line 12, if userInput is null, execution will terminate on lines 5-6, preventing further API calls. If userInput is not null, execution will continue. In the subsequent if statement on line 9, the isNumber(userInput) condition is not related to whether userInput is null and is therefore not considered. Therefore, it can be inferred that the parameter instance userInput passed to FileSystem.open() must be non-null. According to data flow analysis, the value stored in the variable userInput on line 12 comes from the assignment userInput = getUserInput() on line 3. The return value type of GetUserInput() is String, so the specific type of the parameter instance in this call is String.

[0094] Optionally, based on the characteristic information of the parameter instance passed into the first application interface, the implementation code of the first application interface is symbolically executed to obtain a first symbolic result of the first application interface; the first symbolic result is substituted into the first context to obtain a first execution result of the first application interface; similarly, a second execution result of the second application interface can also be obtained. The first execution result accurately describes the behavior of the version A implementation code, and the second execution result accurately describes the behavior of the version B implementation code, which can effectively compare whether the library API calls of different versions are equivalent.

[0095] For the call to FileSystem.open(Integer.valueOf(userInput)) on line 10, Version A's implementation of the function FileSystem.open() has only one implementation (located on lines 12-28). In this example, assume that the parameter instance symbol for the parameter file is f. The symbolic execution process is as follows:

[0096] First, the if statement in line 13 is executed. According to the parameter instance determined by the context of the first call, the API parameter file must not be null, so the condition file == null must be false, and execution continues at line 16.

[0097] The if statement on line 16 executes. Based on the parameter instance determined by the context of the first call, the API parameter type is Integer. Because the Integer class and the String class don't derive or implement each other, an Integer object must not be an instance of the String class. Therefore, the condition file instanceof String must be false, and execution continues at line 20.

[0098] Execute the if statement on line 20. According to the parameter instance determined by the context of the first call, the API parameter type is Integer. Therefore, the judgment condition file instanceof Integer must be true, and execution continues at line 21.

[0099] The assignment statement in line 21 converts the value of file to the variable fileDescriptor. Since type conversion does not change the object, the value of fileDescriptor after the assignment is the same as file, f.

[0100] Continue to execute the if statement on line 22. Since the value of the variable fileDescriptor is f, the condition fileDescriptor<0 is equivalent to f<0. Since the existing analysis results cannot determine whether the condition is true, the condition is retained and the two branches are explored separately. When f<0 is true, the throw statement on line 23 is executed. At this time, the API throws the error newFileDescriptorError("Invalid filedescriptor") and the API call ends. When f<0 is false, that is, f>=0, the return statement on line 25 is executed. At this time, the API return value is new FileOpenedWithFD(fileDescriptor) and the API call ends. Since the return value of the function interface in version A is the base class File instead of the derived class FileOpenedWithFD, the actual return value is (File)new FileOpenedWithFD(f).

[0101] To summarize, the first symbolic result 1 is as follows: when f<0, the API will throw an error newFileDescriptorError("Invalid filedescriptor"); when f>=0, the API will return the result (File)new FileOpenedWithFD(f).

[0102] For the call to FileSystem.open(Integer.valueOf(userInput)) on line 10 of the user program, Version B's implementation code has two implementations of the FileSystem.open() function. Based on the context of the second call, the parameter instance is determined to be of type Integer. The implementation actually called is the one on lines 15-20 that accepts a parameter fileDescriptor of type Integer. In this example, assume the parameter instance symbol of the fileDescriptor parameter is f. The symbolic execution process is as follows:

[0103] Execute the if statement on line 16. Since the value of the parameter fileDescriptor is f, the condition fileDescriptor<0 is equivalent to f<0. Since the existing analysis results cannot determine whether the condition is true, retain the condition and explore the two branches separately. When f<0 is true, execute the throw statement on line 17. At this time, the API throws the error newFileDescriptorError("Invalid filedescriptor"), and the API call ends. When f<0 is false, that is, f>=0, execute the return statement on line 19. At this time, the API return value is new FileOpenedWithFD(fileDescriptor), that is, new FileOpenedWithFD(f), and the API call ends.

[0104] In summary, the second symbolic result 1 is as follows: when f<0, the API will throw an error newFileDescriptorError("Invalid filedescriptor"); when f>=0, the API will return the result newFileOpenedWithFD(f).

[0105] For the call to FileSystem.open(userInput) on line 12 of the user program, Version A's implementation code has only one implementation of the function FileSystem.open() (located on lines 12-28). In this example, assume that the parameter instance symbol for the parameter file is f. The symbolic execution process is as follows:

[0106] First, the if statement in line 13 is executed. According to the parameter instance determined by the context of the third call, the API parameter file must not be null, so the condition file == null must be false, and execution continues at line 16.

[0107] Execute the if statement on line 16. According to the parameter instance determined by the context of the third call, the API parameter type is String. Therefore, the condition file instanceof String must be true, and execution continues at line 17.

[0108] The assignment statement in line 17 converts the value of file to the variable filePath. Since type conversion does not change the object, the value of filePath after the assignment is the same as file, f.

[0109] Execution continues to the return statement on line 18. The API return value is now new FileOpenedWithPath(filePath), and the API call ends. Because the return value of the function interface in Version A is the base class File, not the derived class FileOpenedWithPath, the actual return value is (File)new FileOpenedWithPath(f).

[0110] To summarize, the first symbol result 2 is as follows: the API will return the result (File) new FileOpenedWithPath(f).

[0111] For the call to FileSystem.open(userInput) on line 12 of the user program, Version B's implementation code has two implementations of the FileSystem.open() function. Based on the parameter instance determined by the context of the fourth call, the parameter instance type is String. The implementation actually called is the one on lines 12-14 that accepts a parameter filePath of type String. In this example, assume the parameter instance symbol for the filePath parameter is f. The symbolic execution process is as follows:

[0112] Execute the return statement on line 13. The API return value is new FileOpenedWithPath(filePath), that is, new FileOpenedWithPath(f), and the API call ends.

[0113] To summarize, the second symbol result 2 is as follows: the API will return the result new FileOpenedWithPath(f).

[0114] Optionally, the different symbolic results are substituted into the expression containing the library API call for execution. If two different versions of the library API call produce the same result when substituted into the expression containing the call, then even if the symbolic execution results themselves differ, the two versions of the library API are considered equivalent at that point in the call and can be substituted for each other. Therefore, making decisions based on the expression containing the call result can further reduce the false negative rate of equivalent versions.

[0115] For the expression in line 10 of the user program, the return value of the library API call is used to call the .read() function. The first symbolic result 1 and the second symbolic result 1 are substituted and compared. The comparison process is as follows:

[0116] When f<0, both the first symbolic result 1 and the second symbolic result 1 will throw an error in the library API, and the errors thrown are both new FileDescriptorError("Invalid filedescriptor"), which are exactly the same.

[0117] When f>=0, the first symbolic result 1 is the return value (File)new FileOpenedWithFD(f). When its .read() function is called, since its type is File, the File#read() method is called, and the result of running the expression where the call is located is new FileOpenedWithFD(f).File#read(). The second symbolic result 1 is the return value newFileOpenedWithFD(f). When its .read() function is called, although its type is FileOpenedWithFD, the derived class does not override the read() method, so the File#read() method of the base class is actually called, and the result of running the expression where the call is located is also new FileOpenedWithFD(f).File#read(), which is the same as version A.

[0118] Since versions A and B produce the same results, throw the same error under the same conditions, and return the same result when calling the expression under the same conditions, the two versions of the API are considered equivalent at line 10 of the project code.

[0119] For the expression in line 12 of the user program, the return value of the library API call is used to call the .read() function. The first symbolic result 2 and the second symbolic result 2 are substituted and compared. The comparison process is as follows:

[0120] The first symbol result 2 is the return value (File)new FileOpenedWithPath(f). When its .read() function is called, since its type is File, the File#read() method is called, and the result of running the expression where the call is located is new FileOpenedWithPath(f).File#read(). The second symbol result 2 is the return value newFileOpenedWithPath(f). When its .read() function is called, although its type is FileOpenedWithPath, the derived class does not override the read() method, so the File#read() method of the base class is actually called, and the result of running the expression where the call is located is also new FileOpenedWithPath(f).File#read(), which is the same as version A.

[0121] Since versions A and B produce the same results, throw the same error under the same conditions, and return the same result when calling the expression under the same conditions, the two versions of the API are considered equivalent at line 12 of the project code.

[0122] Optionally, traverse all listed API calls with functional changes, and determine whether the two different implementation versions of the library are equivalent at each API call through the above method. If the two different implementation versions of the library are equivalent at all API calls, then the two versions are compatible for the project as a whole and can be replaced with each other, otherwise the two versions are considered incompatible for the project. At this time, replacing one version with another may cause the behavior of the project program to change, so they cannot be replaced with each other. When version incompatibility is found, it will also summarize in detail which library API calls may have behavioral changes to help developers quickly lock and adjust project code to adapt to the new library version.

[0123] After the above analysis, we can find that the implementation code behaviors of version A and version B are the same. Therefore, we can finally determine that version A and version B of the API library are compatible for this project and can replace each other.

[0124] Based on the same technical concept, Figure 6 The following is an exemplary diagram of a destructive change determination device 600 provided in an embodiment of the present application. Figure 6 As shown, it includes: a determination unit 601 and a judgment unit 602; the determination unit 601 is used to determine the first application interface and the second application interface with functional changes; the first application interface and the second application interface belong to the same application interface corresponding to different versions of the same dependent library; according to the first application interface, a first call point and a first context are determined; the first call point refers to the location where the first application interface is called in the user program; the first context refers to the context of the first call point; according to the second application interface, a second call point and a second context are determined; the second call point refers to the location where the second application interface is called in the user program; the second context refers to the context of the second call point; the judgment unit 602 is used to perform program analysis on the first context and the second context respectively, and determine whether the behavior of the first application interface at the first call point and the behavior of the second application interface at the second call point are equivalent; if they are equivalent, it is determined that there is no destructive change between the first application interface and the second application interface.

[0125] In one possible implementation method, the judgment unit 602 is used to perform program analysis on the first context and the second context respectively, extract characteristic information of parameter instances passed into the first application interface and the second application interface; determine a first execution result of the first application interface based on the characteristic information of the parameter instance passed into the first application interface; determine a second execution result of the second application interface based on the characteristic information of the parameter instance passed into the second application interface; and judge whether the behavior of the first application interface at the first call and the behavior of the second application interface at the second call are equivalent based on the first execution result and the second execution result.

[0126] In a possible implementation method, the characteristic information of the parameter instance includes: whether the value of the parameter instance is a null value, and / or the specific type of the parameter instance.

[0127] In one possible implementation method, the judgment unit 602 is used to perform symbolic execution on the implementation code of the first application interface based on the characteristic information of the parameter instance passed into the first application interface to obtain the first symbolic result of the first application interface; and substitute the first symbolic result into the first context to obtain the first execution result of the first application interface.

[0128] In one possible implementation method, the functional change includes one or more of the following: different number of overloads, different number of parameters, different parameter types, different return value types, and different implementation codes.

[0129] In a possible implementation method, the determining unit 601 is configured to determine, through an abstract syntax tree, whether the implementation codes of the first application program interface and the second application program interface are the same.

[0130] In a possible implementation method, the determining unit 601 is configured to determine that if there is a functional change between the application program interface on which the first application program interface depends and the application program interface on which the second application program interface depends, then there is a functional change between the first application program interface and the second application program interface.

[0131] Based on the same technical concept, the embodiment of the present application provides a destructive change determination device 700, which can be a computing device, for example. Figure 7 As shown, a destructive change determination device 700 includes at least one processor 701 and a memory 702 connected to the at least one processor. The specific connection medium between the processor 701 and the memory 702 is not limited in the embodiment of the present application. Figure 7For example, the processor 701 and the memory 702 are connected via a bus. The bus can be divided into an address bus, a data bus, a control bus, and the like.

[0132] In an embodiment of the present application, the memory 702 stores instructions that can be executed by at least one processor 701. The at least one processor 701 can execute the above-mentioned method for determining a destructive change by executing the instructions stored in the memory 702.

[0133] The processor 701 is the control center of the destructive change determination device 700, and can connect various parts of the computer device using various interfaces and lines. It can perform resource settings by running or executing instructions stored in the memory 702 and calling data stored in the memory 702. Optionally, the processor 701 may include one or more determination units. The processor 701 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 701. In some embodiments, the processor 701 and the memory 702 may be implemented on the same chip. In some embodiments, they may also be implemented on separate chips.

[0134] The processor 701 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0135] The memory 702 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 702 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 702 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 702 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0136] An embodiment of the present application further provides a computer-readable storage medium storing a computer-executable program, wherein the computer-executable program is used to enable a computer to execute a method for determining a destructive change listed in any of the above-mentioned methods.

[0137] An embodiment of the present application provides a computer program product, including a computer program executable by a computer device. When the program is run on the computer device, the computer device executes a method for determining a destructive change listed in any of the above-mentioned methods.

[0138] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0139] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0140] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0141] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0142] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A method for determining destructive changes, characterized in that: include: determining a first application program interface and a second application program interface having functional changes; The first application program interface and the second application program interface are the same application program interface corresponding to different versions of the same dependent library; Determining a first call location and a first context according to the first application program interface; the first call location refers to a location in a user program that calls the first application program interface; The first context refers to the context of the first call; Determining a second call location and a second context according to the second application program interface; The second calling location refers to the location in the user program where the second application program interface is called; The second context refers to the context of the second call location; Performing program analysis on the first context and the second context respectively to determine whether a behavior of the first application program interface at the first call location is equivalent to a behavior of the second application program interface at the second call location; If they are equivalent, it is determined that there is no destructive change between the first application program interface and the second application program interface.

2. The method according to claim 1, wherein The performing program analysis on the first context and the second context respectively to determine whether a behavior of the first application program interface at the first call location and a behavior of the second application program interface at the second call location are equivalent includes: Performing program analysis on the first context and the second context respectively to extract feature information of parameter instances passed into the first application program interface and the second application program interface; determining a first execution result of the first application program interface according to characteristic information of the parameter instance passed into the first application program interface; determining a second execution result of the second application program interface according to characteristic information of the parameter instance passed into the second application program interface; According to the first execution result and the second execution result, it is determined whether a behavior of the first application program interface at the first call location and a behavior of the second application program interface at the second call location are equivalent.

3. The method according to claim 2, wherein The characteristic information of the parameter instance includes: whether the value of the parameter instance is a null value, and / or the specific type of the parameter instance.

4. The method according to claim 3, wherein Determining a first execution result of the first application program interface according to characteristic information of the parameter instance passed into the first application program interface includes: performing symbolic execution on implementation code of the first application program interface according to feature information of the parameter instance passed into the first application program interface to obtain the first symbolic result of the first application program interface; The first symbol result is substituted into the first context to obtain a first execution result of the first application program interface.

5. The method according to claim 1, wherein The functional changes include one or more of the following: different number of overloads, different number of parameters, different parameter types, different return value types, and different implementation codes.

6. The method according to claim 5, wherein The method further includes: determining, through an abstract syntax tree, whether implementation codes of the first application program interface and the second application program interface are the same.

7. The method according to any one of claims 1 to 6, wherein The method further comprises: If there is a functional change between the application program interface on which the first application program interface depends and the application program interface on which the second application program interface depends, then there is a functional change between the first application program interface and the second application program interface.

8. A device for determining destructive changes, characterized in that: include: a determining unit, configured to determine a first application programming interface and a second application programming interface having a functional change; The first application program interface and the second application program interface are the same application program interface corresponding to different versions of the same dependent library; a first call location and a first context are determined based on the first application program interface; the first call location refers to a location in a user program where the first application program interface is called; The first context refers to the context of the first call; Determining a second call location and a second context according to the second application program interface; the second call location refers to a location in the user program where the second application program interface is called; The second context refers to the context of the second call location; a determination unit, configured to perform program analysis on the first context and the second context respectively, and determine whether a behavior of the first application program interface at the first call location is equivalent to a behavior of the second application program interface at the second call location; If they are equivalent, it is determined that there is no destructive change between the first application program interface and the second application program interface.

9. A computing device, characterized in that include: a memory for storing program instructions; A processor is configured to call the program instructions stored in the memory, and execute the method according to any one of claims 1 to 7 according to the obtained program instructions.

10. A computer-readable storage medium, characterized in that The method comprises computer-readable instructions, which, when read and executed by a computer, enable the method according to any one of claims 1 to 7 to be implemented.

11. A computer program product, characterized in that The invention comprises a computer program executable by a computer device, and when the program is run on the computer device, the computer device is caused to execute the steps of the method according to any one of claims 1 to 7.

Images