summaryrefslogtreecommitdiff
path: root/test/files/neg
Commit message (Collapse)AuthorAgeFilesLines
* Eliminate breaking relative names in source.Paul Phillips2012-09-143-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These things are killing me. Constructions like package scala.foo.bar.baz import foo.Other DO NOT WORK in general. Such files are not really in the "scala" package, because it is not declared package scala package foo.bar.baz And there is a second problem: using a relative path name means compilation will fail in the presence of a directory of the same name, e.g. % mkdir reflect % scalac src/reflect/scala/reflect/internal/util/Position.scala src/reflect/scala/reflect/internal/util/Position.scala:9: error: object ClassTag is not a member of package reflect import reflect.ClassTag ^ src/reflect/scala/reflect/internal/util/Position.scala:10: error: object base is not a member of package reflect import reflect.base.Attachments ^ As a rule, do not use relative package paths unless you have explicitly imported the path to which you think you are relative. Better yet, don't use them at all. Unfortunately they mostly work because scala variously thinks everything scala.* is in the scala package and/or because you usually aren't bootstrapping and it falls through to an existing version of the class already on the classpath. Making the paths explicit is not a complete solution - in particular, we remain enormously vulnerable to any directory or package called "scala" which isn't ours - but it greatly limts the severity of the problem.
* Merge pull request #1295 from scalamacros/ticket/6323Eugene Burmako2012-09-1417-28/+59
|\ | | | | improvements for type tags
| * SI-6310 AbsTypeTag => WeakTypeTagEugene Burmako2012-09-1414-28/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new name for AbsTypeTag was a matter of a lengthy discussion: http://groups.google.com/group/scala-internals/browse_thread/thread/fb2007e61b505c4d I couldn't decide until having fixed SI-6323 today, which is about trying to reflect against a local class using typeOf. The problem with local classes is that they aren't pickled, so their metadata isn't preserved between Scala compilation runs. Sure, we can restore some of that metadata with Java reflection, but you get the idea. Before today typeOf of a local class created a free type, a synthetic symbol, with a bunch of synthetic children that remember the metadata, effectively creating a mini symbol table. That might be useful at time, but the problem is that this free type cannot be reflected, because the global symbol table of Scala reflection doesn't know about its mini symbol table. And then it struck me. It's not the presence of abs types (type parameters and abs type members) that differentiates arbitrary type tags from good type tags. It's the presence of types that don't map well on the runtime world - ones that can't be used to instantiate values, ones that can't be reflected. So we just need a name for these types. Phantom types are compile-time only concept, whereas our types can have partial correspondence with the runtime. "Weak types" sound more or less okish, so let's try them out.
| * SI-6323 outlaws free types from TypeTagEugene Burmako2012-09-143-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Free types are no longer acceptable in normal type tags. Like type parameters or abstract type members they don't map on any real type, therefore I think this is a justified change. The main reason for doing is this is to prohibit people from using `typeOf` on local classes. Sure, the guard introduced in the previous commit will raise runtime errors about that, but this commit provides static checking. Those especially persistent might use `absTypeOf` and then try to play around with the weak type it returns, but that's advanced usage scenario, and I don't worry much about it. Bottom line: `typeOf` should just work. Things that work with additional effort should be explicitly marked as such.
* | Merge pull request #1272 from paulp/issue/6340Josh Suereth2012-09-142-0/+31
|\ \ | |/ |/| Fix for SI-6340, error message regression.
| * Fix for SI-6340, error message regression.Paul Phillips2012-09-122-0/+31
| |
* | Merge pull request #1300 from retronym/ticket/6359Josh Suereth2012-09-132-0/+15
|\ \ | | | | | | SI-6359 Deep prohibition of templates in value class
| * | SI-6359 Deep prohibition of templates in value classJason Zaugg2012-09-142-0/+15
| |/ | | | | | | This seems to have been the intent of 95d532 / SI-5882.
* | Better error message for pattern arity errors.Paul Phillips2012-09-123-1/+11
| | | | | | | | | | | | Because friends don't tell friends: "wrong number of arguments for <none>"
* | Merge remote-tracking branch 'origin/2.10.x' into fix-duration-issues-RKRoland2012-09-1219-5/+192
|\ \
| * | Avoid spurious warning for `def foo = x.foo`.Jason Zaugg2012-09-112-6/+27
| |/ | | | | | | Followup to SI-6276.
| * Merge pull request #1274 from retronym/ticket/6335Grzegorz Kossakowski2012-09-112-0/+16
| |\ | | | | | | SI-6335 More precise location of the implicit class synthetic method.
| | * More tests for SI-6335.Jason Zaugg2012-09-092-0/+16
| | |
| * | Merge pull request #1284 from retronym/topic/deprecated-inheritanceGrzegorz Kossakowski2012-09-116-0/+55
| |\ \ | | | | | | | | SI-6162 Adds private[scala] @deprecatedInheritance/@deprecatedOverriding
| | * | Rescues @deprecated{Inheritance, Overriding}Jason Zaugg2012-09-114-6/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While they ought to be generalized to aribirary modifier changes before being offered in the standard library, the opportunity to use them in 2.10 is too important to pass up. So for now, they're private[scala]. En route: - made the error messages more concise - fix positioning of inheritance error - improve test coverage
| | * | SI-6162 Adds @deprecatedInheritance/@deprecatedOverridingSimon Ochsenreither2012-09-106-0/+22
| | |/ | | | | | | | | | | | | | | | | | | | | | These annotations are meant to warn from inheriting a class or from overriding a member, due to the reasons given in `msg`. The naming and placement of the methods is in line with @deprecated and @deprecatedName.
| * | Merge pull request #1275 from retronym/ticket/6276Grzegorz Kossakowski2012-09-115-2/+45
| |\ \ | | | | | | | | SI-6276 Warn on def or val that trivially loops infinitely
| | * | SI-6276 Warn on def or val that trivially loops infinitelyJason Zaugg2012-09-095-2/+45
| | |/
| * | Merge pull request #1168 from retronym/ticket/6258-2Josh Suereth2012-09-062-0/+41
| |\ \ | | | | | | | | SI-6258 Reject partial funs with undefined param types
| | * | SI-6258 Reject partial funs with undefined param typesJason Zaugg2012-08-232-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | More fix for invalid companions.Paul Phillips2012-09-054-3/+14
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* / | restrict Deadline to finite durations (would have to throw otherwise)Roland2012-09-122-0/+23
|/ /
* | Merge pull request #1231 from paulp/issue/6273Josh Suereth2012-09-021-1/+1
|\ \ | | | | | | Fix for SI-6273, repl string interpolation.
| * | Fix for SI-6273, repl string interpolation.Paul Phillips2012-09-011-1/+1
| | | | | | | | | | | | | | | | | | As usual the hard part is tracing through all the needless abstraction. Begone, 25 layers of parsing error issuing methods!
* | | Better errors for Any/AnyRef issues.Paul Phillips2012-09-016-6/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Fix for SI-6263, futile adaptation.Paul Phillips2012-09-012-0/+12
| | | | | | | | | | | | | | | | | | 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."
* | | Suppressed 'possible cause' mis-warning.Paul Phillips2012-09-012-0/+13
|/ / | | | | | | | | I have seen this warning a bunch of times and it has not yet been close to right.
* | Merge pull request #1201 from axel22/issue/4581Josh Suereth2012-09-014-1/+33
|\ \ | | | | | | Fix SI-4581.
| * | Fix SI-4581.Aleksandar Prokopec2012-08-274-1/+33
| | | | | | | | | | | | | | | | | | | | | Specifically, the final flag on the generated static field is no longer ommitted. Fix 2 failing test-cases.
* | | More useful -Xlog-implicits output.Jason Zaugg2012-09-013-0/+25
| | | | | | | | | | | | | | | The test exercises the most important case, when implicits are invalidated through shadowing. (See SI-4270)
* | | Merge pull request #1213 from paulp/topic/anyvalJosh Suereth2012-08-302-6/+0
|\ \ \ | | | | | | | | Expanded the reach of value classes.
| * | | Expanded the reach of value classes.Paul Phillips2012-08-292-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now extending AnyVal: - RichInt, RichDouble, etc. - ArrayOps.ofRef, ofBoolean, etc - StringAdd - StringFormat The rest of it is the changes necessary to enable those.
* | | | Merge pull request #1209 from odersky/ticket/6227Josh Suereth2012-08-302-0/+10
|\ \ \ \ | |/ / / |/| | | Closes SI-6227
| * | | Added/fixed test files for SI-6227Martin Odersky2012-08-291-0/+4
| | | |
| * | | Closes SI-6227Martin Odersky2012-08-291-0/+6
| |/ / | | | | | | | | | I added some general hook where one can add validation code before a name conflict involving at least one implicit symbol is reported.
* / / Fix for SI-6283, no abstract value classes.Paul Phillips2012-08-282-0/+5
|/ / | | | | | | | | | | | | | | 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.
* | Merge pull request #1172 from Blaisorblade/topic/deprecated-conversionJosh Suereth2012-08-232-0/+16
|\ \ | | | | | | JavaConversions: Restore source compatibility with 2.9
| * | Ensure implicit conversions to concurrent map are unambiguousPaolo Giarrusso2012-08-222-0/+16
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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). >>
* / Fix for SI-6264, crash in checkCheckable.Paul Phillips2012-08-213-0/+11
|/ | | | | The classic fail of assuming you will only receive a specific subclass of Type.
* cleanup for macroExpandEugene Burmako2012-08-184-1/+1
| | | | | | | | | | | | | 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.
* Merge pull request #1151 from scalamacros/topic/cleanupEugene Burmako2012-08-179-20/+26
|\ | | | | more cleanup in Macros.scala
| * more cleanup for typedMacroBodyEugene Burmako2012-08-175-11/+17
| |
| * shaves more than 150 lines off typedMacroBodyEugene Burmako2012-08-174-9/+9
| |
* | Fixes SI-6189.Aleksandar Prokopec2012-08-171-0/+6
|/ | | | | | | | 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.
* macroImplSigs => macroImplSigEugene Burmako2012-08-151-0/+1
| | | | | We no longer have multiple canonical signatures for macro implementations, so it was time to put the List-List-List-based logic to rest.
* Merge pull request #1101 from scalamacros/ticket/5940Josh Suereth2012-08-144-0/+17
|\ | | | | SI-5940 impls are no longer in macro def pickles
| * macro implementations must be publicEugene Burmako2012-08-134-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #1125 from hubertp/2.10.x-issue/6214Josh Suereth2012-08-132-0/+11
|\ \ | | | | | | Fixes SI-6214.
| * | Fixes SI-6214.Hubert Plociniczak2012-08-122-0/+11
| | | | | | | | | | | | | | | | | | | | | 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).
* | | More resilience to missing classes.Paul Phillips2012-08-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-31 20:40:48 +0000