General Category > Implementation Details
Suppress warnings
(1/1)
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: ---// noinspection unchecked
Map<String, List<String>> nameMap = (Map)result.get("names");
--- End code ---
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: ---#pragma clang diagnostic push
#pragma ide diagnostic ignored "UnusedValue"
lSeek += file_info.size_file_comment - uSizeRead;
#pragma clang diagnostic pop
--- End code ---
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: ---// 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;
--- End code ---
Other styles are possible as well. The same should go for other scopes:
--- Code: ---// {unchecked:warn_unused}
func i32 foo() {
...
}
// {unchecked:warn_unused}
type Foo struct {
...
}
--- End code ---
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.
Navigation
[0] Message Index
Go to full version