On Wed, Aug 24, 2016 at 9:38 PM, Gijs Kruitbosch
<gijskruitbo...@gmail.com> wrote:
>
> Can this problem be solved with more of these types of
> annotations/"compiler-aids", that is, could we teach the compiler to accept
> either nsresult or out checks at least for simple xpidl property fetches?
> Feels like that would avoid some "false" positives and therefore some
> rewriting.

XPIDL has an [infallible] annotation for attributes. For those, an
infallible getter is generated, which returns the value directly
instead of via an outparam. It solves a lot of problems, but
unfortunately it's only useable within [builtinclass] interfaces --
because there's no way to guarantee that a JS implementation of an
interface really is infallible, whereas we can audit all C++
implementations -- and it only works with some builtin types.

> I'm mostly in frontend Firefox land so excuse the potentially dumb question
> and probably incorrect terminology... My impression was that we already have
> things like NonNull, and if we are now forcing nsresult codes to be actually
> used, presumably we could just as well indicate whether particular IDL
> properties could/couldn't be null, and accept a check on that rather than
> the rv if the idiom is very common?

I'm not sure if this addresses your comment directly, but: IDL methods
have to return nsresult to satisfy interface requirements. Because
xptcall, which is the code that handles these calls from C++ land and
JS land, expects an nsresult return value. Changing this would be
difficult.

Also, not all methods and attributes will/should get the [must_use] annotation.

Nick
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to