Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wip: [2.x] merge 1.10.x #7554

Draft
wants to merge 331 commits into
base: develop
Choose a base branch
from
Draft

wip: [2.x] merge 1.10.x #7554

wants to merge 331 commits into from

Conversation

eed3si9n
Copy link
Member

@eed3si9n eed3si9n commented May 7, 2024

No description provided.

eed3si9n and others added 30 commits May 7, 2023 13:05
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.
feat: add in `actions()` to `Problem`
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
fix: get rid of the `FileChanges` abstraction
Add weaver-cats as a default test framework
**Problem**
Zinc added actions in Problem, but it's not yet forwarded to BSP
clients.

**Solution**
As discussed in
https://contributors.scala-lang.org/t/roadmap-for-actionable-diagnostics/6172,
the plan seems to be to use the `data` field with `actions` inside it,
so this implements that.
Update typelevel toolkit, configure test artifact
Problem
-------
sbt init menu doesn't pick the right template in the latter half.

Solution
--------
This fixes the mapping between the position and the letter.
SethTisue and others added 29 commits March 16, 2024 11:39
Scala 2.12.19 (was 2.12.18), scala-xml 2.2.0 (was 2.1.0)
Add support for SIP-51 (unfreezing the Scala library)
See also sbt/zinc#1326

This adds a new setting `enableConsistentCompileAnalysis`,
which enables the new "Consistent" Analysis format,
which is faster and more repeatable than the status quo.
This is initialized to `true` by default.
It can be opted out either by the setting or using
`-Dsbt.analysis2024=false`.
…hich also allows sbt to work on ARM64 Windows without needing to specify -Djline.terminal=jline.UnsupportedTerminal
Update jansi dep to match the one that's included in the jline dep
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)
...
```
It seems like the latest macOS image no longer supports JDK 8.
**Problem**
scala/scala3#20157 identified that
`sbt-dotty/dotty-knowledge.i17` scripted test fails on sbt 1.10.0-RC2.
The regression happened in https://github.com/sbt/sbt/pull/7480/files#diff-6d9589bfb3f1247d2eace99bab7e928590337680d1aebd087d9da286586fba77L739-L740
where global setting was removed, and moved to project level.

**Solution**
This restores the global setting that is apparently referenced by
now defunct Dotty plugin.
Zinc 1.10.0 + universal macOS sbtn binary
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.

None yet