summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* 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 #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.
| * | | | Made 'def clone()' consistent with parens everywhere.Paul Phillips2012-09-146-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the reference of others, ack --files-with-matches 'def clone[:\s]' src is how you might find out who needs fixing.
* | | | | Merge pull request #1281 from jsuereth/fix/SI-4813Josh Suereth2012-09-147-6/+77
|\ \ \ \ \ | | | | | | | | | | | | Fix SI-4813 - Clone doesn't work on LinkedList.
| * | | | | Fix SI-4813 - Clone doesn't work on LinkedList.Josh Suereth2012-09-147-6/+77
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | * Added extensive test for clone across all standard mutable collections * Fixed clone implementations when needed so they work.
* | | | | Merge pull request #1295 from scalamacros/ticket/6323Eugene Burmako2012-09-14116-443/+489
|\ \ \ \ \ | | | | | | | | | | | | improvements for type tags
| * | | | | accommodates pull request feedbackEugene Burmako2012-09-142-27/+27
| | | | | |
| * | | | | SI-6310 redeploys the starrEugene Burmako2012-09-148-15/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updates the starr with the changes introduced by the previous commit. Cleans up obsolete symbols required by the previous starr.
| * | | | | SI-6310 AbsTypeTag => WeakTypeTagEugene Burmako2012-09-1490-268/+277
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-149-6/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | SI-6323 prohibits reflection against free typesEugene Burmako2012-09-143-3/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the use cases for free types is reification of local classes. The result is very seamless. Despite that local classes are not pickled, free types recreated the symbols referenced by local classes, so that we get our own symbol table, which can be analyzed with usual precision of pickled symbols and types. However when we try to use those symbols for reflection, we hit a problem. Scala runtime reflection uses its own mechanism for dealing with non-pickled types, which is incompatible with mini symbol tables used in free types. Therefore to prevent confusion, I prohibit using those symbols for reflection.
| * | | | | improvements for reification of free symbolsEugene Burmako2012-09-1418-125/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) Free symbols no longer carry signatures in their constructors. Previously to reify a free symbol (i.e. to generate a ValDef that creates it) one had to reify sym.info first. However reification of sym.info might lead to unexpected side effects, including stack overflows, if reification of sym.info recursively required reifying sym itself. Now it's not a problem. First we reify a "header" of a free symbol by emitting something like: val free$Foo1 = build.newFreeTerm("Foo", Foo.this, NoFlags)` Afterwards, when doing code generation for the reification symbol table, we populate free symbols by inserting calls to `build.setTypeSignature($sym.info)` This techniques transforms recursion into memoized iteration, because even if reifying sym.info indirectly requires reification of sym itself, we remember that we already reified sym and simply return things like Ident(free$Foo1). 2) Unfortunately I haven't been able to get rid of recursion completely. Since some symbols (e.g. local classes) aren't pickled, we need to recreate them during reification (this is necessary e.g. to reify RefinedTypes). Reifier uses a special function, named `reifySymDef`, for that purpose. Here's an example of how it works: val symdef$_1 = build.newNestedSymbol(free$U1, newTypeName("_"), NoPosition, DEFERRED | PARAM, false); `reifySymDef` expands into a call to `newNestedSymbol`, which requires an owner This essentially turns `reifySymDef` into a recursion of `reifySymDef` calls, so that the entire owner chain get reified. This is an implementation strategy that was employed in the first revision of the reifier written by Martin, and personally I have no clue whether it's really necessary to reify the parents. I leave this as a future work. 3) When working with free symbols, it's necessary to attach free symbols to their reification. This is required in obscure nested reification scenarios, when a symbol that was free for an inner reifee is no longer free for an outer reifee. In that case we need to remove that free symbol from the symbol table of the inner reification. Back then we didn't have tree attachments, so I had to introduce a phantom "value" parameter for `newFreeType` to keep track of the original symbols for free types. Now when we have attachments, this is no longer necessary and allowed me to clean up the code.
| * | | | | removes build.newFreeExistentialEugene Burmako2012-09-146-24/+4
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | build.newFreeType does exactly the same, so we don't have a need in two different methods. Type parameters and existentially bound syms can later be distinguished using flags.
* | | | | Merge pull request #1272 from paulp/issue/6340Josh Suereth2012-09-143-1/+31
|\ \ \ \ \ | |/ / / / |/| | | | Fix for SI-6340, error message regression.
| * | | | Fix for SI-6340, error message regression.Paul Phillips2012-09-123-1/+31
| | |_|/ | |/| |
* | | | Merge pull request #1300 from retronym/ticket/6359Josh Suereth2012-09-133-8/+24
|\ \ \ \ | | | | | | | | | | SI-6359 Deep prohibition of templates in value class
| * | | | SI-6359 Deep prohibition of templates in value classJason Zaugg2012-09-143-8/+24
| |/ / / | | | | | | | | | | | | This seems to have been the intent of 95d532 / SI-5882.
* | | | Merge pull request #1292 from jsuereth/fix/SI-6259Josh Suereth2012-09-136-67/+156
|\ \ \ \ | |_|/ / |/| | | Fixes SI-6259. Unable to use typeOf in super call of top-level object.
| * | | Fixes SI-6259. Unable to use typeOf in super call of top-level object.Josh Suereth2012-09-136-67/+156
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | This works around the issue of the inability to use classOf for top-level object classes by inventing a new anonymous class and instantiating it just to grab its class. Since the class is a nested type of the top-level object it'll be in the same classloader unless some kind of evil behavior is afoot. This patch should be undone if ever SI-2453 ever gets fixed, or we wind up with a direct way to grab the class of an object.
* | | Merge pull request #1293 from jsuereth/fix/binary-pushJosh Suereth2012-09-132-7/+10
|\ \ \ | | | | | | | | Fixes binary repo push for new typesafe repo layouts.
| * | | Fixes binary repo push for new typesafe repo layouts.Josh Suereth2012-09-132-7/+10
|/ / / | | | | | | | | | | | | | | | | | | | | | This adds a new/fixed push.jar and adapts the binary-repo-lib script to use different URLs for pulling than pushing. This also adjustst the script to attempt the backup repo in case new artifacts haven't synched to the fast/stable repository.
* | | Merge pull request #1294 from paulp/issue/6367Josh Suereth2012-09-132-13/+51
|\ \ \ | | | | | | | | Fix for SI-6367, exponential time in inference.
| * | | Fix for SI-6367, exponential time in inference.Paul Phillips2012-09-122-13/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This pathology is not new - it can be witnessed in 2.9, where compiling the test case enclosed with this ticket with -Yinfer-debug will print a line with (pinky to lips) one million type parameters. 1048576 actually, aka 2^20. But in 2.9 we were somehow getting away with creating the list, presumably by not spending much time looking at it. Somewhere between there and M1, that changed. I cut it off at the knees - don't create a list of one million upper bound constraints when 1 will suffice. It would not be too surprising if this proves to be a boon for performance.
* | | | Merge pull request #1296 from paulp/210-errors-and-treesJosh Suereth2012-09-1314-26/+100
|\ \ \ \ | | | | | | | | | | 210 errors and trees
| * | | | Better error message for pattern arity errors.Paul Phillips2012-09-128-14/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because friends don't tell friends: "wrong number of arguments for <none>"
| * | | | Rescued TreeBuilder from the parser.Paul Phillips2012-09-123-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For too long, Tree Builder has ruled over those who would like to build their own trees. Today marks the start of a new era. Trees are for building, not for parsers to hoard. It's in Global now. The particular motivation is exposing makeNew, and I also added makeAnonymousNew, so rather than this... Apply(Select( Block(List(ClassDef( Modifiers(scala.tools.nsc.symtab.Flags.FINAL), tpnme.ANON_CLASS_NAME, Nil, Template(List(Ident(definitions.AnyRefClass)), emptyValDef, List( DefDef(NoMods, nme.CONSTRUCTOR, Nil, List(Nil), TypeTree(), Block( List(Apply(Select(Super(This(tpnme.EMPTY), tpnme.EMPTY), nme.CONSTRUCTOR), Nil)), Literal(Constant(())) )))))), Apply(Select(New(Ident(tpnme.ANON_CLASS_NAME)), nme.CONSTRUCTOR), Nil)) , sn.GetClass), Nil) We can write this. Apply(Select(makeAnonymousNew(Nil), nme.getClass_), Nil)
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-16 03:04:17 +0000