enabling 'deprecated api usage' warning in chrome/blink

[Mike Reed]

Skia (and no doubt other libraries used by chrome/blink) has some of its API marked as Deprecated. We have a macro that can formally annotate those calls as deprecated, generating a warning at the call-site. This seems like a great thing, as it will aid us in finding/fixing those call-sites. However, if we build chrome/blink with warnings-are-errors, this breaks the build...

Can we allow (in gyp I presume) for select warnings to shine-through, but not be treated as errors?

[Daniel Bratell]

On Tue, 12 Nov 2013 18:04:51 +0100, Mike Reed <re...@google.com> wrote:

> Skia (and no doubt other libraries used by chrome/blink) has some of its
> API marked as Deprecated. We >have a macro that can formally annotate

> those calls as deprecated, generating a warning at the call->site. This

> seems like a great thing, as it will aid us in finding/fixing those
> call-sites. However, >if we build chrome/blink with warnings-are-errors,
> this breaks the build...
>
>
>
> Can we allow (in gyp I presume) for select warnings to shine-through,
> but not be treated as errors?

In Presto development we did that for quite some years, but I must say the
idea sounds much better than it works out. By setting an API as deprecated
you basically are forcing, or trying to force, someone to adapt to your
changes. People don't always have time to jump in and change their code,
and then the deprecation warning starts building up, people learn to
ignore them, real warnings disappear in the spam and there is no net win.

Also, having multiple APIs at the same time contribute to code bloat.
Better to just do the switch than adding deprecation markers. Or have the
warnings as a non-default compilation mode for those (rare) occasions when
you are interested in them.

(A second data point - the Java compiler used to show lots of deprecation
warnings, but rather quickly moved that to a special flag.)

/Daniel

[Nico Weber]

Hi,

I am strongly opposed to this. Experience has shown that deprecation warnings only get cleanup if the person who deprecates an API moves all code to the new API. In that case, having warning spew for all developers while a small number of people migrate some API isn't useful.

Nico

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:   http://groups.google.com/a/chromium.org/group/chromium-dev

[Alexei Svitkine]

Maybe a better solution is to simply file Chromium bugs against the owners of the code that use the specific deprecated APIs?

[Thiago Farina]

fwiw, V8 has V8_DEPRECATED macro behind a gyp flag.

https://codereview.chromium.org/25226002/

Thiago

[Sven Panne]

On Tue, Nov 12, 2013 at 6:55 PM, Thiago Farina <tfa...@chromium.org> wrote:

fwiw, V8 has V8_DEPRECATED macro behind a gyp flag.

https://codereview.chromium.org/25226002/

Just a note: We *have* to do this, because v8 is not only embedded in Chrome, but in lots of other projects, so the closed-world approach of "simply adapt all call sites" doesn't work. We typically leave a deprecation for one stable release to give embedders a chance to change their code, and then remove the deprecated stuff in the next stable release. This works quite well for us so far, but now and then we had to made some exception to this "grace period", e.g. for things related to the handlepocalypse.

[Paweł Hajdan, Jr.]

By the way, I really appreciate V8_DEPRECATED. Thank you for adding and using it.

Paweł

--

[Mike Reed]

We have SK_ATTR_DEPRECATED for the same purpose, with the same issue of multiple embedding clients besides chrome. I will investigate adding that behind a flag in chrome's gyp as well. Thanks.