Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] deliberately raise compiler errors & warnings #369

Open
shamiao opened this issue May 8, 2024 · 1 comment
Open

[Feature request] deliberately raise compiler errors & warnings #369

shamiao opened this issue May 8, 2024 · 1 comment

Comments

@shamiao
Copy link

shamiao commented May 8, 2024

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
Copy link
Collaborator

Yoorkin commented May 8, 2024

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants