I would like to suppress some of these VB.NET warnings at class level. (=Not globally.) Supression is intended as temporary woarkaround until the code of some classes gets properly cleaned. There are hundreds of ID: 42016 (Option Strict On disallows implicit conversions from 'TypeA' to 'TypeB'.) warnings in legacy code, I cannot afford to fix them all right now.
I found that SuppressMessage attribute can be effectively used for the task but I cannot find proper argument values to supply to <SuppressMessage()> for warning 42016.
My question is: can be warning 42016 and other above referenced VB.NET-specific warnings suppressed by SuppressMessage attribute?
If you know there is no way of doing it, I will accept it as the answer, too.
Note: I know how to suppress them globally, this is not an option at the moment.
No, that does not get you anywhere. SuppressMessageAttribute is only used by code analysis (aka FxCop), the VB.NET compiler ignores it. And it is not a warning, it is a compile error. You can never ignore an error.
Option Strict can only be changed at file scope, there is no support for changing it on-the-fly. The only reasonable approach here is to tackle the borken source code one .vb file at a time. Not an unreasonable approach.
Related
As you may know, it is pretty easy to have active code of a class containing syntax errors (someone activated the code ignoring syntax warnings or someone changed the signature of a method the class calls, for instance).
This means that also dynamic instantiation of such a class via
CREATE OBJECT my_object TYPE (class_name).
will fail with an apparently uncatchable SYNTAX_ERROR exception. The goal is to write code that does not terminate when this occurs.
Known solutions:
Wrap the CREATE OBJECT statement inside an RFC function module, call the module with destination NONE, then catch the (classic) exception SYSTEM_FAILURE from the RFC call. If the RFC succeeds, actually create the object (you can't pass the created object out of the RFC because RFC function modules can't pass references, and objects cannot be passed other than by reference as far as I know).
This solution is not only inelegant, but impacts performance rather harshly since an entirely new LUW is spawned by the RFC call. Additionally, you're not actually preventing the SYNTAX_ERROR dump, just letting it dump in a thread you don't care about. It will still, annoyingly, show up in ST22.
Before attempting to instantiate the class, call
cl_abap_typedescr=>describe_by_name( class_name )
and catch the class-based exception CX_SY_RTTI_SYNTAX_ERROR it throws when the code it attempts to describe has syntax errors.
This performs much better than the RFC variant, but still seems to add unnecessary overhead - usually, I don't want the type information that describe_by_name returns, I'm solely calling it to get a catchable exception, and when it succeeds, its result is thrown away.
Is there a way to prevent the SYNTAX_ERROR dump without adding such overhead?
Most efficient way we could come up with:
METHODS has_correct_syntax
IMPORTING
class_name TYPE seoclsname
RETURNING
VALUE(result) TYPE abap_bool.
METHOD has_correct_syntax.
DATA(include_name) = cl_oo_classname_service=>get_cs_name( class_name ).
READ REPORT include_name INTO DATA(source_code).
SYNTAX-CHECK FOR source_code MESSAGE DATA(message) LINE DATA(line) WORD DATA(word).
result = xsdbool( sy-subrc = 0 ).
ENDMETHOD.
Still a lot of overhead for loading the program and syntax-checking it. However, at least none additional for compiling descriptors you are not interested in.
We investigated when we produced a dependency manager that wires classes together upon startup and should exclude syntactically wrong candidates.
CS includes don't always exist, so get_cs_name might come back empty. Seems to depend on the NetWeaver version and the editor the developer used.
If you are certain that the syntax errors are caused by the classes’ own code, you might want to consider buffering the results of the syntax checks and only revalidate when the class changed after it was last checked. This does not work if you expect syntax errors to be caused by something outside those classes.
What is a "suitable guard" and what does it look like?
Linked this question because it refers to the same compiler message and the answer mentions a guard but not how to create one. Looked through the AspectJ docs but did not find and answer there.
This Lint warning is usually switched off in AJDT (AspectJ Development Tools) within Eclipse, but you can activate it as a warning or even error like this (I had to do it to actually see it at all when trying to reproduce your issue):
You can just ignore the Lint warning because basically it only says that there is no way for certain pointcuts to populate the thisJoinPoint object lazily during runtime because the pointcut has no dynamic component like if(), cflow() or similar, which is actually good news because it means that all your joinpoints can be determined statically during compile/weave time and are thus faster than dynamic pointcuts. On the other hand, the warning says that the tjp object always has to be created because for some reason it is also always needed during runtime and thus cannot be instantiated lazily.
I realize that doing this can lead to compile errors. But is an import always safe if no (new) compile errors or warnings arise? If I use an import statement (e.g. to remove duplicate protocol definition warning), could doing so, on it's own, ever change the run-time behavior? What checks (if any) are necessary to ensure invariability of operation after a new header import?
Yes, importing a header can lead to run-time issues.
For example, you may get a warning that a selector is unknown so the compiler is making assumptions about its signature. If you fix that warning by importing the relevant header, then that changes the code the compiler is emitting. Generally, it would change the code from broken to correct, but that nevertheless results in a run-time change.
If you use #import, then the header could define preprocessor macros that radically alter the subsequent code. For example, it could #define setNeedsDisplay setHidden or something.
The only way I can think of to verify that importing the header didn't alter the generated code is to examine the generated code and compare before and after. You can ask Xcode or clang to produce assembly from the compilation. You could also use otool -tV to disassemble the binaries (although that wouldn't show changes in, say, static data like strings).
I am getting sick of seeing the warning
"Declaration of 'index' shadows a global declaration"
index is defined in string.h. I don't think that it's required for anything I am using and I really don't want to change all the local vars from index to something else.
Anyone know of a way to find out how (by what path) string.h is included? Is it possible to prevent it from being included?
The index function is actually declared in /usr/include/strings.h, and is marked as removed as of POSIX issue 7. You can hide its declaration by setting the appropriate POSIX version with the compiler flag -D_POSIX_C_SOURCE=200809. This will also hide other functions deprecated in issue 7, like bcopy and bzero.
I find -Wshadow extremely annoying and rarely useful. Even if you solve this one case, there are bound to be others in the future, especially since system headers may define non-standard functions and variables which yours unintentionally shadow.
Personally, I would just disable the warning, and manually make sure no variables, functions, etc. are named the same as something being used.
in VB.NET it is possible to omit parentheses when you call a parameterless function. However this can be very confusing because developers could think that a statement is accessing a property instead of a method. this could result in a performance drop if you are calling the method again and again instead of storing the result in a temp variable.
is there an option in VS2008 or a compiler option to force parentheses on statements that are calling a method?
and if so, would it be also possible that VS will insert missing parentheses automatically if you "format document" (Menu: Edit - Advanced)?
thanks, toebens
No there is no such option in the VB.Net compiler. Parens are optional and there is no warning or error that exist for using a lack of them.
The other reason is that VB.Net is a language which tries to be flexible and get the syntax out of the way of the user. This type of restriction goes against this general philosophy.
Another issue to consider is that it's not a universally enforceable restriction. VB.Net allows for late binding scenarios whenever option strict is set to off. In these scenarios it is impossible for the VB.Net compiler to determine ahead of time if a particular call is a property, statement or not a valid call at all.