amp-lang/amp

The Amp compiler

amp's Issues

Compile "Hello, world!" example

Compile the following example:

const Printf = func printf(format: &u8): i32;

const Main = func main(): i32 {
    Printf("Hello, world!");
    return 0;
};

• Scanner
• Parser
• Semantic analysis
• Codegen (AIR to Cranelift)

Report `const` declarations with values not known at compile time.

The following program causes the compiler to crash:

const MyNumber = 42;

const Main = func(): i32 {
    // MyNumber();
};

const MyValue = Main();
//              ^^^^^^ not known at compile time

(functions cannot currently be called at compile time)

Instead, this should report a nice error message stating that the value is not known at compile time.

Implement implicit returns

Currently, if a function doesn't return, the compiler panics due to Cranelift's verification pass.

Instead, the compiler should implicitly return from each function. If the function should return a value, it should return uninitialized memory instead.

For basic types such as integers, 0 shall be returned as a default, similar to C.

This will eventually be replaced with a check that doesn't allow a function to return implicitly if it returns a value, and a function would have to explicitly return uninit instead:

const Main = func main(): i32 {
    // ...
    
    return uninit;
}

Equivalent to the following C code:

int main() {
    // implicit return
}

Disable returning `type`s from functions entirely

Currently, type technically can be used as a return type for a function, but type values are not supported by the Cranelift backend.

const MyFunc = func(): type {
    return i32;
};

Which causes the compiler to output:

thread 'main' panicked at 'all possible types in Amp should be supported by Cranelift', src\clif\mod.rs:243:18

Instead, we should report a diagnostic explaining that types cannot be returned from functions.

Implement using function calls as values

For example,

export const Add = func Add(i32, i32): i32;
export const PrintNumber = func PrintNumber(i32);

export const Main = func(): i32 {
    PrintNumber(Add(42, 42)); // => 84
    return 0;
}

Report diagnostics in `Type::from_ast`

Currently, Type::from_ast looks like this:

from (src/types.rs):

/// Attempts to resolve a constant type value from the provided expression.
pub fn from_ast(
    cx: &mut Context,
    unit: &mut Unit,
    scope: &Scope,
    expr: &ast::Expr,
) -> Result<Self, ()> {
    let Value::Type(final_ty) = Value::eval(
        IntermediateExpr::verify(cx, unit, scope, expr)?
            // verify that the value is a type
            .coerce(&Type::Type)
            .expect("TODO: report non-type in type position"),
    )
    .expect("TODO: report non-constant type")
    else { 
        unreachable!("value should be of type `type` as verified above")
    };

    Ok(final_ty)
}

Rather than expecting and panicking when a value is used as a type, we should report a diagnostic. Ideally, this diagnostic would be a type-mismatch diagnostic which may be re-used in other situations, such as variable type mismatches, etc.

Ensure `return` statement has value

The following program crashes the compiler:

const Printf = func printf(&u8): i32;

const Main = func main(): i32 {
    Printf("Hello, world!");
    return;
};

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Compilation(Verifier(VerifierErrors([VerifierError { location: inst2, context: Some("return"), message: "arguments of return must match function signature" }])))', src\clif\mod.rs:328:22

Instead, a nice diagnostic should be shown.

Implement indirect functions as values in Cranelift IR

For example:

const UseFunction = func(callback: func(&u8): i32): i32 {
    return callback("Hello, world!");
}

const Printf = func printf(&u8): i32;

const Main = func main(): i32 {
    UseFunction(Printf);
    return 0;
}

NOTE: this would only become useful when variables and function parameters are implemented.

Clean up `codespan-reporting` fork

There is a lot of unnecessary code in the codespan-reporting fork used by Ampc, and we could clean it up a bit. This means either merging it into the main crate or just cleaning it up as is.

Parse command line arguments

Currently, the compiler only compiles a hard-coded file name (HelloWorld.amp). The compiler should accept command line arguments to build an object file like so:

ampc build-obj HelloWorld.amp -o HelloWorld.o