Rules scala fixup #56
Closed
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
These files are not deterministic because the contain unordered maps. During my testing, I couldn't identify any meaningful difference in compile times with or without them.
The default global ExecutionContext simply logs uncaught exceptions. Since Future only catches NonFatal exceptions, any Fatal exceptions would cause the Future to never complete, which meant a WorkResponse was never sent back to the bazel server, which would then be stuck waiting forever for a response. Since Fatal exceptions can leave the JVM in an invalid state, we exit if any thread has an unhandled Fatal exception.
Zinc seems to run into this error pretty frequently, and if uncaught, the entire worker process will exit suddenly, which can leave Bazel in a weird state where it tries to send messages to the worker, but can't because the process has already exited. Consider this a temporary workaround until the underlying issues with Bazel can be fixed.
Exit Worker process on Fatal exceptions
…g them Currently the hashes can change due to sorting differences which breaks caching
We're seeing cache determinism issues again since re-adding these. NOTE: this change makes the ScalaCompile action incompatible with RE. We'll need to re-evaluate how to make these files deterministic before exploring RE on this rule set again.
…e-files-2 Don't include AnalyisCache files as action inputs
* return when getting null request in scala worker * add logging to scala worker to help debug hanging issue * Reword logging messages Co-authored-by: Jared Neil <[email protected]> * print args in string format Co-authored-by: Jared Neil <[email protected]>
In multiplexer mode, the compiler would occasionally hang because multiple threads were using the same HashMap, which is not thread safe.
- also run workflow on PRs to lucid-master
migrate ci to GitHub Actions (higherkindness#293)
This is a rather large commit with lots of changes. The end goal of the commit is to support Scala 3. That goal has been met, but not extensively tested in a production codebase. Part of this effort included upgrading the Scala 2 version in these rules to Scala 2.13 in order to test Scala 2.13's forwards compatibility with Scala 3. Zinc was also upgraded, so it supports Scala 3. Scalafmt was also upgraded, so it supports scala 3.
Using ijar on Scala 3 jars currently breaks things. Using ijar on Scala 2 does work. In order to support both of these things simultaneously, I introduced a config value on the Scala compiler, which informs whether the ijar or non-ijar version of the target should be used. I changed the Scala 3 test to make sure we had Scala 3 depending on Scala 2 and vice versa. Ultimately it would be nice to get rid of this configuration value by fixing ijars for Scala 3.
Scala 3 support
Upgrade to bazel 5.0.0
Upgrade Scala to 2.13.8 and 3.1.1
…acters-in-test-names Escape special regex characters in test names
b9436b0 Assumed that when the test filter is just a scope, the :: separating the scope and the (absent) test name would be escaped along with the scope, as it is when there is a test name. However, this is not the case. Just the scope is escaped, and the :: is not. So, replacing everything after the starting \Q, up to and including the ::, with nothing gets rid of the \E (which, when there's just a scope, is before the ::) which is needed for the \Q to work properly.
Handle specs2 scopes by themselves properly
…s in them We only handled .srcjar before, but many source jars are -sources.jar Also many source jars have MANIFEST.MF files in them. We were treating those as Scala sources before this fix, which is not correct.
Support -sources.jar source jars and sourcejars with MANIFEST.MF files in them
…traction These could/should probably be two separate commits, but the improvement to argument parsing was inspired by the requirements of multiplex sandboxing. The work was so intertwined that I'm leaving it as one PR. Good news is that if we need to move to another parsing framework in the future, it should be much easier because parsing is no longer spread throughout the work functions.
This is useful for when workers fail to run and have an error message to help with debugging. Otherwise you just have empty output.
Adds multiplex sandbox support and improves argument parsing
…db-files-separately Support not bundling SemanticDB files in the output JAR
Not only does ProblemStringFormats format problems (compilation messages) slightly differently, but it uses `xsbti.Position#pointer` rather than `xsbti.Position#offset` as the column number. Prior to v1.10.1 of Zinc, `sbt.internal.inc.javac.JavaPosition`, a concrete implementation of `Position`, set `pointer` to `None` unconditionally, meaning that `ProblemStringFormats` didn't have access to the line number. To fix this, I upgraded our version of Zinc to v1.10.1 from v1.10.0.
Make error reporting match that of SBT's
Support worker cancellation for all workers
rules_java supports it, and we support it, so we might as well use it.
None of the workers use it yet, but it is an update to the interface. Want to get it merged, so we can stop making changes to the interface for a bit.
Sends verbosity from the worker protocol to the worker, enables Java toolchain multiplex sandboxing, and fixes the launcher to work with multiplex sandboxing
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.
@jadenPete actually wrote all of this, it just adds compiler information to the bazel providers(? or something, I don't know bazel that well) so bazelbsp can use it.