GitLab

This removes some duplication from the README that is already found in
the manual.

Using mkdocs (https://www.mkdocs.org/) allows us to decouple
documentation from the website, in turn allowing us to include
documentation directly into this project.

There's still plenty of documentation to port over, but the current
implementation should be a good starting point.

As part of these changes we also change the CI config so certain tests
and lints only run when necessary, including documentation lints. This
cuts down the amount of redundant builds.

This patches the libffi and libffi-sys crates to use the changes
discussed in https://github.com/tov/libffi-sys-rs/pull/37. This removes
the dependencies on bindgen and libclang, making the installation
process easier and faster.

All Make files have been merged into a single top-level Makefile, which
in turn has been cleaned up. The CLI has also been revamped

== Easier installation process

The installation process has also been simplified into two steps:

    make build
    make install

If files need to be installed in a different location, such as a
packaging jail/chroot, you can run the following:

    make build
    make install DESTDIR=example/directory

We also support the PREFIX variable better now. By default DESTDIR is
set to PREFIX, but you can also set them separately. This way you can
customise where the compiler will look for source files using PREFIX,
while still being able to install the files into a (temporary) directory
using DESTDIR. For example:

    make build
    make install PREFIX=/usr/local DESTDIR=/tmp/package-chroot

== Removal of pre-compiled packages

As part of these changes, we stop providing pre-compiled binaries in the
S3 bucket releases.inko-lang.org. This is discussed in
#218, but in short:

1. Few users are likely to use and benefit from these pre-compiled
   binaries.
2. Because of the compile-from-source fallback you still have to install
   all compile-time dependencies.
3. Focusing on package managers (e.g. including Inko in the AUR) is more
   useful.
4. The compiler packages may stop working in the future, if any of the
   OS' decide to change things such that previously compiled binaries
   have to be recompiled.
5. All of this requires a fair amount of complexity on our end, with
   little to no benefit.

== New CLI

This adds a new "inko" executable written in Rust, replacing the
"inko-test", "inkoc", and "inko" Ruby executables, and the "ivm"
executable.

This new executable uses sub-commands for building Inko source files,
running tests, etc. This executable has various paths, such as the path
to the compiler, compiled into itself. This ensures that the "inko"
executable always uses the correct version of the compiler, runtime,
etc.

Usage of the new CLI is as follows:

    inko test.inko          # Compiles and runs test.inko
    inko run test.inko      # Same thing
    inko run test.ibi       # Run a bytecode image
    inko build test.inko    # Just compiles test.inko
    inko test               # Runs all unit tests in ./tests/test

Since the compiler is still written in Ruby, the "inko" executable will
spawn a sub-process to run the compiler. The VM is run in the same
process as the CLI.

To make developing the CLI a bit easier, we now use Cargo workspaces to
separate the VM (= libinko) and the CLI.

This fixes various Immix related bugs and makes some improvements to the
collector's performance.

Bug fixes
---------

The following bugs have been fixed:

1. Evacuating required one or more fragmented blocks, which were set
   based on histogram statistics. These statistics were only populated
   when there were one or more fragmented blocks. This resulted in
   evacuating never happening.

   Evacuating now happens if the previous collection increased the
   allocation threshold.

2. The fragmentation status of a block was never cleared after a
   collection. This could result in an increase of fragmentation if the
   collector statistics deemed evacuating to not be needed.

3. The remembered set using a HashSet meant that updating forward
   pointers in the remembered set would result in duplicate entries, as
   the hash codes would be different.

4. Objects promoted to the mature generation would not be remembered if
   they contained any young pointers ...

The use of AtomicU16 requires Rust 1.34 or newer, as it's only available
when using nightly Rust on older versions.

1.31 introduced Rust 2018, not 1.30.

This replaces the VM dependency on std::intrinsics with a dependency on
std::arch. The std::arch module provides the means to perform CPU
prefetching, but without having to use Rust nightly.

This means we can finally remove any traces of nightly-only features,
including those used for parking_lot (which weren't very useful to begin
with).

All of this means you can now build the VM on stable Rust, while still
being able to benefit from CPU prefetching.

This should make it a bit easier to install the compiler on systems with
slightly older versions of Ruby, such as Debian stretch.

This all in preparation for the upcoming Inko website.

Using "var" is a bit confusing because one might read it as "variable"
opposed to something along the lines of "mutable variable". Using "let
mut" makes it more clear that we're defining a mutable variable, it also
ensures both definitions always start with the same keyword.

The compiler now embraces prototype OO more, removing any mentions to
"classes", instead providing a simple "object" keyword. This keyword on
the outside behaves the same, but the underlying code/behaviour is much
more straightforward. For example, this:

    object Person {
      fn init(name: String) {
        let @name = name
      }
    }

Is (roughly) compiled down to this:

    let Person = Object.new

    fn(self) {
      fn new(name: String) {
        let instance = prototype.new

        instance.init(name)

        instance
      }

      fn init(name: String) {
        let @name = name
      }
    }.call(Person)

Here "Object.new" creates an empty object with its prototype set to
"Object". In this setup there are no class methods, but I actually quite
like this. Since you can define methods directly in a module there isn't
really a good reason to support class methods.

One big benefit of this approach is that bootstrapping is much simpler,
and the compiler can more easily infer types. I personally also find it
much easier to reason about objects when you have _just_ objects and
methods, instead of also having classes and meta classes.

With this also comes the decision to expose prototypes more to the
language. For example, Object will respond to the "prototype" message
instead of responding to some kind of "class" message.

Finally, in this commit the compiler is also changed to mostly rely on
message sending for defining core constructs. For example, when you
define a trait like so:

    trait ToString {
      fn to_string -> String
    }

It's (roughly) compiled down to:

    let ToString = Trait.new

    fn(self) {
      define_required_method('to_string')
    }.call(ToString)

Knowledge such as the type signatures of the required methods or any
type arguments will only be known to the compiler for the time being.

The old prototype compiler written in Ruby is being replaced with a Rust
based compiler.

Inko ("インコ") means parrot/parakeet in Japanese. In Inko communication
happens via message passing, for both objects and processes. Naming the
language after parrots/parakeets (a rather vocal type of bird, some
known for mimicking human speech) makes more sense than naming it after
the concept of eternity. Furthermore, naming the language after parrots
allows the creation of a proper logo and mascot; something quite hard
when your language is called "Aeon".