aboutsummaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
* Decouple Product and pattern-matchingOlivier Blanvillain2017-04-064-18/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Product pattern use to: - have a `<: Product` requirement - compute the arity of a pattern by looking at `N` in a `ProductN` superclass. This commit changes `<: Product`, instead we look for a `_1` member. The arity is determined by inspecting `_1` to `_N` members instead. --- Here another attempt to formalize Dotty's pattern-matching (base on #1805). This covers the *Extractor Patterns* [section of the spec](https://www.scala-lang.org/files/archive/spec/2.12/08-pattern-matching.html#extractor-patterns). Dotty support 4 different extractor patterns: Boolean Pattern, Product Pattern, Seq Pattern and Name Based Pattern. Boolean Pattern - Extractor defines `def unapply(x: T): Boolean` - Pattern-matching on exactly `0` patterns Product Pattern - Extractor defines `def unapply(x: T): U` - `N > 0` is the maximum number of consecutive (parameterless `def` or `val`) `_1: P1` ... `_N: PN` members in `U` - Pattern-matching on exactly `N` patterns with types `P1, P2, ..., PN` Seq Pattern - Extractor defines `def unapplySeq(x: T): U` - `U` has (parameterless `def` or `val`) members `isEmpty: Boolean` and `get: S` - `S <: Seq[V]` - Pattern-matching on any number of pattern with types `V, V, ..., V` Name Based Pattern - Extractor defines `def unapply(x: T): U` - `U` has (parameterless `def` or `val`) members `isEmpty: Boolean` and `get: S` - If there is exactly `1` pattern, pattern-matching on `1` pattern with type `S` - Otherwise fallback to Product Pattern on type `U` In case of ambiguities, *Product Pattern* is preferred over *Name Based Pattern*.
* Generate synthetic productElement/productArity methods above 22Olivier Blanvillain2017-04-062-28/+56
|
* Workaround #1932 (bug trigged by desugaring changes)Olivier Blanvillain2017-04-061-1/+1
|
* Adapt TastyPrinter to new formatMartin Odersky2017-04-061-1/+1
|
* Update doc comment on HkTypeLambda/PolyTypeMartin Odersky2017-04-061-12/+13
|
* PolishingsMartin Odersky2017-04-067-19/+13
|
* Refactorings for efficiencyMartin Odersky2017-04-062-43/+56
| | | | | | | | | - split LambdaType.equals into two equals so that tests are more specific (also avoids type testing against a trait) - re-order cases in some pattern matches with the aim to (1) move common cases earlier, (2) move more expensive trait type tests later.
* Narrow matches from TypeLambda to HKTypeLambda where appropriateMartin Odersky2017-04-064-8/+10
|
* Merge MethodType and PolyType functionality where possibleMartin Odersky2017-04-0612-130/+78
| | | | | | Two benefits: (1) less code. (2) finding subtle bugs about parameter dependent method types. By merging with PolyTypes we are forced to take parameter dependencies into account.
* Make PolyType a ground typeMartin Odersky2017-04-062-1/+5
| | | | | It's too surprising to leave it as a type proxy. In all circumstances except erasure, it is not true that a PolyType is somehow the same as its result type.
* Split HKTypeLambda from PolyTypeMartin Odersky2017-04-069-31/+28
|
* Generalize comparisons from PolyTypes to TypeLambdasMartin Odersky2017-04-061-7/+7
|
* Handle hk lambdas in tastyMartin Odersky2017-04-064-33/+42
|
* Eliminate LambdaAbstractMartin Odersky2017-04-067-34/+34
| | | | Use fromParams instead.
* Further refactoringsMartin Odersky2017-04-0621-146/+150
| | | | | - Use TypeLambda instead of PolyType. - Further harmonize factory operations
* Rename PolyTypeTree -> LambdaTypeTreeMartin Odersky2017-04-0613-44/+44
|
* Add HKTypeLambdaMartin Odersky2017-04-061-5/+40
|
* Eliminate MethodOrPolyMartin Odersky2017-04-064-6/+4
| | | | Replace with LambdaType
* Eliminate ParamTypeMartin Odersky2017-04-065-18/+12
| | | | Replace with ParamRef
* replace derived{Method,Poly}Type with derivedLambdaTypeMartin Odersky2017-04-0617-45/+34
|
* Add StarLambda, HKLambda abstractions ...Martin Odersky2017-04-061-70/+79
| | | | | ... to distinguish between HK(proxy) and *(ground) types. Also, refactor some more methods to keep it DRY.
* Make PolyTypes subtypes of LambdaTypesMartin Odersky2017-04-064-98/+89
| | | | Also, rename LambdaOver{Type,Term}s to {Type,Term}Lambda
* Rename PolyParam --> TypeParamRefMartin Odersky2017-04-0628-173/+166
|
* Refactor ParamRef so that no type params are neededMartin Odersky2017-04-064-51/+31
|
* Disable -strict when compiling dotty.Martin Odersky2017-04-061-3/+3
| | | | | | It seems we need a more refined way to deal with non-variant variables in pattern matches. See branch change-patmat-undet for a WIP. For the moment we disable -strict to be able to compile latest version of dotty. (reverted from commit c8fe830f8a382eb965c2231064fa286ee8f0a4ec)
* Remove parameter from lambda typeMartin Odersky2017-04-062-9/+12
|
* Disable -strict when compiling dotty.Martin Odersky2017-04-061-3/+3
| | | | | | It seems we need a more refined way to deal with non-variant variables in pattern matches. See branch change-patmat-undet for a WIP. For the moment we disable -strict to be able to compile latest version of dotty.
* Get rid of Name parameter for LambdaType and ParamRefMartin Odersky2017-04-064-24/+32
| | | | Use an abstract type instead.
* ParamType refactoringsMartin Odersky2017-04-064-77/+78
| | | | Trying to bring PolyTypes closer to TypeLambdas
* Harmonize paramTypes and paramBoundsMartin Odersky2017-04-0643-213/+216
| | | | | | MethodTypes have paramTypes whereas PolyTypes have paramBounds. We now harmonize by alling both paramInfos, and parameterizing types that will become common to both.
* Break out functionality from MethodTypeMartin Odersky2017-04-0620-134/+176
| | | | | and generalize MethodParam to ParamRef, and TypeParamInfo to ParamInfo
* Drop name checking scheme for type parametersMartin Odersky2017-04-061-9/+3
| | | | | It was a red herring. Symbolic names are expanded anyway to $plus / $minus, so they can't be confused with a variance prefix.
* Don't let illegal parameter names propagate into typesMartin Odersky2017-04-061-4/+4
|
* Add neg test for illegal parameter namesMartin Odersky2017-04-061-1/+1
| | | | and fix typo
* Encode variances in parameter namesMartin Odersky2017-04-0613-41/+76
| | | | | | | | | | This leads to a slight overall simplification, harmonizes pickle format with internal representation, and makes MethodTypes and PolyTypes more similar to each other. I believe the change is useful as it is, but in particular it is a useful step for an eventual unification of MethodTypes and PolyTypes.
* Merge pull request #1958 from dotty-staging/add-enumodersky2017-04-0619-149/+547
|\ | | | | Add "enum" construct
| * Emit enum utility methods only if enum class is not genericMartin Odersky2017-04-061-6/+8
| |
| * Implementation of proposal changesMartin Odersky2017-04-052-45/+76
| | | | | | | | | | - rename utility methods - generate utility methods also for object cases
| * Infer enum type args from type parameter boundsMartin Odersky2017-04-041-11/+45
| | | | | | | | | | | | Infer type arguments for enum paraments from corresponding type parameter bounds. This only works if the type parameter in question is variant and its bound is ground.
| * Fix rebase breakageMartin Odersky2017-04-041-1/+1
| |
| * Avoid assertion failure on neg testMartin Odersky2017-04-041-1/+8
| | | | | | | | This commit can hopefully be reverted once #2121 is in.
| * Support cases with type parameters that extend a non-parameterized baseMartin Odersky2017-04-042-16/+24
| | | | | | | | | | | | | | | | Support cases with type parameters that implicitly extend a non-parameterized base without needing their own extends clause. The proposal has been updated to make clear that this is supported. Also address other reviewers comments.
| * Support comma-separated enum constantsMartin Odersky2017-04-043-26/+46
| |
| * Change enumeration members.Martin Odersky2017-04-042-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on the discussion in #1970, enumeration objects now have three public members: - valueOf: Map[Int, E] - withName: Map[String, E] - values: Iterable[E] Also, the variance of case type parameters is now the same as in the corresponding type parameter of the enum class.
| * Change return type of `apply`.Martin Odersky2017-04-041-7/+7
| | | | | | | | | | | | | | | | | | | | | | In an enum case like case C() extends P1 with ... with Pn ... apply now returns `P1 & ... & Pn`, where before it was just P1. Also, add to Option test.
| * Don't change the return type of the `copy` methodMartin Odersky2017-04-041-1/+1
| | | | | | | | | | `copy` should always return the type of it's rhs. The discussion of #1970 concluded that no special treatment for enums is needed.
| * Check that cases with type parameters also have an extends clauseMartin Odersky2017-04-041-1/+5
| |
| * Fix cheeky comment in nested scopeFelix Mulder2017-04-042-6/+47
| |
| * More fine-grained distinctions when flags are defined.Martin Odersky2017-04-043-9/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Flags like Trait are in fact not always defined when a symbol is created. For symbols loaded from class files, this flag, and some other is defined only once the classfile has been loaded. But this happens in general before the symbol is completed. We model this distinction by separating from the `FromStartFlags` set a new set `AfterLoadFlags` and distinguishing between the two sets in `SymDenotations#is`. Test case is enum-Option.scala. This erroneously complained before that `Enum` was not a trait.
| * Fix typoMartin Odersky2017-04-041-1/+1
| |
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-30 08:48:00 +0000