TelluIoT / ThingML

The ThingML modelling language
https://github.com/TelluIoT/ThingML
Apache License 2.0
102 stars 33 forks source link

Disable specific warnings and notices from the compiler #135

Closed jakhog closed 7 years ago

jakhog commented 7 years ago

It would be nice if it was possible to disable specific warnings and notices from the compiler, where "unconventional" behaviour is intentional and known by the developer. In the current situation, the compiler spits out a lot of warnings and notices that is irrelevant, and potentially hides imporant messages. Three specific examples come to mind:

  1. Functions that are never called from ThingML code, but is called from native code. E.g. the following code

    function catch_sigint()
    @c_prototype "void catch_sigint(int sig)"
    @c_instance_var_name "_handler_instance"
    do
    print " Caught SIGINT\n"
    commands!stopsignal()
    end
    
    statechart Handler init Waiting {
    state Waiting {
      on entry do
        '_handler_instance = _instance;'
        'signal(SIGINT, catch_sigint);'
      end
    
      internal event e : commands?doexit action do
        print "Exiting!\n"
        'exit('&e.code&');'
      end
    }
    }

    leads to the following error [WARNING] ThingML: Function catch_sigint of Thing ExitHandler is never called. (in catch_sigint)

I suggest an annotation that could disable this warning for this very specific function. Something like:

  function catch_sigint()
  @no_warning "never_called"
  ...
  do
    ...
  end
  1. Sink states that are intentional. The above code snippet also leads to this notice

[NOTICE] ThingML: Sink state Waiting in Thing ExitHandler. (in Waiting)

I suggest the following annotation to hide this notice:

  state Waiting
  @no_notice "sink"
  {
    ...
  }
  1. Function calls with parameters which cannot be typed. This happens quite often, and result in a lot of warnings. I'm not sure function calls can even have annotations, but a similar solution would be nice.
brice-morin commented 7 years ago

Not that you can use @SuppressWarnings annotation on configuration to disable specific checks. I can probably allow this annotation on functions, states, etc. I will go for @SuppressWarnings rather than something exotic as you propose as it is e.g. the annotation used by Java

brice-morin commented 7 years ago

e.g. use @SuppressWarnings "Call" on function

Also, feel free to add filters in the existing rules using somethings like if (!AnnotatedElementHelper.isDefined(f, "SuppressWarnings", "Call")) {...