[Feature request] deliberately raise compiler errors & warnings

[shamiao]

Certain #pragma-like syntax may be provided for raising errors & warnings when compiling. Some examples:

A) Prevent important unimplemented functions from being compiled

fn important_method(self: MyType) {
    @pragma.error("not implemented, don't call me now");
}
fn main() {
    let x = MyType::new()
    x.important_method() // cause compile error
    // note: no compile errors if the method is dead code (not called at all)
}

B) Show library-specified warnings. I believe mainly used for deprecation.

fn old_method(self: MyType) {
    @pragma.warning("deprecated since 0.1.5 and will be removed in 0.2.0, use `refreshed_method()` instead")
}
fn main() {
    let x = MyType(1)
    x.old_method() // cause warning
    // note: no warnings if the method is dead code
}

C) Prevent certain target from being built.

// main.js.mbt
fn init {
    @pragma.error("the mooncake `my-awesome-wasm-tool` won't build on non-wasm target!");
    // won't compile by `moon build --target=js`
}

[Yoorkin]

Currently we have alert pragmas, which are sufficient for scenarios A and B:

/// @alert unimplemented "don't call me now"
fn important_method(self: MyType) {
}

/// @alert deprecated "deprecated since 0.1.5 and will be removed in 0.2.0, use `refreshed_method()` instead"
fn old_method(self: MyType) {

}

For scenario C, perhaps the build system should be responsible for checking the building target. @lijunchen

The alerts are designed to be configurable. You can turn them off or treat them as compile errors by passing the -alert flag to the compiler. For example, -alert -unsafe@deprecated will turn off the unsafe alerts and treat deprecated alerts as errors.

The build system, moon, will support these configuration options in moon.pkg.json and moon.mod.json soon, so stay tuned!

[peter-jerry-ye]

For scenario A and B, we have alert pragma.

For scenario C, we are having conditional compilation and supported targets configuration.