SI-6331 Avoid typing an If tree with a constant type.

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
Refine equality of Constant types over floating point values.

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.
Test for consistency of Constant#{equals, hashCode}.

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.
Improve Constant#hashCode

 - 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.
A little cleanup along the Any to AnyRef trail.

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.
Fix for SI-6340, error message regression.
Fixes binary repo push for new typesafe repo layouts.

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 #1293 from jsuereth/fix/binary-push

Fixes binary repo push for new typesafe repo layouts.
Fixes SI-6259.  Unable to use typeOf in super call of top-level object.

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.
Fix for SI-6245 with workaround for SI-2296.

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 #1292 from jsuereth/fix/SI-6259

Fixes SI-6259.  Unable to use typeOf in super call of top-level object.
SI-6359 Deep prohibition of templates in value class

This seems to have been the intent of 95d532 / SI-5882.
Merge pull request #1300 from retronym/ticket/6359

SI-6359 Deep prohibition of templates in value class
removes build.newFreeExistential

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.
improvements for reification of free symbols

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.
SI-6323 prohibits reflection against free types

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.
SI-6323 outlaws free types from TypeTag

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-6310 AbsTypeTag => WeakTypeTag

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-6310 redeploys the starr

Updates the starr with the changes introduced by the previous commit.
Cleans up obsolete symbols required by the previous starr.
accommodates pull request feedback