Skip to content

Cancellation #17

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

Open
wants to merge 969 commits into
base: diagnostic-provider
Choose a base branch
from
Open

Cancellation #17

wants to merge 969 commits into from

Conversation

rochala
Copy link
Owner

@rochala rochala commented Apr 3, 2025

No description provided.

tgodzik and others added 30 commits March 28, 2025 08:49
Fixes scala#22874.

`wildApprox` approximates parameter references and type variables by
wildcards. When doing so for an `AnnotatedType`, this can produce trees
with wildcards types, causing the type assigner to fail. For example,
consider `Apply(fn, args)` where `fn` has type `TermParamRef`. Applying
`wildApprox` will approximate the type of `fn` to a wildcard, leading
[the type assigner for
`Apply`](https://github.com/scala/scala3/blob/cb97c40930d335e0fca38238682d218c3e718bd8/compiler/src/dotty/tools/dotc/typer/TypeAssigner.scala#L298)
to emit an error stating that `<?>` does not take parameters.

This issue is somehow similar to the one described in
scala#19957 (comment),
which was fixed by scala#21941 (and
re-worked in scala#22839).

This PR fixes the issue by approximating annotated types in
`wildApprox`: annotated types are approximated by their parent types if
they are not refining, or by wildcards upper-bounded by their parent
types if they are.
Getting started now includes correct commands used to setup working on
bootstrapped projects
We update to the latest RC of develocity, which fixes some bugs found
during the testing phase.
…cala#22865)

Since 2.13, case class `hashCode` mixes in the hash code of the
`productPrefix` string. This is inconsistent with the `equals` method,
subclasses of case classes that override `productPrefix` compare equal
but have a different `hashCode`
(scala/bug#13033).

This commit changes `hashCode` to mix in the `productPrefix.hashCode`
statically instead of invoking `productPrefix` at runtime.

For case classes without primitive fields, the synthetic `hashCode`
invokes `ScalaRunTime._hashCode`, which mixes in the result of
`productPrefix`. To fix that, the synthetic hashCode is changed to
invoke `MurmurHash3.productHash` directly and mix in the name to the
seed statically.

Scala 3 forward port of scala/scala#11023
Fixes scala#22895 
Fixes scala#22896 
Follow-up to scala#22729 
Follow-up to scala#22757 

Since Scala 2, the check for unused parameters does not warn for an
overriding method, since the signature is dictated by the overridden
method. That behavior was intentionally omitted in 3.7 because it was
introduced in Scala 2 before `@nowarn` and `@unused` were available.
(The warning would be too noisy without mitigation.) A compiler option
for these heuristics was tried in a previous commit, but reverted.
(Compiler options are difficult to evolve once added.) So these commits
restore this heuristic without further ado. An option for "strict mode"
without allowances is future work.

The other issue was that detecting an override in a Java parent did not
work. The commit always checks `is(Override)` before searching for an
overridden member, since it is not necessary to verify the modifier
(which happens in RefChecks). Incorrect overriding would result in false
negatives, which is acceptable since it will error later.

Further asymmetry between checking implicit params and explicit class
param accessors may or may not be dubious.
# Conflicts:
#	compiler/src/dotty/tools/dotc/cc/Setup.scala
Simplifies previous too convoluted logic.
No need to refer to keep track of openExistentials.
…he binder

Some failing tests:

 - pos test lists.scala
 - neg test i21920.scala

Both are moved to pending.

Also some errors in neg test curried-closures.scala look wrong, these seem to be analogous to the errors in
lists.scala.
Use an explicit `reported` set. The previous logic suppressed some
real non-duplicate errors.
A capture set variable can appear several times at different variances in a type. So interpolating at the first
variance encountered is wrong. Instead, we need to compute the overall variance and interpolate according to it.
tgodzik and others added 20 commits May 13, 2025 20:13
…able` to `main` (scala#23153)

The [created PRs](scala#23152) be this
job were potentially erroneous, allowing to overwrite changes on main.
These are also typically outof date - language-reference-stable tracks
at least 1 stable release before the current main.

Instead possible backports should be done manually
Fixes scala#22649.

The printed representation looks like this:

```
RecursiveType(rec12 => ... RecursiveThis(<rec12>) ...)
```
Declarations like `type C <: {cap}` were missing the `CaptureVar`
attachment after post-processing in typer. This PR ensures that the
attachment is added.
The new version of the plugin fixes an issue with the cleanup of the
local cache that the scala infrastructure suffers from.
Fixes scala#23145

As in Scala 2, use TreeInfo to deal with the hassle of adapted trees.

The interesting case is `this.m` which is a lossy adaptation. The
attachments must be copied.
https://github.com/VirtusLab/scala-cli/releases/tag/v1.8.0

Notable changes:
- Scala.js set to 1.19.0
- Scala LTS bumped to 3.3.6
- `runner` and `test-runner` modules are now built with Scala 3.3.6, and
thus only support Scala 3.3+ (support for 2.13 and 2.12 remain
unchanged). For builds using Scala 3.0, 3.1 and 3.2, and older
`runner`/`test-runner` is used (v1.7.1, specifically).
- A number of compiler options no longer require being passed with `-O`,
when used from the command line.
- Scala CLI now detects multiple test frameworks under the `test`
sub-command, rather than just one.
- It is also possible to pre-define multiple test frameworks in a Scala
CLI project.
```scala
//> using test.frameworks org.scalatest.tools.Framework munit.Framework custom.CustomFramework
```

@WojciechMazur @tgodzik we might want to backport this into 3.7.1, if we
do another RC.
The suggestion to try nightlies would've saved me about 10 minutes
because I would've seen @som-snytt already fixed scala#22901...

[skip ci]

---------

Co-authored-by: Som Snytt <[email protected]>
Co-authored-by: Piotr Chabelski <[email protected]>
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.