Skip to content

Conversation

@Locke
Copy link
Contributor

@Locke Locke commented May 16, 2018

Thanks a lot for taking the time to look into my PRs and the merge!

In the meantime I developed some more changes and collected some of them here. This PR contains a bugfix in the aggregation of SetElements, some code cleanup and also some minor logging and performance improvements.

Just a heads up: I'm also working on more performance changes, mostly regarding synchronized code and also a upgrade from EDU.oswego.cs.dl.util.concurrent to java.util.concurrent.ForkJoinPool, but haven't finished that for a PR yet.

Locke added 18 commits May 16, 2018 12:52
In case of `extend U with x do R` the value `x` will not be a member of `U` (as the UpdateSet wasn't consistent `x` wasn't added to `U`).

Therefore any writes to a function with a signature `.. * U * .. -> ..` or `.. -> U` will report `x` not being a member of `U`,
although there is nothing wrong with such an update.
.. add @OverRide, remove unnecessary casts, and re-order methods
in HashState to match the State interface and HashStorage
…getFunctionName

The name is already known iff the FunctionElement is loaded from the storage
- and useIncrementalCompilation=false
Tests all cases of SetPlugin.compose, especially
aggregateLocationForComposition and eradicateConflictingIncrementalUpdates
@Locke
Copy link
Contributor Author

Locke commented Feb 6, 2019

Added test file "Set4_compose.java" specifically for the rule Case3a_remove to test SetPlugin.aggregateLocationForComposition().

I think the solution in the recent commit bfc6350 looks better than my approach in 74fae96.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant