The built-in 'literal' role implements ``. It tokenizes the
literal string to attempt some particular wrapping behavior.
This puts parts of the string in different spans, each with
class='pre' and the previous docs.css had a padding for that
class. This led to excessive space within the literal string.
The custom role does no do this tokenization, but nested
inline parsing can result in multiple nodes, repeating the
problem. So, the padding for class='pre' is dropped. Ideally,
the sequence of nodes would simply be wrapped in an inline element
with class='pre' or some other proper solution that avoids having
multiple nodes.
To avoid wrapping in the middle of a literal, the 'pre' class
now has the style `white-space: pre;`.
The default role is now 'codeliteral' and the previous
uses of the built-in `` are converted to `. Some incorrectly
converted code blocks were fixed in the process.
Finally, the Global-Settings page is updated with the new location
for the global sbt directory. Due to the above changes, this could
be done without hardcoding the version.
This drops older code that picked a single fingerprint within a framework.
This commit ensures only one name is executed across all frameworks.
The precedence is the order that frameworks are declared in Defaults.scala.
JUnit should be last because it is common for specs tests to be annotated
with @RunWith for Eclipse support. If a distinct fingerprint is not
picked, the test will be run by both specs and JUnit.
In addition to this main reason, result processing code assumes one result
per test class name and would have to be fixed if multiple fingerprints
were allowed.
This way we have a little bit more clear separation
between compiler phase logic and the core logic responsible for
processing each compilation unit and extracting an api for it.
As added benefit, we have a little bit less of mutable state
(e.g. sourceFile doesn't need to be a var anymore).
The API extraction logic contains some internal caches that are
required for correctness. It wasn't very clear if they have to
be maintained during entire phase run or just during single compilation
unit processing. It looks like they have to be maintained during
single compilation unit processing and refactored code both
documents that contracts and implements it in the API phase.
Move collection (a class `Compat`) of compatibility hacks into separate
file. This aids understanding of the code as both Analyzer and API make
use of that class and keeping it `Analyzer.scala` file suggested that
it's used only by Analyzer.
Incremental compiler didn't have any explicit logic to handle
cancelled compilation so it would go into inconsistent state.
Specifically, what would happen is that it would treat cancelled
compilation as a compilation that finished normally and try to
produce a new Analysis object out of partial information collected
in AnalysisCallback. The most obvious outcome would be that the
new Analysis would contain latest hashes for source files. The
next time incremental compiler was asked to recompile the same files
that it didn't recompile due to cancelled compilation it would think
they were already successfully compiled and would do nothing.
We fix that problem by following the same logic that handles compilation
errors, cleans up partial results (produced class files) and makes sure
that no Analysis is created out of broken state.
We do that by introducing a new exception `CompileCancelled`
and throwing it at the same spot as an exception signalizing compilation
errors is being thrown. We also modify `IncrementalCompile` to
catch that exception and gracefully return as there was no compilation
invoked.
NOTE: In case there were compilation errors reported _before_
compilation cancellations was requested we'll still report them
using an old mechanism so partial errors are not lost in case
of cancelled compilation.
Mark Harrah
Jacek Laskowski
Johannes Rudolph
James Roper
Eugene Yokota
Grzegorz Kossakowski
Lloyd Meta