Suppress warnings

[lerno]

Suppressing warnings should be easy to do on a file / func / statement.

In IntelliJ, annotations are used to suppress warnings on file / class / method level, but can be suppressed by statement with a comment as well, in this manner:

Code: [Select]

// noinspection unchecked
Map<String, List<String>> nameMap = (Map)result.get("names");

For Xcode / Clang, it's much more complicated. You push the current state with a pragma, disable a warning and then have to pop it later. Very ugly:

Code: [Select]

#pragma clang diagnostic push
#pragma ide diagnostic ignored "UnusedValue"
lSeek += file_info.size_file_comment - uSizeRead;
#pragma clang diagnostic pop

I'd like for C2 to have a very easy way to suppress warnings in the manner of IntelliJ's comments.

Something like this:

Code: [Select]

// A.
lSeek += file_info.size_file_comment - uSizeRead; // $ignoreunused$

// B.
lSeek /* $ignoreunused$ */ += file_info.size_file_comment - uSizeRead;

// C.
// $ignoreunused$
lSeek += file_info.size_file_comment - uSizeRead;

// D.
// {unchecked:warn_unused}
lSeek += file_info.size_file_comment - uSizeRead;

Other styles are possible as well. The same should go for other scopes:

Code: [Select]

// {unchecked:warn_unused}
func i32 foo() {
   ...
}

// {unchecked:warn_unused}
type Foo struct {
   ...
}

For file scope it should be slightly different to avoid parsing ambiguity.

[bas]

The only warnings in C2 so far are unused decls/imports/etc, all other issues are just errors.

I don't like pragma's either, very ugly. But I also don't like abusing comments. I think all stuff related
to meta issues (like packed, etc) could just be attributes. So @(..). That way the language syntax
is still the same, but we just have to add some possible attribute points..

[lerno]

Something like @(nocheck=unused_variable | implicit_conversion)?

[bas]

Yes, but i would want to avoid all the nitty-gritty Warning level tweaking that's part of C/C++. Only unused decls maybe and maybe maybe
some implicit conversions. Otherwise just be strict and generate errors. If you inherit a piece of code, disabling some warnings is okey.

What I'm thinking of is whether these adjustments should be make in code or in the recipe file. I think the recipe file might be better
suited for file-based adjustments.

[lerno]

For file maybe. I find that I mostly will turn of statement based warnings. It's when I run into a piece of code I know will be safe, but that the compiler think might be unsafe. In java that's usually casting between generics. For Objective-C, using dynamic calls where the compiler can't see the definition, etc. Things that you want to avoid 90% of the cases.