| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
SI-6258 Reject partial funs with undefined param types
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This regressed with virtpatmat.
With -Xoldpatmat, pattern matching anonymous functions with
an expected type of PartialFunction[A, B] are translated to
a Function tree, and typed by typedFunction, which issues an
error of the parameter types are not fully defined.
This commit adds the same check to MatchFunTyper.
It doesn't plug the hole in RefChecks#validateVariance (which is
reminiscent of SI-3577.) Seems to me that in general one should handle:
a) both BoundedWildcardType and WildcardType
when in a place that can be called during inference, or
b) neither otherwise
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Eliminated InvalidCompanions exception entirely. Anyone's
guess why we unholstered this exception every time someone
calls "isCodefinedWith" rather than when symbols are created.
I moved the check into Namers, where it can be done once and
with sufficient finesse not to crash so much.
With this patch in place, "playbench" can be built with java7.
|
| |\ \
| | |
| | | |
Fix for SI-6273, repl string interpolation.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
As usual the hard part is tracing through all the
needless abstraction. Begone, 25 layers of parsing error
issuing methods!
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When an error occurs because some type does not conform
to AnyRef (and an AnyRef-derived type would have sufficed)
try to say something useful about the situation.
This commit also initializes scope members before printing
error messages because the + version seems more useful than
the - version (taken from one of the checkfile diffs.)
- def <init>: <?>
- def methodIntIntInt: <?>
+ def <init>(): X
+ def methodIntIntInt(x: scala.Int,y: scala.Int): scala.Int
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Don't try to implicitly convert an unstable prefix
to a stable one by applying a view. As the matrix spoon kid
says, "that's impossible."
|
| |/ /
| |
| |
| |
| | |
I have seen this warning a bunch of times and it has not yet
been close to right.
|
| |\ \
| | |
| | | |
Fix SI-4581.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Specifically, the final flag on the generated static field
is no longer ommitted.
Fix 2 failing test-cases.
|
| | | |
| | |
| | |
| | |
| | | |
The test exercises the most important case, when implicits are invalidated through shadowing.
(See SI-4270)
|
| |\ \ \
| | | |
| | | | |
Expanded the reach of value classes.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now extending AnyVal:
- RichInt, RichDouble, etc.
- ArrayOps.ofRef, ofBoolean, etc
- StringAdd
- StringFormat
The rest of it is the changes necessary to enable those.
|
| |\ \ \ \
| |/ / /
|/| | | |
Closes SI-6227
|
| | | | | |
|
| | |/ /
| | |
| | |
| | | |
I added some general hook where one can add validation code before a name conflict involving at least one implicit symbol is reported.
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
The needless abstraction penalty was in full flower in Namers.
I managed to find somewhere else to issue this error, where I
can still just write an error message without tracking down an
enumeration in a separate file and inventing an intermediate
name for the enum member.
|
| |\ \
| | |
| | | |
JavaConversions: Restore source compatibility with 2.9
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Even after the parent change, implicit conversions should still convert
ConcurrentHashMap to concurrent.Map and not to mutable.ConcurrentMap.
I'll include the comment by axel22 which prompting this change (taken
from https://github.com/scala/scala/pull/1172#issuecomment-7928285)
since it is highly informative and links to pull request comments might
not be very stable:
<<
Instead of just testing an implicit conversion to ConcurrentMap, the
test should call ConcurrentMap methods such as putIfAbsent (which
returns an Option[T]) and replace, to see if the correct Scala
concurrent map trait is being resolved.
The problem is that putIfAbsent already exists on juc.ConcurrentMap so
instead of triggering an implicit conversion, a type mismatch error is
output anyway.
And we cannot test that the correct concurrent map trait is returned
using methods like map, flatMap and friends, because concurrent map
traits extends mutable.Map anyway.
For this reason, I recommend to add this to the test:
scala> val a = new java.util.concurrent.ConcurrentHashMap[String,
String]() += (("", ""))
a: scala.collection.concurrent.Map[String,String] = Map("" -> "")
and make sure that the returned map is concurrent.Map, not
mutable.ConcurrentMap (the above += is one of the few methods in
collection that has the return type this.type).
>>
|
| |/
|
|
|
| |
The classic fail of assuming you will only receive a
specific subclass of Type.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Error reporting is moved to ContextErrors to disentangle stuff in Macros.scala.
With logics and error reporting intertwined it was an awful mess.
Exceptions are used for the same reason. Instead of threading failures through
the code polluting it with options/ifs, I outline the success path.
It worked much better for typedMacroBody, but I'm also happy with the resulting
code of macroExpand. To me a major factor towards applicability of exceptions
was that they are short-lived and that there might be max one error per domain,
after which we unconditionally bail.
|
| |\
| |
| | |
more cleanup in Macros.scala
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
| |
Disable @static for the REPL code.
The problem is that there are no companion classes generated for objects
that contain the top-level declarations in the REPL.
When there is no companion class, the selecting a @static field will translate
to a getter call, instead of to a field load.
|
| |
|
|
|
| |
We no longer have multiple canonical signatures for macro implementations,
so it was time to put the List-List-List-based logic to rest.
|
| |\
| |
| | |
SI-5940 impls are no longer in macro def pickles
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The immediate motivator for this change was the desire to keep things simple
during macro expansion.
Here's the story. When you expand a macro, you need to reflectively load
a macro implementation method and invoke it. However private methods in Scala
can sometime have their names mangled, so the reflector has to check multiple
variants of the same name (the normal one and the mangled one).
The problem is that since the previous commit we don't have an access to a
symbol of the macro impl, hence we cannot just use `impl.expandedName` like
we did before. Sure I could duplicate the logic of expandedName, but I have
a better suggestion.
Let's prohibit non-public macro implementations. This doesn't seem to hurt,
and it lets us avoid extra bit of complexity in Macros.scala.
If this measure turns out to be a hassle during the trial period of macros,
non-public macros can always be allowed. In fact, we can even have this feature
back for free when we migrate from Java reflection to Scala reflection for
invoking macro implementations (because Scala reflection knows how to account
for mangled private names). But that's the 2.10.x business.
|
| |\ \
| | |
| | | |
Fixes SI-6214.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
addSynthetics was calling typedStat that caused flushing error buffer. Typically that would result in errors being re-added but addSynthetics was the last thing to run in typedStats.
Instead of adding yet another check I used this as an opportunity to cleanup the once necessary workaround for typing stats. Since we are now chaining buffers of contexts manual handling is no longer necessary.
Review by @odersky (I recall that you were planning to cleanup that part at some point).
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The situation (I don't know how to make partest test this) is
package s
class A ; class S { def f(): A = ??? }
If one compiles this and removes A.class, should references to
class S cause the compiler to explode eagerly and fail to load S,
or explode lazily if and when it needs to know something about A?
This patch takes us from the former strategy to the latter.
Review by @xeno-by.
|
| |\ \ \
| |_|/
|/| | |
Better pattern matcher error message.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For the common case when someone hasn't quite grokked
the significance of lower case in a pattern match. I'd
like to make all the unreachables errors, not warnings,
but there may be a bug or two to clear out first.
class A {
def badEquals(x: Any, y: Any) = x match {
case y => true
case _ => false
}
}
a.scala:3: warning: patterns after a variable pattern cannot match (SLS 8.1.1)
If you intended to match against parameter y of method badEquals, you must use backticks, like: case `y` =>
case y => true
^
a.scala:4: warning: unreachable code due to variable pattern 'y' on line 3
case _ => false
^
two warnings found
|
| |\ \ \
| |/ /
|/| | |
SI-5739 (bis) vals for subpatterns when -g:patmatvars
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To facilitate debugging pattern matches, we store the values for
sub-patterns of extractor (synthetic or user-defined) patterns in local variables.
When performing an optimized build, and when possible, we don't do store but inline them directly.
For soundness, SI-5158, SI-6070, we must always store the values of mutable case class fields.
(Specifying -optimize is the only way to suppress emitting these local variables.
An unoptimized build will always generate them, which was deemed the right default during the meeting.)
(updated flags for t4425 to get consistent runs on optimized and non-optimized partest runs
by always passing -optimize)
|
| |\ \ \
| |_|/
|/| | |
Fixes SI-5687.
|
| | | |
| | |
| | |
| | |
| | | |
Recover from erroneous type alias override to report
more useful error message.
|
| |\ \ \
| |_|/
|/| | |
SI-6040 error on unauthorized extension Dynamic
|
| | | |
| | |
| | |
| | | |
authorization is easy to get: `import language.dynamics`
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The original idea was to support both both TypeTags and ConcreteTypeTags as
context bounds on macro implementations.
Back then TypeTags were the implied default flavor of type tags. Basically
because "TypeTag" is shorter than "ConcreteTypeTag" everyone jumped onto
them and used them everywhere.
That led to problems, because at that time TypeTags could reify unresolved type
parameters ("unresolved" = not having TypeTag annotations for them). This
led to a series of creepy errors, when one forgets to add a context bound
in the middle of a chain of methods that all pass a type tag around, and then
suddenly all the tags turn into pumpkins (because that unlucky method just
reifies TypeRef(NoPrefix, <type parameter symbol>, Nil and passes it down
the chain).
Hence we decided to rename ConcreteTypeTag => TypeTag & TypeTag => AbsTypeTag,
which makes a lot of sense from a reflection point of view.
Unfortunately this broke macros (in a sense), because now everyone writes
TypeTag context bounds on macro implementations, which breaks in trivial
situations like: "def foo[T](x: T) = identity_macro(x)" (the type of x
is not concrete, so macro expansion will emit an error when trying to
materialize the corresponding TypeTag).
Now we restore the broken balance by banning TypeTag from macro impls.
This forces anyone to use AbsTypeTags, and if someone wants to check the input
for presence of abstract types, it's possible to do that manually.
|
| |\ \
| | |
| | | |
SI-6074 disallow implicit enrichment with constructor
|
| | | |
| | |
| | |
| | |
| | | |
When selecting a non-accessible constructor, don't infer a view to
something with an accessible constructor.
|
| |\ \ \
| | | |
| | | | |
Promote unchecked warnings into being emitted by default.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
To make that viable, suppression of unchecked warnings is now available
on a per-type-argument basis. The @unchecked annotation has hereby been
generalized beyond exhaustiveness to mean context-dependent "disable further
compiler checking on this entity." Example of new usage:
def f(x: Any) = x match {
case xs: List[String @unchecked] => xs.head // no warning
case xs: List[Int] => xs.head // unchecked warning
}
It turns out -unchecked has been put to other noisy uses such as
the pattern matcher complaining about its budget like a careworn spouse.
This actually simplified the path forward: I left -unchecked in place
for that and general compatibility, so those warnings can be enabled
as before with -unchecked. The erasure warnings I turned into regular
warnings, subject to suppression by @unchecked.
Review by @odersky.
|
| | |/ /
|/| | |
|
| | | |
| | |
| | |
| | | |
Removes the stubs left out to appease the old starr, fixes macro tests.
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These options were meant to be used to bootstrap macros defined in our codebase
However we can bootstrap perfectly without any additional effort, because
library classpath classloader can delegate to tool classpath classloader to
load macro implementations from starr.
Since then (for several months) this functionality hasn't proven to be useful,
neither anyone on the mailing list or stackoverflow asked questions about it
(even despite it was explicitly mentioned in the "cannot load macro impl"
error message).
Hence I suggest that it is totally unnecessary and should be removed.
|
| |\ \
| | |
| | | |
Fixed SI-5031. Only consider classes when looking for companion class.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
sym.effectiveOwner revealed this piece of inconsistency. companionModule
is fine because similar check is there already.
Review by @paulp.
|
| |\ \ \
| | | |
| | | | |
Closes SI-5882
|
