Suppress Compiler Warnings

, ,
1

I am wondering if there is a way to suppress compiler warnings in Visual Studio Code when working on multiple *.hxml files.

In the below illustration, I use a multitude of hxml files for different scenarios in my website application. I call them through a single point called build.bat with parameters. For example, I use .\build.bat server 1 to build the server code for the admin control panel.

image
image1920×1040 119 KB

Now, as you can see there are green squiggly lines everywhere, and the reason being is because the sys.db.* package is part of the record-macros library - of which I have included - and will soon be removed from the main Haxe library. Yes, okay, I’ve got the message after being okay with it for several months, but now it’s getting on my nerves.

Now, normally I find the Haxe compilation server works quite well with multiple *.hxml files, as long as you tell it where to look, but it doesn’t seem to be taking into account that I have included the library record-macros in the case of the server folder, and thus showing this deprecation warning. Is there a way to suppress this warning? I really don’t want to have to disable the Haxe plugin simply to remove the annoyance of green squiggly lines.

2

Have you tried adding -D no-deprecation-warnings to your HXML?

What’s the exact warning message?

1 Like
3

Sorry I’m a little late to reply.

The warning message is [diagnostics] This class will be removed soon, please install the record-macros library.

This is my *.hxml file(s) for server building:

Admin:

-cp server
-main Main
-php ../admin/includes
-lib record-macros
-D no-deprecation-warnings

Main Website:

-cp server
-main Main
-php ../includes
-lib record-macros
-D no-deprecation-warnings

As you can see, I’ve added your suggestion however it does not seem to apply. There are however times when I will click on another tab, then move back to the same class extending sys.db.Object and the green squiggly lines will disappear.

I think the Haxe compilation server gets confused as to which hxml file to use in which context. I’m sure there’s a way to modify the debug configuration file to have Haxe compile for the appropriate context and having no further problems, but I have never used VSC configuration files before other than the settings. I will have to look into it unless you think there is something else I can do.

4

Hm… I’m actually a bit confused where the deprecation warnings are even coming from, considering you’re using -lib record-macros. Those types were deprecated while they were still part of Haxe std, but the record-macros lib itself doesn’t have the deprecation warnings. And they should shadow those from the standard library.

I guess you must still be using Haxe 3.4? Have you tried updating to Haxe 4.0.0-rc.1?

5

I’d ideally prefer to avoid using version 4 until it’s fully released, but I believe also that Haxe 4 only supports php 7.0+?

Last time I tried php 7.0, haxe.Json wasn’t working properly when targeting using -D php7, but that’s an issue for another time.

6

All the more reason to at least give Haxe 4 a quick try while it’s still in RC-stage, to ensure any major issues you encounter actually get fixed until the final release. :wink: I’m sure @RealyUniqueName would be very curious to hear about any haxe.Json-related issues, especially if they’re regressions.

Note that you can just install it to some other location and point vshaxe to it using the "haxe.executable" setting. You can seamlessly switch between different Haxe version that way.

3 Likes
7

What was the issue with haxe.Json on php target? Could you please provide a reproducible sample?

8

I can’t reproduce for php 7.0 and Haxe 4 at the moment because of this issue on GitHub.

However when I get time I will attempt to reproduce an example using -D php7 for Haxe 3.4.7. That being said, I am currently having an issue somehow not being able to connect to localhost now… I will create a new thread as this will become off-topic.