Home » Eclipse Projects » Eclipse Titan » RFC: Configurable warnings / errors for ttcn3_compiler
| RFC: Configurable warnings / errors for ttcn3_compiler [message #1837691] |
Thu, 04 February 2021 09:21  |
|
In our normal development (of the IUT, not the test suite), we at Osmcoom work a lot with gcc.
gcc (like other C compilers) have fine-grained control over which warnings the compiler should or should not emit. It can be configured "globally" via compiler flags, and also via in-line prgmas in the code.
This is extremely useful in order to express the policy / expectation of the project, and then finally compile with -Werror (turning all remaning warnings into errors) in order to ensure nobody introduces new code that contains any of the deemed-to-beproblematic warnings.
I've been missing a related functionality in TITTAN ttcn3_compiler for a long time. It unfortunately emits a lot of warnings (like function retunr values not being used), which might be perfectly legitimate in the given code base. I'd want to ignore (hide/disable) those, as they just hide the "real" warnings that I care about in the output.
By now the problem is that probably every one of our codebases emits hundreds of ttcn3_compiler warnings, and nobody ever looks at them anymore, as it's very tedious to filter those that are relevant from those that are irrelevant, like ignoring function return values.
Has this been discussed before? Do people generally consider this useful?
Sure, I'm aware one could work around this find a way to create elaborate "grep" pipes or the like, but then the warnings and errors are multi-line messages, so it's not as straight-forward as one might assume to filter the "good" from the "bad".
|
|
| |
| Re: RFC: Configurable warnings / errors for ttcn3_compiler [message #1837704 is a reply to message #1837700] |
Thu, 04 February 2021 11:47  |
|
Thanks for your feedback. The flags unfortunately work globally, and cannot be used to disable individual warnings while keeping others (or even elevating certain warnings to errors like the -Werror flag of gcc.
IMHO it would be avery useful feature to have.
I cannot make guarantees, but would related patches be meged if I'd be working on it?
|
|
| |
| Re: RFC: Configurable warnings / errors for ttcn3_compiler [message #1837955 is a reply to message #1837691] |
Thu, 11 February 2021 09:52 |
 Kristof Szabados
Messages: 82
Registered: July 2009 |
Member |
|
|
Hi Harald,
One more option could be to use the IDE Titan provides over Eclipse.
In the IDE, it is possible to control for each individual quality issue kind how it is reported (ignored, warning, error)/
And there is not just a lot more code quality issues detected (in the Titanium plugin), but also architectural issues, metrics measured, etc..
It can even help you get a better understanding of your architecture, with its visualizations.
This is taking advantage of not just the graphing that a graphical user interface can provide, but also the amount and precision of configurability (having to remember 10+ command line argument can be quite troublesome, but usually IDE -s offer hundreds of options for just formatting code ... if done correctly it can still feel like a good user interface).
On the other hand the command line compiler was struggling for a long time with Solaris limitations (like 1 letter parameters as command line arguments), and was not exactly designed to operate like that.
In this setup you could use the IDE to check the quality of your code.
The C side compiler to compile it into C code (removing the warnings as they are no longer in focus here).
And if you wish also try to see if your code could already be compiled to Java code on the Java side of the toolset.
|
|
|
| Re: RFC: Configurable warnings / errors for ttcn3_compiler [message #1837958 is a reply to message #1837955] |
Thu, 11 February 2021 10:18 |
|
Thanks for your suggestion, but our development and testing workflow is working with fully automatizedbuld + testing, with jenkins building the TITAN test suites, executing them, etc.
I doubt there is a (reasonable) way to integrate the "IDE" you mention within a jenkins job?
After all, as I believe I mentioned before, in our use case no IDE is desired. We just want to call one 'make' (or other build system) comamnd which then calls the compiler to compile the code.
And the compilation should work exactly identical both on the local developers' machine, as on the build slaves which later will be compiling the tests for the CI/CD workflow. Wtih the same output, same warnings, etc.
In my opinion, the ideal workflow to compile TTCN3 works exactly like the workflow to compile C code.
* compiler with full command line control or even pragmas to control over which warnings are enabled or disabled
* warnings read by the human when compiling loally on their development system
* warnings consumed/analyzed by a related jenkins plug-in to provide statistics on number of warnings for each "master" build, e.g. https://plugins.jenkins.io/warnings-ng/
As stated, if there was a chance to get the patches merged, I might try to look into creating at least command line (long-opts) control over emitted warnings.
If you still have to maintain Solaris compatibility and have related constraints, it could also be some kind of configuration file, or envirionment variables, or some other method by to pass this into the compiler.
|
|
|
| Re: RFC: Configurable warnings / errors for ttcn3_compiler [message #1838033 is a reply to message #1837958] |
Sun, 14 February 2021 07:29 |
Kristof Szabados
Messages: 60
Registered: July 2015 |
Member |
|
|
Hi Harald,
Just a few quick note:
1)
It is possible to run all Titanium checks in headless mode.
Where you have to have Eclipse and Titanium installed, but you call this functionality from the command line and the operation never opens an Eclipse window.
It is possible to export the measured value to XLS files for human consumption, or CSV files for script-based processing (one of our internal users built a tool on it that warn them if the amount of predetermined code smalls increases and also rejects the commit).
Also, the dependency graphs can be output in .dot and .net formats.
2)
Please note, that hiding away warnings, by using pragmas is not really considered a good practice.
If you wish to hide them, because you currently don't have the time to deal with it, but you manager forces you to have a 0 warning policy, that can be problematic since you might hide away warnings, that could later turn out to be actual errors ... but as they were hidden neither you nor others in the future will have the chance to notice and fix them.
If you wish to hide away warnings, because you do not wish to make the developers of Titan angry (by writing lots of improvement requests) .. don't be afraid, they are nice people ... maybe not immediately, but sooner or later those bugs will be fixed ;)
3)
It might not be the best policy to say that CI is the one and the only tool to be used and developers should not use IDEs that give them extra information/options.
On the contrary, I would encourage you to embrace several different tools, that can help you be more productive and create better code.
The IDE of Titan built onto Titan can provide some very nice features, above what is comfortable in the command line (like dynamic visualization of dependency graphs).
There might be out there some other tools that can detect some other quality issues, or offer different sets of features.
In my experience the bigger the diversity we embrace, the better the output we create ;)
Best Regards
Kristof
|
|
|
| Re: RFC: Configurable warnings / errors for ttcn3_compiler [message #1838035 is a reply to message #1838033] |
Sun, 14 February 2021 08:00 |
|
Hi Kristof,
thanks for your input, as usual.
Kristof Szabados wrote on Sun, 14 February 2021 08:29
1)
It is possible to run all Titanium checks in headless mode.
Where you have to have Eclipse and Titanium installed, but you call this functionality from the command line and the operation never opens an Eclipse window.
Ok, this is interesting indeed, and looks like it's suitable for CI/CD integration. I'm not an expert in this field, but we'd have to investigate if there's some kind of standard format that CI software like jenkins can consume regarding code smells or the like.
Kristof Szabados wrote on Sun, 14 February 2021 08:29
2)
Please note, that hiding away warnings, by using pragmas is not really considered a good practice.
That's where I beg to disagree (and probably anyone using the related gcc command line arguments from their build environment like autotools).
Compiler warnings _can_ be useful. But if, after investigation, you determine that a given warning is a false positive, then there ought to be some way to suppress that warning from future runs. That could be a pragma in the code at the specific location, or it could be a global disable of that warning type (at least for some compile units). Otherwise, people will not bother looking at the warnings at all anymore, as they are used to the fact that thert always is a large amount of warnings anyway.
My prime example in TITAN is the warning about an unused function return value. Yes, there are some functions that in some scenarios the caller is interested about the return value, but in other situations it is legitimately not interesting t othe code whether it succeeded or what it returned. In that situation you would have to duplicate code and have one version of the function wtih return value, and another function wtihout the return value as a work-around. That means code duplication, and also having to memorize that there are two variants of each function whenever calling it. And all that just because ther was no pragma/flag.
Another TITAN example: "deactivat() in a function or altstep". Yes, I know what I'm doing, and yes, this is what I want to do. For example, if I activate a default altstep to handle a global guard timer, there is no reason why I should not be doing that in a global initialization function.
Also, "Function invocation ... may change the actual snapshot". It's nice to see that warning once, think about it, conclude that it is not an issue in this piece of code and then get rid of it for the future.
In C, the prime example is a fall-through in a switch statement. You simply can annotate it with /* fall-through */ and many tools (e.g. coverity) will understand that yes indeed here this is intentional and not a forgotten "break;".
Kristof Szabados wrote on Sun, 14 February 2021 08:29
If you wish to hide them, because you currently don't have the time to deal with it, but you manager forces you to have a 0 warning policy, that can be problematic since you might hide away warnings, that could later turn out to be actual errors ... but as they were hidden neither you nor others in the future will have the chance to notice and fix them.
That's clearly not the point. I just think that every project / organization should be empowered to have their own policy about which warnigns they care, and which they don't. Thats a development policy decision, and not a decision by the compiler provider.
Kristof Szabados wrote on Sun, 14 February 2021 08:29
If you wish to hide away warnings, because you do not wish to make the developers of Titan angry (by writing lots of improvement requests) .. don't be afraid, they are nice people ... maybe not immediately, but sooner or later those bugs will be fixed ;)
I also think that also misses the point. There is only so much the compiler can do, and it requires a skilled developer to r eview and decide if there is an issue, or not.
Kristof Szabados wrote on Sun, 14 February 2021 08:29
3)
It might not be the best policy to say that CI is the one and the only tool to be used and developers should not use IDEs that give them extra information/options.
I have not tried to say that. Within Osmocom, I know almost every developer is using a different setup on their systems. Different Linux distribution, different editor (vim, emacs, vscode, atom, somebody even tried Eclipse at some point), etc.
Anyone can do what ethey please as llong as they get the development done. But fron the project maintainer/management point of view, what matters most is what the CI system states. The TTCN3 code must build there, it must work there (as the actual testsuites are executed from builds generated there), ...
In my 30+ years of intense daily use of computers I have personally concluded *for myself* that any software that requires me to use the mouse is nothing I would want to use voluntarily. I don't like GUIs, I don't like the concept of re-sizeable windows. I spend 99% of my time on the ocmmand line, using a tiling window manager with keyboard input to manage tons of uxterms. I would say the web browser is the only software I really ever use that is not console based. Yes, I use it if I must, if there's no alternative, but in terms of productivityy, every time I move my hand from keyboard to mouse, and I have to point an arrow somewhere and clickc somewhere, my productivity goes away. Of course that conclusion only applies to myself, and not to others. Everyone is different.
Everyone is entitled to their own conclusions, preferences, etc. and by all means should act on them.
|
|
|
| Re: RFC: Configurable warnings / errors for ttcn3_compiler [message #1838796 is a reply to message #1838033] |
Fri, 05 March 2021 08:14 |
|
Kristof Szabados wrote on Sun, 14 February 2021 08:29
If you wish to hide away warnings, because you do not wish to make the developers of Titan angry (by writing lots of improvement requests) .. don't be afraid, they are nice people ... maybe not immediately, but sooner or later those bugs will be fixed ;)
Hi Kristof,
I just encountered (again) one such situation: ttcn3_compiler complaining about missing return statements in code that can never be reached.
See https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23232/1/pcu/GPRS_Components.ttcn#704 in function f_rlcmac_dl_block_get_usf() which calls f_shutdown() which in turn calls all component.stop and/or mtc.stop.
How can the "return" statement after that call ever be reached by the control flow?
IMHO, the compiler should figure this out by itself: Don't mandate return statements if a function is called which never returns. If the compiler cannot do that, then the developers should have some pragma/annotation by which they can tell the compiler "this function never returns" and hence no warnings about missing return statements in code after such function calls are issued.
|
|
|
Goto Forum:
Current Time: Tue Apr 16 07:43:02 GMT 2024
Powered by FUDForum. Page generated in 0.13167 seconds |
] 
Search
Help
Register
Login
Home
