**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
**Problem**
It's currently not easy to write a scripted test that works on
both sbt 1.x and 2.x when you want to write exists test under target.
**Solution**
Since we can only use the file system (and not evaluate Scala version etc)
1. this implements glob expression support in `exists`, `absent`, and `delete`.
2. this also introduces `||` operator that would mean a or b.
**Problem**
It's currently not easy to write a scripted test that works on
both sbt 1.x and 2.x when you want to write exists test under target.
**Solution**
Since we can only use the file system (and not evaluate Scala version etc)
1. this implements glob expression support in `exists`, `absent`, and `delete`.
2. this also introduces `||` operator that would mean a or b.
sbt passes raw string messages in `ConsoleAppenderFromLog4J` to `StringFormatterMessageFactory`. This is wrong because these strings are pre-formatted and should not be processed again for formatting. There is no way to pass parameters to them anyway. This causes problems when the raw strings contain characters that `StringFormatterMessageFactory` wants to interpret.
For example, when using `-Ystatistics`:
```
ERROR StatusConsoleListener Unable to format msg: nscprofiling : 1 spans, ()7.543ms (0.3%)
java.util.UnknownFormatConversionException: Conversion = ')'
at java.base/java.util.Formatter.checkText(Formatter.java:2732)
at java.base/java.util.Formatter.parse(Formatter.java:2718)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2938)
at org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:121)
at org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:89)
at sbt.internal.util.Appender.$anonfun$appendMessage$1(ConsoleAppender.scala:522)
...
```
Previously, the list of logger names that have been created in a given
context with Log4J was being kept in a `Vector`. As a result, subsequent
calls to `logger` on a `Log4JLoggerContext` with the same logger name
would introduce duplicates in the list. Note that Log4J's logger
configuration would not allow duplicates, and only one configuration
object for a given logger name will exist. The duplicates in the list of
logger names are therefore unnecessary.
With this patch, the logger names will be kept in a `HashSet`.
Since the logger names are only used to remove the logger configurations
after the logger context is closed, and the logger configurations
contain no duplicates, removing duplicate logger names should not cause
any issue.
- remove unused type params
- use `withFilter` if possible
- use `collectFirst` instead of `collect` and `headOption`
- use `length` instead of `size` if `Array` or `String`
- use `foreach` instead of `map`
I don't believe this is actually needed. We can simplify the
`WorkspaceEdit` further and put together the mapping for `changes`
according to the LSP spec later on down the line. This will allow us to
remove the need for the `URI`, which is problematic.
closes#7252
This adds a new field into `xsbti.Problem` allowing for the compiler to
forward "actions" that can address diagnostics. The idea largely mimics
a very minimal `CodeAction` that can be found in the [LSP
Spec](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeAction)
in order to ensure it will work with a variety of difference clients
that use LSP, and those that don't. In the future the `WorkspaceEdit`
that was created here could also be expanded to handle more advanced
changes, aka resource operations, like creating/moving/deleting files.
For now we only focus on a small subset of these features.
If the terminal supports ANSI control sequence,
this displays the template list in an interactive way.
The focused template is rendered reversed,
and arrow key can be used to move the focus up/down.
Looks like I missed this in https://github.com/sbt/sbt/pull/6874 and I
hit on it in Mill when I couldn't figure out why it was also empty, and
thanks to @adpi realized it was because of the `LoggedReporter` in zinc
not taking it into account. However before I can bump that this needs to
be bumped as well.
refs: https://github.com/lampepfl/dotty/issues/14904
Looks like I missed this in https://github.com/sbt/sbt/pull/6874 and I
hit on it in Mill when I couldn't figure out why it was also empty, and
thanks to @adpi realized it was because of the `LoggedReporter` in zinc
not taking it into account. However before I can bump that this needs to
be bumped as well.
refs: https://github.com/lampepfl/dotty/issues/14904
If we use the ProxyTerminal in the background jobs, the logs
would be spread across different terminals, switching from active
client to active client. We want the logs to stick
to the client that started the job.
A new context is created and closed for each state of the MainLoop.
But the context of the backgroundJob must stay alive.
So we use a context that is owned by the BackgroundJobService.
It creates a new logger for each background job and cleans it when
the job stops.
This PR makes changes to the existing `xsbti.Problem` to account for an
optional diagnostic code that the compiler can return for a given
diagnostic and also related information.
Given a piece of code like:
```scala
try {}
```
You'll receive the following:
```
-- [E002] Syntax Warning: /Users/ckipp/Documents/scala-workspace/dotty-error-index/examples/002_EmptyCatchAndFinallyBlockID.scala:3:2
3 | try {}
| ^^^^^^
| A try without catch or finally is equivalent to putting
| its body in a block; no exceptions are handled.
```
The `E002` here is the actual code. Right now there would be no
description.
Some diagnostics have multiple positions that they need to represent.
You can see an example of this
[here](lampepfl/dotty#14002) in Dotty with the
use of inlining. Instead of needing to rely on including all of that
information in the diagnostic message it can now be extracted out into
a `DiagnosticRelatedInformation`.
These changes reference the conversation in #6868
xuwei-k
eugene yokota
friendseeker
adpi2
Stefan Zeiger
Matthias Kurz
Heikki Vesalainen
Martin Duhem
Julien Richard-Foy
Andrzej Ressel
Chris Kipp
Amina Adewusi
Amina Adewusi
tpetillot
David Francoeur