forked from scala/scala3
-
Notifications
You must be signed in to change notification settings - Fork 0
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
rochala
wants to merge
969
commits into
diagnostic-provider
Choose a base branch
from
cancellation
base: diagnostic-provider
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Cancellation #17
Conversation
This file contains hidden or 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
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.
…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.
Tests for scala#19413, scala#20070 and scala#23122
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
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.
No description provided.