[nomerge] SI-7601 Scaladoc: img elements must have an "alt" attribute

SI-7741: Be more tolerant of absent inner classfiles and non-Scala interface members

…ature

SI-9239 fix java generic signature when traits extend classes

SI-3368 CDATA gets a Node

The Delambdafy phase generates its `FunctionN` subclasses after
the specialization phase. As such, `((x: Int) => x).apply(42)` incurs
boxing.

This commit falls back to the `-Ydelambdafy:inline` in this case.

This is done by running the specialization type map over the
type of the function, and seeing if anything changes. To make this
work robustly, we first need to ensure that the specialization info
transformer has processed all the function types.

This is not a fundamental limitation; we could in principle generate
the specialized code.

A followup change will use `-Ydelambdafy:method` as the basis for
invokedymnamic lambdas. As part of that stream of
work, we will synthesize specialization-aware lambdas, and remove
the fallback to `-Ydelambdafy:inline`.

I have updated some tests that intend to test the delambdafy transform
to avoid use of specialized function types.

…ions-2

SI-8359 Adjust parameter order of accessor method in Delambdafy

Patmat: efficient reasoning about mutual exclusion

…zation

Disable -Ydelambdafy:method for specialized FunctionN

A bare identifier `classOf` in a position wth an expected type of
`Class[_]` was leading to an unpositioned error.

This is due to special treatment of bare `classOf` in `typedIdent`
creating an ephemeral, but unpositioned, `TypeTree`.

This commit positions that tree and tests that the error is
issued at a sensible position.

There is still an irregularity between `classOf` and `Predef.classOf`,
but that seems esoteric enough to leave alone for now.

SI-9273 Avoid unpositioned error for bare classOf

Preserve current behavior (no PCData nodes, only Text)
for 2.11.

The coalescing flag is on if enabled or if source level
is not 2.12 and no flag was supplied.

The subtle change is that adjacent Text nodes are thereby
coalesced. This happens in the presence of CData sections,
but this is at the discretion of the parser anyway.

Also, no PCData nodes are emitted under coalescing, even
if there were no sibling text nodes. That is the correct
behavior: the general idea is that coalescing mode says,
I only want to deal with text.

If a value class has a self declaration

  class V(x: Long) extends AnyVal { self => /* ... */ }

`vClassSymbol.typeOfThis.typeSymbol` is `class Long` in the backend.

The InlineInfo for traits contains a field for the self type of the
trait. This is required for re-writing calls to final trait methods
to the static implementation method: the self type appears in the
impl method signature.

By mistake, the backend was recording the self type of all classes,
not only of traits. In the case of a value class with a self
declaration, this broke the assumption that the self type is always
a class type (not a primitive type).

The simple fix: only record the self type for traits.

Since we're moving to bintray, first centralizing the config of
the repositories we use while bootstrapping a release.

This should not be hardcoded in scala/scala anyway, it's an
implementation detail of our infrastructure, which is defined by
scala/scala-jenkins-infra.

Derive repository info from (jenkins) env vars

SI-3368 Default to coalescing for 2.11

Under -Ydelambdafy:method (the basis of the upcoming "indylambda"
translation for -target:jvm-1.8), an anonymous function is currently
encoded as:

 1. a private method containing the lambda's code
 2. a public, static accessor method that allows access to 1 from
    other classes, namely:
 3. an anonymous class capturing free variables and implementing
    the suitable FunctionN interface.

In our prototypes of indylambda, we do away with 3, instead deferring
creating of this class to JDK8's LambdaMetafactory by way of an
invokedynamic instruction at the point of lambda capture. This
facility can use a private method as the lambda target; access is
mediated by the runtime-provided instance of
`java.lang.invoke.MethodHandles.Lookup` that confers the privelages
of the lambda capture call site to the generated implementation class.
Indeed, The java compiler uses this to emit private lambda body
methods.

However, there are two Scala specific factors that make this
a little troublesome.

First, Scala's optimizer may want to inline the lambda capture
call site into a new enclosing class. In general, this isn't a
safe optimization, as `invokedynamic` instructions have call-site
specific semantics. But we will rely the ability to inline like
this in order to eliminate closures altogether where possible.

Second, to support lambda deserialization, the Java compiler creates
a synthetic method `$dersializeLamda$` in each class that captures
them, just to be able to get the suitable access to spin up an
anoymous class with access to the private method. It only needs
to do this for functional interfaces that extends Serializable,
which is the exception rather than the rule. But in Scala, *every*
function must support serialization, so blindly copying the Java
approach will lead to some code bloat.

I have prototyped a hybrid approach to these challenges: use the
private method directly where it is allowed, but fall back to
using the accessor method in a generic lambda deserializer or
in call sites that have been inlined into a new enclosing class.

However, the most straight forward approach is to simply emit the
lambda bodies as public (with an mangled name and with the SYHTNETIC
flag) and use them in all cases. That is what is done in this commit.

This does moves us one step backwards from the goals of SI-7085,
but it doesn't seem sensible to incur the inconvenience from locking
down one small part of our house when we don't have a plan or the
budget to complete that job.

The REPL has some fancy logic to decompile the bodys of lambdas
(`:javap -fun C#m`) which needed tweaking to accomodate this change.
I haven't tried to make this backwards compatible with the old
encoding as `-Ydelambdafy:method` is still experimental.

It mimics the ant build as closely as necessary to compare the produced
artifacts between the two builds, to build confidence in the transition:

 - all projects are built into the same directories in build/quick
 - include legacy projects: forkjoin, asm, actors
 - TODO: Include forkjoin & asm into library & compiler jars, respectively.

We don't carry over ant's built-in bootstrapping process;
this will be scripted outside of the build, publishing layers locally.

NOTE: the root project cannot be named `scala`:
it shadows the `scala` package in e.g., `projectConsole`.

Override default location for jars to be build/pack/lib. This turned out
to be a bit more involved than I expected. Check the diff for details.

Strip down the -version suffix from jar names.

For now we're trying to mimic Ant's build as closely as possible. Ant does
not embed version numbers in jar names it creates in build/pack/lib
directory.

Add an sbt task that generates .properties files that are packaged
into jars. The properties file contains Scala version in various
formats.

The task is registered as a resource generator so sbt can properly
track generated files and make sure they are included in packaged
jars.

The implementation of generateVersionPropertiesFile contains a note
on arbitrary order of written properties. We could consider using
https://github.com/etiennestuder/java-ordered-properties
to guarantee a stable order. Or simply ditch using Properties class
and generate a String. Our property files are simple enough that
nothing more fancy is needed.

Previously, Project.base was set to ./$name and we tweaked manually the
`baseDirectory` setting to point at `.`. This was confusing sbt and its
plugins. We are setting Project.base to ./src/$name and leave
`baseDirectory` intact (so it will point at `./src/$name`.

Adapt settings that depend on `baseDirectory` accordingly.

Refactor configuration as a subproject into a common method.

Given that `baseDirectory` is pointing at `src/$name`, we don't have to
worry about `sourcesInBase`.

This settings determines location of where class files, jars, and other
build products will go. By default, it's `./build-sbt`. It makes it easier
to compare what Ant and sbt builds do.

Also, changed `SettingKey` to `settingKey`. The latter is a macro that
automatically determines `label` of a setting and takes a description as
argument. Before that, `SettingKey("my desc")` would create a setting key
with `label` set to "my desc". Not what we wanted.

Move most of `commonSettings` to `subprojectSettings` and keep
`commonSettings` truly minimal.

As they are forks of external Java projects, don't document/publish them.
TODO: move them out of the repo

As in ant, pass -g, -source and -target options to javac to get
byte-identical outputs for Java files between Ant and sbt builds.

Put library class files to scaladoc's classpath when documenting the library.
TODO: why is this needed? Bug in scaladoc?

Pass `src/library-aux` to scaladoc using `-doc-no-compile` option.

To mimic ant, output docs into `buildDirectory/scaladoc/$name`.

Mirror ant by disabling docs and publishing tasks in these subprojects.
Class files are included by merging `mappings`: the `package` task
uses it to determine which class files should end up in a jar file.

As suggested in sbt/sbt#1872, specify ScalaInstance manually
and use sbt's launcher as a context for Ivy resolution. This way
we avoid the circular dependency problem described in the issue.

Scaladoc depends on scala-xml, etc, built with the previous stable
version of Scala. This isn't ideal, but we're stuck with this for
now.

We were relying on Ivy to evict the transitive dependency on the
old version of scala-library. However, SBT treats evictions of
scala-library as suspicious and emits a custom warning.

This commit explicitly excludes the transitive dependency so
as to avoid these warnings. It also makes the output of `show update`
a little easier to read.

Let's override `sources` task to return empty collections of sources to
compile. Otherwise, sbt by default would pick up sources in the root
directory which is not what we want.

But sans test.

We talk about bit rot but not about how dust accumulates on
code that hasn't been swept since the last time the furniture
was moved around.

Fix 36 typos (d-f)

…Argument

SI-9253 avoid IndexOutOfBoundsException in TypeMaps.correspondingTypeArgument

SI-9359 Fix InnerClass entry flags for nested Java enums

Spec: Add lost references, cleanup

SI-9206 Fix REPL code indentation

@Local now takes a type parameter: @Local[Nothing] means 1st class
i.e. normal value, @Local[Any] means 2nd class value that cannot
escape its scope.

@Local[T] does the right thing for abstract types.

This allows diffing before and after fixing a code with warning,
to quickly see the particular warning is indeed gone.

- introduce abstract type TL in GenTraversable{Like,Once} and
  [Flat]HashTable
- specialize to Any in Set, List and all subclasses of {Flat}HashTable
  (TODO: the latter is not ideal since we need override in each impl
  because TL/plocal is inherited twice)

Adding (abstract) type LT for @Local macro to collections API (unstable!)