Why static analyzer remove code instead of warning

1

Why it’s remove the code on output instead of telling us that we have unreachable code and such.
There is good resources about haxe’s static analyzer?
Thx!

2

I think the idea is that you don’t have to worry about it. Also because of conditional compilation in some cases it might be unreachable but in other cases it doesn’t, so not sure how much worth the information is.

2 Likes
3

I would say you don’t want a whole bunch of warnings telling you some variables/functions in some libraries (including the std lib) are not being used. Because I am pretty sure you will be getting A LOT of them.

4

hm… yes but for example, in jslint you get warning only for your code…

5

JSLint and Haxe are hardly the same. Haxe actually produces code, while a linter doesn’t. Meaning if you have unreachable JS code, then a linter can’t eliminate it and reporting it gives you the opportunity to improve your file size.

Mostly though, Haxe does a lot of transformations to your code, which can easily make some of it unreachable. Example:

class Dummy {
  static public inline function foo(bar:Bool) {
    trace("foo");
    if (!bar) return;
    trace("bar");
  }
}

class Main {
  static function main() {
    Dummy.foo(false);
  }
}

After inlining you have:

class Main {
  static function main() {
    trace("foo");
    if (true) return;
    trace("bar");
  }
}

The 2nd trace is clearly unreachable and the if (true) is also superfluous. Similarly, macro expansion can also yield code that contains unreachable parts.

1 Like
6

With vshaxe, some unused code is grayed out by diagnostics info from the compiler:

2 Likes
7

Is there a way to get diagnostics commandline?

8

Re-reading this old post, I thought it might be worthwhile that "sometimes you do this sort of thing on purpose." You might have code that is used in some contexts but not in others. You might have a library that is used in several different places but, for each place that it’s used, you don’t need everything that it contains. Haxe’s compiler is smart enough to detect this “dead code” and to omit it from a particular target/output … and it does it silently. You don’t have to touch the source-file to get the proper output for each case where that source-file is used. Haxe figures out what’s dead and what’s not, for each case separately.

Per contra, a “JavaScript library” isn’t “generated.” For the most part it isn’t customized. Even sophisticated JS build-tools have only a limited ability to eliminate things because of the intrinsic structure and design of the language, JavaScript. That source-code is going to be in there, whether you use it or not – and just by being there it just might do something. … :scream_cat:

Haxe is, all around, a stronger and more-rigorous language which makes you specify more and which therefore knows more. This is what enables it to do things like this, which are actually “to be expected” from a true compiler … which Haxe is.

1 Like