summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* SI-5692 better error messageEugene Burmako2012-09-189-1/+33
| | | | | | Doesn't fix the underlying issue with macros and type inference, but at least now the error message says exactly what needs to be done to make the error go away.
* Merge pull request #1321 from namin/apply-dynamic-sugarGrzegorz Kossakowski2012-09-175-6/+40
|\ | | | | Fixed SI-6353: applyDynamic with sugared applications
| * Fixed SI-6353: applyDynamic with sugared applicationsamin2012-09-175-6/+40
| | | | | | | | | | | | | | - Accept sugared applications such as x(1) if x implements Dynamic, so x(1) gets re-written to x.apply(1). - When picking a dynamic rewrite for x.apply(1), favor applyDynamic instead of the default selectDynamic.
* | Merge pull request #1320 from scalamacros/topic/is-implicitPaul Phillips2012-09-173-4/+21
|\ \ | | | | | | moves isImplicit from TermSymbol to Symbol
| * | moves isImplicit from TermSymbol to SymbolEugene Burmako2012-09-163-4/+21
| | | | | | | | | | | | Because classes can also be implicit.
* | | Merge pull request #1322 from paulp/topic/emptyArrayJosh Suereth2012-09-1713-75/+16
|\ \ \ | | | | | | | | Topic/empty array
| * | | Revert "Added constant empty array to the companion objects."Paul Phillips2012-09-1610-73/+4
| | | | | | | | | | | | | | | | This reverts most of commit 9d84e89d2 .
| * | | Moved constant empty arrays into Array companion.Paul Phillips2012-09-163-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reminds me of at least one reason I didn't put them here before: I don't feel like I can return these from calls to Array.empty, because there's no way of knowing whether anyone has been relying upon this property: scala> Array.empty[Byte] eq Array.empty[Byte] res0: Boolean = false Since that is exactly the property I need to alter. The test above is true in all the "real" collections, which is all the more reason to be concerned that someone might be using empty arrays as not-equivalent sentinels. I can still move them here, but it'd be a lot better if array creation could use them - not only def empty but def apply[T: ClassTag](xs: T*): Array[T] which probably creates millions of empty arrays where one would do in almost every case.
* | | | Merge pull request #1318 from odersky/ticket/6336Josh Suereth2012-09-173-4/+22
|\ \ \ \ | | | | | | | | | | SI-6336 Disallows value types in structuralal refinements
| * | | | SI-6336 Disallows value types in structuralal refinementsMartin Odersky2012-09-163-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | Structural refinements already have a number of restrictions, e.g. cannot refer to type parameters of enclosing classes. We need to disallow value classes as well.
* | | | | Merge pull request #1308 from soc/SI-4478Josh Suereth2012-09-173-15/+15
|\ \ \ \ \ | |_|/ / / |/| | | | SI-4478 Replaces wrt with (hopefully) slightly improved wording.
| * | | | SI-4478 Replaces wrt with (hopefully) slightly improved wording.Simon Ochsenreither2012-09-153-15/+15
| | | | |
* | | | | Merge pull request #1309 from paulp/210-no-relative-pathsPaul Phillips2012-09-16118-262/+238
|\ \ \ \ \ | |_|_|_|/ |/| | | | More relative path elimination.
| * | | | More relative path elimination.Paul Phillips2012-09-15118-262/+238
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some names I missed in 55b609458fd . How one might know when one is done: mkdir scratch && cd scratch mkdir annotation beans collection compat concurrent io \ math parallel ref reflect runtime scala sys testing \ text tools util xml scalac $(find ../src/library -name '*.scala') Until recently that would fail with about a billion errors. When it compiles, that's when you're done. And that's where this commit takes us, for src/library at least.
* | | | | Merge pull request #1310 from scalamacros/ticket/6329Eugene Burmako2012-09-168-0/+59
|\ \ \ \ \ | |_|_|_|/ |/| | | | test suite for SI-6329
| * | | | test suite for SI-6329Eugene Burmako2012-09-068-0/+59
| | | | |
* | | | | Merge pull request #1319 from paulp/eugene-pullreq-1306Paul Phillips2012-09-162-1/+4
|\ \ \ \ \ | | | | | | | | | | | | Eugene pullreq 1306
| * | | | | Merge commit 'refs/pull/1306/head' into 2.10.xPaul Phillips2012-09-162-1/+4
|/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | * commit 'refs/pull/1306/head': SI-6356 reflection now supports Java annotations
| * | | | | SI-6356 reflection now supports Java annotationsEugene Burmako2012-09-166-2/+75
| | |/ / / | |/| | | | | | | | | | | | | | | | | | Except for one thingie: java enums are currently not understood by Scala reflection, hence they aren't yet supported in annotations.
* | | | | Merge pull request #1314 from paulp/pullreq-1306Paul Phillips2012-09-167-15/+111
|\ \ \ \ \ | |_|_|_|/ |/| | | | Pullreq 1306
| * | | | Reworking of annotation arg parser.Paul Phillips2012-09-162-37/+57
| | | | | | | | | | | | | | | | | | | | | | | | | Paradoxically it has less duplication but is longer. That's the way it goes sometimes.
| * | | | SI-6356 reflection now supports Java annotationsEugene Burmako2012-09-156-7/+83
| |/ / / | | | | | | | | | | | | | | | | Except for one thingie: java enums are currently not understood by Scala reflection, hence they aren't yet supported in annotations.
* | | | Merge pull request #1311 from scalamacros/topic/magicEugene Burmako2012-09-168-55/+76
|\ \ \ \ | |/ / / |/| | | deals with magic
| * | | extinguishes some magic from scalacEugene Burmako2012-09-168-50/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | First I was quite skeptical about Paul's dislike of names that contain "magic" in them. However when I went through the code and tried to think of "magic"-less alternatives, it became apparent that resulting names are much better than the originals. Therefore I removed all the magic from reflection and macros. Feels good.
| * | | magic classes are no longer entered twiceEugene Burmako2012-09-122-13/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously magic classes such as NothingClass were entered twice into root mirrors of java universes. No idea how this managed not to blow up. Now this problem is fixed. Also, as usual when I gain understanding of something, this allows to come up with better names. `magicSymbols` are now split into three collections: `magicallyEnteredClasses`, `magicallyEnteredMethods` and `magicallyHijackedSymbols`.
* | | | Merge pull request #1302 from scalamacros/topic/reflectionEugene Burmako2012-09-14121-368/+340
|\ \ \ \ | | | | | | | | | | cleaning up reflection
| * | | | SI-6362 & SI-5924 removes caches in the macro APIEugene Burmako2012-09-153-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As recent experience shows, it's hardly possible to provide a global cache that persists between compilation runs: http://groups.google.com/group/scala-ide-user/browse_thread/thread/b1cab5588ff21f7f. Therefore I think we need to remove Context.globalCache. Speaking of a per-run cache, it looks like Context.cache can be to a certain extent emulated with attachments. Otherwise, one could write a JVM-wide static cache weakly indexed by compilation run instances (that are available via c.currentRun). For now I think we need to remove both caches. If macro writers really need that functionality, we could come up with a well-thought API later.
| * | | | SI-6342 cleans up toolbox APIEugene Burmako2012-09-1587-122/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) parseExpr => parse 2) runExpr => eval 3) Introduces compile(Tree): () => Any, since it has frequent uses
| * | | | SI-6360 revises naming of AnnotationInfo and its membersEugene Burmako2012-09-1518-128/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Internal face of AnnotationInfos is bound by backward compatibility with compiler plugins and possibly SBT, but the public face can be shaped in whatever fashion we like. Hence I cleaned up the names: AnnotationInfo itself got renamed to just Annotation, AnnotArgs got renamed to just Arguments and so on.
| * | | | SI-6372 cleans up the API of AttachmentsEugene Burmako2012-09-1511-23/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously Attachments allowed multiple attachments that correspond to the same attachment type. This created a potential for confusion, given that Attachments.get only searched for the first attachment of a given type. Hence I made Attachments.add overwrite previously existing attachments of a given type and renamed it to Attachments.update, so that the name suits the intention better.
| * | | | SI-6371 adds comments for Trees#UnApplyEugene Burmako2012-09-151-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately we cannot remove this node, because it's emitted by typer and, therefore, can be seen by macros and pickled as a part of annotations. Therefore we have to expose UnApply in the API. Experimental status of scala-reflect.jar will give us some leeway to evict it from the compiler (and consequently from the API) by 2.10.1.
| * | | | SI-6369 removes Type.narrow from the APIEugene Burmako2012-09-141-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looks like narrow doesn't help us solve the problem it was intended for: http://groups.google.com/group/scala-user/browse_thread/thread/9f5d55ebfcc8e60a I believe we'll be on a safer side if we remove it until it's really needed.
| * | | | SI-6365 removes Symbol.hasAnnotation from the APIEugene Burmako2012-09-141-5/+0
| | | | | | | | | | | | | | | | | | | | It's clearly redundant and also is susceptible to initialize-based bugs.
| * | | | SI-6373 removes Trees#ApplyDynamic from the APIEugene Burmako2012-09-146-52/+10
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduced by erasure - therefore it can be seen neither by macros, nor by runtime reflection. Despite never being pickled, ApplyDynamic is supported by unpickler so I couldn't move it exclusively to scala-compiler.jar. Figuring out the mysterious reason for pickling ApplyDynamic is left to future work.
* | | | Merge pull request #1290 from retronym/ticket/no-implicit-to-anyrefPaul Phillips2012-09-145-12/+58
|\ \ \ \ | | | | | | | | | | A little cleanup along the Any to AnyRef trail.
| * | | | A little cleanup along the Any to AnyRef trail.Jason Zaugg2012-09-115-12/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to 35316be and d3f879a. - Remove obsolete comments and replace them with a test. - Don't emit error addendum unless we know we're dealing with a value class.
* | | | | Merge pull request #1299 from namin/si-6245Paul Phillips2012-09-1412-8/+40
|\ \ \ \ \ | | | | | | | | | | | | Fix for SI-6245 with workaround for SI-2296.
| * | | | | Fix for SI-6245 with workaround for SI-2296.amin2012-09-1312-8/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | protected/super accessor issue: Don't subvert the creation of the standard protected accessor with the java interop accessor. For SI-2296, the compiler emits an error instead of causing an illegal access error at runtime.
* | | | | | Merge pull request #1304 from paulp/topic/empty-array-optimizationJosh Suereth2012-09-1413-6/+83
|\ \ \ \ \ \ | |_|_|/ / / |/| | | | | Topic/empty array optimization
| * | | | | Optimization in ZipArchive.Paul Phillips2012-09-142-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's that empty array. When compiling "trait Foo", this took me from allocating 44,410 empty arrays to allocating 383 of them.
| * | | | | Added constant empty array to the companion objects.Paul Phillips2012-09-1411-7/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because there are lots of times when you just need an array and shouldn't have to allocate one every time or pick a random spot to cache yet another empty array.
* | | | | | Merge pull request #1303 from paulp/210-relative-namesEugene Burmako2012-09-14395-850/+837
|\ \ \ \ \ \ | |/ / / / / |/| | | | | Eliminate breaking relative names in source.
| * | | | | Eliminate breaking relative names in source.Paul Phillips2012-09-14395-850/+837
|/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | "Hot fix" for broken build.Paul Phillips2012-09-141-1/+1
| | | | | | | | | | | | | | | | | | | | Two pull requests crossed in the night.
* | | | | Merge pull request #1271 from retronym/ticket/6331Josh Suereth2012-09-147-4/+201
|\ \ \ \ \ | | | | | | | | | | | | SI-6331 deconst If type / refine equality of floating point Constant types.
| * | | | | Improve Constant#hashCodeJason Zaugg2012-09-091-11/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Incorporate `tag`, which is considered by equals, to reduce collisions. - Use the result of floatToRawIntBits(value) / doubleToRawLongBits(value), rather than value. This wasn't strictly necessary as (0d.## == (-0d).##) but this is more obviously correct.
| * | | | | Test for consistency of Constant#{equals, hashCode}.Jason Zaugg2012-09-091-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the examples I've constructed, they are consistent, but I put this down to good luck, rather than good management. The next commit will address this.
| * | | | | Refine equality of Constant types over floating point values.Jason Zaugg2012-09-083-2/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The constant types for 0d and -0d should not be equal. This is implemented by checking equality of the result of doubleToRawLongBits / floatToRawIntBits, which also correctly considers two NaNs of the same flavour to be equal. Followup to SI-6331.
| * | | | | SI-6331 Avoid typing an If tree with a constant type.Jason Zaugg2012-09-084-1/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fast path in typedIf added in 8552740b avoided lubbing the if/else branch types if they are identical, but this fails to deconst the type. This could lead to the entire if expression being replaced by a constant. Also introduces a new tool in partest for nicer checkfiles. // in Test.scala trace(if (t) -0d else 0d) // in Test.check trace> if (Test.this.t) -0.0 else 0.0 res: Double = -0.0
* | | | | | Merge pull request #1301 from paulp/clone-parensJosh Suereth2012-09-146-6/+6
|\ \ \ \ \ \ | | | | | | | | | | | | | | Made 'def clone()' consistent with parens everywhere.
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 13:30:51 +0000