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