Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Issue 1346 - Deprecated error message mapping - haxe #1346

Closed
issuesbot opened this Issue · 17 comments

4 participants

@issuesbot

[Google Issue #1346 : https://code.google.com/p/haxe/issues/detail?id=1346]
by andy@onthewings.net, at 26/12/2012, 18:01:37
Posted in Google Groups: https://groups.google.com/forum/?fromgroups=#!topic/haxedev/4ysmZ6hCxsI

Here is a feature request to introduce a @ :deprecated metadata.

Because haxe is moving fast and from my experience there are constantly new breaking changes are proposed.
There are quite a lot of things got deprecated, with a temp typedef and/or wrapped with #if, which I think is good because it gives time for us to adopt changes.
But since normally there is no warning given when using deprecated things, many of us will not notice/remember some APIs got deprecated.

With a @ :deprecated on a type(class/typedef etc.), or on a class member, there would be a compiler warning when they are used.
Something like:

@ :deprecated("IntIter will be renamed to IntIterator soon.")
typedef IntIter = IntIterator;

class A {
    @:deprecated("Use superA instead. See: http://haxe.org/some-page")
    public function a():Void {
        superA();
        }
    public function superA():Void {}
    }

@issuesbot

[comment from si...@haxe.org, published at 29/12/2012, 21:56:32]
It's not a bad idea, but would be a bit too intrusive. What we could do instead is simply map error messages caused by deprecation to new ones like so:

let deprecated = [
"Class not found : IntIter", "IntIter was renamed to IntIterator";
"EReg has no field customReplace", "EReg.customReplace was renamed to EReg.map";
]

Using -D haxe3 will then give nice error messages with what's going on.

Feel free to augment this with other messages you can think of, it will be a while before I could look into it.

@issuesbot

[comment from ncanna...@gmail.com, published at 31/12/2012, 08:50:50]
another one : "#StringTools has no field isEOF"

@issuesbot

[comment from ncanna...@gmail.com, published at 31/12/2012, 08:53:30]
I think both @ :deprecated and Simon's suggestion are good : @ :deprecated is for user-specific code and the other one for Haxe 3 changes

@issuesbot

[comment from si...@haxe.org, published at 31/12/2012, 11:34:28]
@ :deprecated might work on user code. I didn't consider it for std classes because there we would have to detect the actual usage as opposed to just hook into the type loading, but this is not the case for user classes.

@issuesbot

[comment from si...@haxe.org, published at 04/01/2013, 10:45:48]
This issue was closed by revision 35cbc1b.

@issuesbot

[comment from si...@haxe.org, published at 04/01/2013, 11:54:56]
Not fixed yet

@issuesbot

[comment from si...@haxe.org, published at 30/01/2013, 10:06:59]
This requires too many changes to get right at the moment, maybe we can review after haxe 3.

@issuesbot

[comment from si...@haxe.org, published at 24/02/2013, 17:12:14]

@issuesbot

[comment from si...@haxe.org, published at 27/05/2013, 15:26:58]
Giving warnings is really difficult with what we currently have. I suggest instead that we support this using @ :require. Library authors can then decide how to approach this:

@ :require(LEGACY, "Use something else or compile with -D LEGACY") static var test;
@ :require(!NO_DEPRECATION, "Use something else") static var test2;

The former would error by default, but allow compilation if -D LEGACY is set. The latter would not error unless -D NO_DEPRECATION is in place.

I consider this good enough.

@Simn Simn closed this
@frabbit
Collaborator

is this already supported?

@Simn
Owner

Yes.

@frabbit
Collaborator

hmm, it doesn't work for me in every case.

@frabbit
Collaborator

ok, my fault, it works as expected.

@Simn
Owner

Request from prezi: Implement an optional post-process analyzer which checks for access to fields that are annotated with @:deprecated. That looks like a simple enough solution to me.

@Simn Simn reopened this
@Simn Simn modified the milestone: 3.1.1, 3.2
@Simn
Owner

I'll squeeze this into 3.1.1 behind a -D deprecation-warnings flag just in case I royally mess up the filter. We can later invert that and make it the default.

@Simn
Owner

@lptr: This has been implemented and will be part of the 3.1.1 release.

It can be activated using -D deprecation-warnings and then reports field and type access during post-processing (before DCE). This is my test file: https://gist.github.com/Simn/9475605

Is this what you had in mind? You can use either @:deprecated("message") or just plain @:deprecated without any arguments, which defaults to "Usage of this _ is deprecated."

Additionally you can use -D deprecation-warnings=def-pos which also prints a second warning "Defined here" with the position of the field or type which has the @:deprecated metadata. I decided to not make this the default as it is a bit verbose.

@Simn Simn closed this
@lptr

Thanks, this was really quick. We already build with Haxe 3.1.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.