#753 [Shrike] pop2 opcode not translated to Pop(2) instruction #775
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
It looks like there are some tests failing, e.g., the |
DeepCode's analysis on #bb0fe4 found:
Top issues
👉 View analysis in DeepCode’s Dashboard | Configure the bot |
…trol and data dependencies
allow no default edge type remove uses of default to instead make e.g. hasEdge check for an edge with any label. This is more consistent with what other APIs do.
new file: fact.java modified: wala.testdata.txt 1) new test file new file: ../../com.ibm.wala.core/src/main/java/com/ibm/wala/classLoader/ClassFileURLModule.java modified: ../../com.ibm.wala.core/src/main/java/com/ibm/wala/core/util/config/AnalysisScopeReader.java 2) read class files as urls to load classes from arbitrary resources
This was the simplest way I could find to introduce [dependency locking](https://docs.gradle.org/current/userguide/dependency_locking.html), which should prevent issues like wala#898 / wala#899 in the future. It adds a bunch of empty lock files for configurations without dependencies, but since they are auto-generated I don't think this is a big deal; it will be more fragile to try to only generate non-empty lock files. For now, we use the `LENIENT` lock mode to work around failure of certain checks in the default mode; see the comments for details. Even in `LENIENT` mode, dynamic dependencies should be fixed at the versions in the lock files.
The `KawaCallGraphTest` tests take too long to run. This adds a limit to how many fixed point iterations the call graph construction runs for, which yields enough runs to pass the assertions while making the tests terminate faster. This may cause an unexpected failure later if we tweak the internals of our fixed point computations, but that code is pretty stable. And this approach is less flaky than just setting a timeout, since our core fixed point code is pretty deterministic AFAIK. Plus, I don't know enough about what is being tested here to reduce the input enough to make a fast-running unit test.
Turns out, IntelliJ IDEA doesn't like having a single directory be a content root for more than one module. OK, we can easily configure this differently so that resources are copied from another task without adding reusing that other task's resource directories to multiple `SourceSet`s.
Previously, the top-level `build.gradle` iterated over all subprojects and applied lots of additional build-configuration logic to subprojects that contain Java source code. Now, that Java-specific configuration logic is extracted into its own `wala-java.gradle` script plugin, which each individual subproject can load if appropriate. This change makes the top-level `build.gradle` a bit smaller and easier to read through.
Instead of task A explicitly declaring that it `dependsOn` task B, the preferred style is for task A to declare that its inputs include task B's outputs (or some subset thereof). The dependency between the tasks should be implicit, to be inferred by Gradle.
Javadoc tasks only arise in Java-containing subprojects, with one important exception: the `aggregatedJavadocs` task in the top-level project. Extract Javadoc-specific configuration into its own script plugin that we can reuse wherever we need it, even in projects that do not contain any Java code of their own. Corrects [a regression](https://github.com/wala/WALA/runs/4424048891?check_suite_focus=true) that was introduced by pull request wala#1075. I'm also adding `aggregatedJavadocs` to the standard tasks performed by all pre-merge GitHub CI jobs. That should help us catch any future regressions of this task earlier, before merging to `master`.
As used here, it's enough to have a `Provider` for the `Task` that may eventually be created. We don't need to force creation of that task right away.
We didn't write this code and are in no position to critique its formatting.
Our previous approach triggered deprecation warnings. This new approach works fine, and should be compatible with some future Gradle 8.x release. The important change seems to be to treat subprojects' Javadoc tasks' class paths as Gradle "artifacts", which are allowed to be produced and consumed in different (sub)projects. Fixes wala#1079.
As [pointed out by `$RANDOM_INTERNET_PERSON`](TwoStone/gradle-eclipse-compiler-plugin#13 (comment)), this extra step is not needed. Setting an executable in the fork options (which we do) is sufficient.
Running `./gradlew runInspections` works fine on Fedora 35. However, on Ubuntu 20.04, it hangs. The headless IntelliJ IDEA subprocess fails to exit once the inspections have all been run. I don't know why. Until we can make this work, we shouldn't run this as a weekly GitHub action.
Pulls in various bug fixes and improvements; see https://github.com/mozilla/rhino/releases/tag/Rhino1_7_14_Release. Includes a source location fix we contributed (mozilla/rhino#808)
This release has [a few improvements](https://github.com/michel-kraemer/gradle-download-task/releases/tag/5.0.0) over the 4.x versions of this plugin. For example, it can download concurrently with other build tasks or downloads, and it shows the destination file name in the build progress message.
Organizing shared logic in this way avoids [ cross-project configuration](https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#sec:convention_plugins_vs_cross_configuration) that can "introduce configuration-time coupling between projects, which can prevent optimizations like configuration-on-demand from working properly."
For the best Gradle performance, we should always use Gradle task-configuration-avoidance APIs to configure tasks only when truly needed.
My recent attempt to avoid premature task configuration accidentally broke the `aggregatedJavadocs` task. This commit corrects that regression.
`subprojects` can be invoked directly with a closure to apply to each subproject.
# Conflicts: # com.ibm.wala.core/src/test/java/com/ibm/wala/core/tests/shrike/FloatingPointsTest.java
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hopefully fixes #753 but I think some other tests fail. Maybe it's because of some setup issues on my machine. Need external review