| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They remain ValDefs until then.
- remove lazy accessor logic
now that we have a single ValDef for lazy vals,
with the underlying machinery being hidden until the fields phase
leave a `@deprecated def lazyAccessor` for scala-refactoring
- don't skolemize in purely synthetic getters,
but *do* skolemize in lazy accessor during typers
Lazy accessors have arbitrary user code, so have to skolemize.
We exempt the purely synthetic accessors (`isSyntheticAccessor`)
for strict vals, and lazy accessors emitted by the fields phase
to avoid spurious type mismatches due to issues with existentials
(That bug is tracked as https://github.com/scala/scala-dev/issues/165)
When we're past typer, lazy accessors are synthetic,
but before they are user-defined to make this hack less hacky,
we could rework our flag usage to allow for
requiring both the ACCESSOR and the SYNTHETIC bits
to identify synthetic accessors and trigger the exemption.
see also https://github.com/scala/scala-dev/issues/165
ok 7 - pos/existentials-harmful.scala
ok 8 - pos/t2435.scala
ok 9 - pos/existentials.scala
previous attempt: skolemize type of val inside the private[this] val
because its type is only observed from inside the
accessor methods (inside the method scope its existentials are skolemized)
- bean accessors have regular method types, not nullary method types
- must re-infer type for param accessor
some weirdness with scoping of param accessor vals and defs?
- tailcalls detect lazy vals, which are defdefs after fields
- can inline constant lazy val from trait
- don't mix in fields etc for an overridden lazy val
- need try-lift in lazy vals: the assign is not seen in uncurry
because fields does the transform (see run/t2333.scala)
- ensure field members end up final in bytecode
- implicit class companion method: annot filter in completer
- update check: previous error message was tangled up with unrelated
field definitions (`var s` and `val s_scope`),
now it behaves consistently whether those are val/vars or defs
- analyzer plugin check update seems benign, but no way to know...
- error message gen: there is no underlying symbol for a deferred var
look for missing getter/setter instead
- avoid retypechecking valdefs while duplicating for specialize
see pos/spec-private
- Scaladoc uniformly looks to field/accessor symbol
- test updates to innerClassAttribute by Lukas
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`typedFunction` uniformly recognizes Single Abstract Method types
and built-in `FunctionN` types, type checking literals regardless
of expected type.
`adapt` synthesizes an anonymous subclass of the SAM type, if
needed to meet the expected (non-`FunctionN`) type.
(Later, we may want to carry `Function` AST nodes with SAM types
through the whole pipeline until the back-end, and treat them
uniformly with built-in function types there too, emitting the
corresponding `invokedynamic` & `LambdaMetaFactory` bytecode.
Would be faster to avoid synthesizing all this code during type
checking...)
Refactor `typedFunction` for performance and clarity to avoid
non-local returns. A nice perk is that the error message for missing
argument types now indicates with `<error>` where they are missing
(see updated check file).
Allow pattern matching function literals when SAM type is expected
(SI-8429).
Support `return` in function body of SAM target type, by making the
synthetic `sam$body` method transparent to the `enclMethod` chain, so
that the `return` is interpreted in its original context.
A cleaner approach to inferring unknown type params of the SAM
method. Now that `synthesizeSAMFunction` operates on typed `Function`
nodes, we can take the types of the parameters and the body and
compare them against the function type that corresponds to the SAM
method's signature. Since we are reusing the typed body, we do need
to change owners for the symbols, and substitute the new method
argument symbols for the function's vparam syms.
Impl Notes:
- The shift from typing as a regular Function for SAM types was
triggered by limitation of the old approach, which deferred type
checking the body until it was in the synthetic SAM type
subclass, which would break if the expression was subsequently
retypechecked for implicit search. Other problems related to SAM
expansion in ctor args also are dodged now.
- Using `<:<`, not `=:=`, in comparing `pt`, as `=:=` causes
`NoInstance` exceptions when `WildcardType`s are encountered.
- Can't use method type subtyping: method arguments are in
invariant pos.
- Can't use STATIC yet, results in illegal bytecode. It would be a
better encoding, since the function body should not see members
of SAM class.
- This is all battle tested by running `synthesizeSAMFunction` on
all `Function` nodes while bootstrapping, including those where a
regular function type is expected. The only thing that didn't
work was regarding Function0 and the CBN transform, which breaks
outer path creation in lambdalift.
|
| |\ |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For local definitions (eg. in a block that is an argument of a method
call), the type completer may have a silent context. A CyclicReference
is then not thrown but transformed into a NormalTypeError. When
deciding if 'x = e' is an assignment or a named arg, we need to report
cyclic references, but not other type errors. In the above case, the
cyclic reference was not reported.
Also makes sure that warnings are printed after typing argument
expressions.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Enable simply:
```
scala> def f(@deprecatedName foo: String) = foo.reverse
f: (foo: String)String
scala> f(foo = "bar")
<console>:9: warning: naming parameter foo has been deprecated.
f(foo = "bar")
^
res0: String = rab
```
`Symbol.deprecatedParamName` conventionally returns `NO_NAME`
when the name is omitted.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow deprecatedName to specify the name of the parameter
it qualifies.
This tells the user, That's my name, don't wear it out.
I.e., don't use my name when calling me.
Use cases include: the name will change; normally a name
should be provided for a boolean, but not in this case
(perhaps because there is only one argument).
```
scala> def f(@deprecatedName('foo) bar: String) = bar.reverse
f: (bar: String)String
scala> f(foo = "hello")
<console>:9: warning: the parameter name foo has been deprecated. Use bar instead.
f(foo = "hello")
^
res0: String = olleh
scala> def g(@deprecatedName('foo) foo: String) = foo.reverse
g: (foo: String)String
scala> g(foo = "hello")
<console>:9: warning: naming parameter foo has been deprecated.
g(foo = "hello")
^
res1: String = olleh
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An `AppliedTypeVars` spawned from `HKTypeVar#applyArgs`
(necessarily) shares the same `TypeConstraints`.
But, we can have multiple ATVs based on a single HKTV floating
around during inference, and they can appear on both sides
of type relations. An example of this is traced out in
the enclosed test.
This commit avoids registering upper/lower bound constraints
when this is detected.
In the enclosed test, we end up with an empty set of constraints
for `?E`, which results in inference of Nothing, which is what
we expect.
I have also improved the printing of ATVs (to include the args)
and sharpened the log message when `solve` leaves type variables
instantiated to `NoType`, rather than some other type that doesn't
conform to the bounds. Both of these changes helped me to get
to the bottom of this ticket. The improved `ATV#toString` shows
up in some updated checkfiles.
The reported test has quite a checkered history:
- in 2.10.0 it worked, but more by good luck than good planning
- after the fix for SI-7226 / 221f52757aa6, it started crashing
- from 3bd897ba0054f (a merge from 2.10.x just before 2.11.0-M1)
we started getting a type inference failure, rather than a crash.
"no type parameters for method exists [...] because cyclic
instantiation".
- It still crashes in `isGround` in 2.10.3.
|
| |
|
|
|
|
|
| |
Rather than just the first.
For example, `foo(wizzle, wuzzle, woggle)` should report all three
not-found symbols.
|
| |
|
|
|
| |
This reverts commit 884e1ce762d98b29594146d37b85384581d9ba96, reversing
changes made to f6fcc4431f272c707d49de68add532c452dd4b0f.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The parser hole I found while working on the generated positions
serves as the umbrella for a host of improvements. Upgraded
positions assigned during some specific challenging situations mostly
involving the creation of synthetic trees, e.g. for comprehensions
and closures. While doing so improved some error messages.
Eliminated some of the most glaring duplication in the parser.
It's written like there is some payoff associated with being
spectacularly imperative. Not so far.
|
| |
|
|
|
|
|
|
| |
There appears to be no upper bound on the number of places
we have to remove calls to typeSymbol and introduce calls to
baseType. This one was type inference for function parameter
types: worked when expected type was A => B, but not if there
was an implicit conversion from A => B to the expected type.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code that was silently typed would not report warnings, even if it
returned a successful result.
This appeared in the following code which didn't show warnings even
with -Ywarn-adapted-args:
def foo(a: Any) = a; foo(1, 2)
While the following would show the expected warning:
def foo[A](a: Any) = a; foo(1, 2)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment parser does too much w.r.t handling of parent types.
It checks whether a parent can have value arguments or not and
more importantly, it synthesizes constructors and super calls.
This approach is fundamentally incompatible with upcoming type macros.
Take for example the following two snippets of code:
`class C extends A(2)`
`class D extends A(2) with B(3)`
In the first snippet, `A` might be a type macro, therefore the super call
`A.super(2)` eagerly emitted by the parser might be meaningless. In the
second snippet parser will report an error despite that `B` might be
a type macro which expands into a trait.
Unfortunately we cannot simply augment the parser with the `isTypeMacro`
check. This is because to find out whether an identifier refers to a type
macro, one needs to perform a typecheck, which the parser cannot do.
Therefore we need a deep change in how parent types and constructors
are processed by the compiler, which is implemented in this commit.
|
| |
|
|
|
|
| |
Because friends don't tell friends:
"wrong number of arguments for <none>"
|
| |\
| |
| | |
fix SI-5044: better error message on cyclic error and named/default args
|
| | | |
|
| |/
|
|
| |
better error message when a parameter is first defined positionally, then with a named argument.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
% scala -Dscalac.debug.tvar
scala> class Foo[CC[X] <: Traversable[X]] { def bar[T](xs: CC[T]) = xs.head }
defined class Foo
scala> new Foo bar List(1,2,3)
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ setInst] Nothing ( In Foo[CC[X] <: Traversable[X]], CC=Nothing )
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ create] ?T ( In Foo[CC[X] <: Traversable[X]]#bar[T] )
[ create] ?A ( In List#apply[A] )
[ create] ?A ( In List#apply[A] )
[ setInst] Int ( In List#apply[A], A=Int )
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ create] ?T ( In Foo[CC[X] <: Traversable[X]]#bar[T] )
[ create] ?CC ( In Foo[CC[X] <: Traversable[X]] )
[ applyArgs] ?CC ( In Foo[CC[X] <: Traversable[X]], apply args ?T to CC )
[ setInst] List ( In Foo[CC[X] <: Traversable[X]], CC=List )
[ setInst] Int ( In Foo[CC[X] <: Traversable[X]]#bar[T], T=Int )
res0: Int = 1
Also, I gave TypeVar some polymorphism. Review by @moors.
|
| |
|
|
|
|
|
| |
Custom versions of collections which methods which operate on 2 or 3
collections. Eliminated most users of zip/zipped. Cleaned up the kinds
checking code somewhat. Reduced the number of silent typechecks
being performed at named argument sites.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Important note for busy commit log skimmers ***
Symbol method "fullName" has been trying to serve the dual role of "how
to print a symbol" and "how to find a class file." It cannot serve both
these roles simultaneously, primarily because of package objects but
other little things as well. Since in the majority of situations we want
the one which corresponds to the idealized scala world, not the grubby
bytecode, I went with that for fullName. When you require the path to a
class (e.g. you are calling Class.forName) you should use javaClassName.
package foo { package object bar { class Bippy } }
If sym is Bippy's symbol, then
sym.fullName == foo.bar.Bippy
sym.javaClassName == foo.bar.package.Bippy
*** End important note ***
There are many situations where we (until now) forewent revealing
everything we knew about a type mismatch. For instance, this isn't very
helpful of scalac (at least in those more common cases where you didn't
define type X on the previous repl line.)
scala> type X = Int
defined type alias X
scala> def f(x: X): Byte = x
<console>:8: error: type mismatch;
found : X
required: Byte
def f(x: X): Byte = x
^
Now it says:
found : X
(which expands to) Int
required: Byte
def f(x: X): Byte = x
^
In addition I rearchitected a number of methods involving:
- finding a symbol's owner
- calculating a symbol's name
- determining whether to print a prefix
No review.
|
| |
|
|
|
|
|
|
| |
Since I don't want to commit anything "interesting" until we ship 2.9, a
few uninteresting cleanups involving how types are printed, getting some
debugging code in shape to prepare for the long winter ahead, etc. No
review.
|
| |
|
|
|
|
| |
Some cleanup from investigating #4041, with a comment instead of a fix
for the ticket. Review by rytz in case he sees a good way to fix it.
|
| |
|
|
|
|
| |
A raw tree was making its way into an error message. Removed. Closes
#4196, no review.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some refinement of the error messages when the found and required types
have the same simple names. No longer must we watch people scratch their
heads at such messages as:
found : scala.collection.Set[String]
required: Set[String]
Now so clear you could enjoy a movie through it:
found : scala.collection.Set[String]
required: scala.collection.immutable.Set[String]
No review.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
added @deprecatedName annotation, allowing to deprecate parameter names.
review by prokopec.
|
| | |
|
| |
|
|
|
|
| |
removed integration of placeholder syntax and named arguments. review by
odersky
|
| | |
|
| | |
|
| |
|
|
|
|
| |
fixes to check files and removed nonapplicable test case Tuple2 impl,
but commented out so that we can bootstrap whitespace...
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Enhanced error message when a type error is because of identically named
classes, one in scala.* and one not.
|
| | |
|
| |
|
|
|
| |
named arguments only at top level in () parameters.
|
| |
|
|
|
|
| |
improvements to names / defaults (implicits, type of defaults, #2064,
...)
|
| |
|
|
|
|
| |
allow using named / default arguments in self- and super constructor
calls. fixes #2050 and #2052.
|
| | |
|
| |
|
|
|
|
| |
named argument disallowed when assignment expression would typecheck.
minor fixe to names / defaults.
|
|
|
- MethodTypes now have (params: List[Symbol])
- "copy"-methods for case classes
- the "copy" object in the compiler is now called "treeCopy"
|
