gecko-dev/dom/bindings/Nullable.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

109 строки
2.9 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this file,
* You can obtain one at http://mozilla.org/MPL/2.0/. */
Bug 742217. Reduce the use of nested namespaces in our binding code. r=peterv,bent In the new setup, all per-interface DOM binding files are exported into mozilla/dom. General files not specific to an interface are also exported into mozilla/dom. In terms of namespaces, most things now live in mozilla::dom. Each interface Foo that has generated code has a mozilla::dom::FooBinding namespace for said generated code (and possibly a mozilla::bindings::FooBinding_workers if there's separate codegen for workers). IDL enums are a bit weird: since the name of the enum and the names of its entries all end up in the same namespace, we still generate a C++ namespace with the name of the IDL enum type with "Values" appended to it, with a ::valuelist inside for the actual C++ enum. We then typedef EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to refer to the values, but means that values from different enums don't collide with each other. The enums with the proto and constructor IDs in them now live under the mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively. Again, this lets us deal sanely with the whole "enum value names are flattened into the namespace the enum is in" deal. The main benefit of this setup (and the reason "Binding" got appended to the per-interface namespaces) is that this way "using mozilla::dom" should Just Work for consumers and still allow C++ code to sanely use the IDL interface names for concrete classes, which is fairly desirable. --HG-- rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
2012-05-03 08:35:38 +04:00
#ifndef mozilla_dom_Nullable_h
#define mozilla_dom_Nullable_h
Bug 1609996 - Reorder some includes affected by the previous patches. r=froydnj This was done by: This was done by applying: ``` diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py index 789affde7bbf..fe33c4c7d4d1 100644 --- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py +++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py @@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase): from subprocess import Popen, PIPE, check_output, CalledProcessError diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE) - args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format] + args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes'] if not output_file: args.append("-i") ``` Then running `./mach clang-format -c <commit-hash>` Then undoing that patch. Then running check_spidermonkey_style.py --fixup Then running `./mach clang-format` I had to fix four things: * I needed to move <utility> back down in GuardObjects.h because I was hitting obscure problems with our system include wrappers like this: 0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration 0:03.94 extern void *realloc (void *__ptr, size_t __size) 0:03.94 ^ 0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here 0:03.94 MALLOC_DECL(realloc, void*, void*, size_t) 0:03.94 ^ 0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL' 0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__); 0:03.94 ^ 0:03.94 <scratch space>:178:1: note: expanded from here 0:03.94 realloc_impl 0:03.94 ^ 0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl' 0:03.94 #define realloc_impl mozmem_malloc_impl(realloc) Which I really didn't feel like digging into. * I had to restore the order of TrustOverrideUtils.h and related files in nss because the .inc files depend on TrustOverrideUtils.h being included earlier. * I had to add a missing include to RollingNumber.h * Also had to partially restore include order in JsepSessionImpl.cpp to avoid some -WError issues due to some static inline functions being defined in a header but not used in the rest of the compilation unit. Differential Revision: https://phabricator.services.mozilla.com/D60327 --HG-- extra : moz-landing-system : lando
2020-01-20 19:19:48 +03:00
#include <ostream>
#include <utility>
Bug 1609996 - Reorder some includes affected by the previous patches. r=froydnj This was done by: This was done by applying: ``` diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py index 789affde7bbf..fe33c4c7d4d1 100644 --- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py +++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py @@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase): from subprocess import Popen, PIPE, check_output, CalledProcessError diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE) - args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format] + args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes'] if not output_file: args.append("-i") ``` Then running `./mach clang-format -c <commit-hash>` Then undoing that patch. Then running check_spidermonkey_style.py --fixup Then running `./mach clang-format` I had to fix four things: * I needed to move <utility> back down in GuardObjects.h because I was hitting obscure problems with our system include wrappers like this: 0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration 0:03.94 extern void *realloc (void *__ptr, size_t __size) 0:03.94 ^ 0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here 0:03.94 MALLOC_DECL(realloc, void*, void*, size_t) 0:03.94 ^ 0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL' 0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__); 0:03.94 ^ 0:03.94 <scratch space>:178:1: note: expanded from here 0:03.94 realloc_impl 0:03.94 ^ 0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl' 0:03.94 #define realloc_impl mozmem_malloc_impl(realloc) Which I really didn't feel like digging into. * I had to restore the order of TrustOverrideUtils.h and related files in nss because the .inc files depend on TrustOverrideUtils.h being included earlier. * I had to add a missing include to RollingNumber.h * Also had to partially restore include order in JsepSessionImpl.cpp to avoid some -WError issues due to some static inline functions being defined in a header but not used in the rest of the compilation unit. Differential Revision: https://phabricator.services.mozilla.com/D60327 --HG-- extra : moz-landing-system : lando
2020-01-20 19:19:48 +03:00
#include "mozilla/Assertions.h"
#include "mozilla/Maybe.h"
#include "nsTArrayForwardDeclare.h"
class nsCycleCollectionTraversalCallback;
namespace mozilla::dom {
// Support for nullable types
template <typename T>
struct Nullable {
private:
Maybe<T> mValue;
public:
Nullable() : mValue() {}
MOZ_IMPLICIT Nullable(const decltype(nullptr)&) : mValue() {}
explicit Nullable(const T& aValue) : mValue() { mValue.emplace(aValue); }
MOZ_IMPLICIT Nullable(T&& aValue) : mValue() {
mValue.emplace(std::move(aValue));
}
Nullable(Nullable<T>&& aOther) : mValue(std::move(aOther.mValue)) {}
Nullable(const Nullable<T>& aOther) : mValue(aOther.mValue) {}
void operator=(const Nullable<T>& aOther) { mValue = aOther.mValue; }
void SetValue(const T& aArgs) {
mValue.reset();
mValue.emplace(aArgs);
}
void SetValue(T&& aArgs) {
mValue.reset();
mValue.emplace(std::move(aArgs));
}
// For cases when |T| is some type with nontrivial copy behavior, we may want
// to get a reference to our internal copy of T and work with it directly
// instead of relying on the copying version of SetValue().
T& SetValue() {
if (mValue.isNothing()) {
mValue.emplace();
}
return mValue.ref();
}
void SetNull() { mValue.reset(); }
const T& Value() const { return mValue.ref(); }
T& Value() { return mValue.ref(); }
bool IsNull() const { return mValue.isNothing(); }
bool Equals(const Nullable<T>& aOtherNullable) const {
return mValue == aOtherNullable.mValue;
}
bool operator==(const Nullable<T>& aOtherNullable) const {
return Equals(aOtherNullable);
}
bool operator!=(const Nullable<T>& aOtherNullable) const {
return !Equals(aOtherNullable);
}
friend std::ostream& operator<<(std::ostream& aStream,
const Nullable& aNullable) {
return aStream << aNullable.mValue;
}
};
template <typename T>
void ImplCycleCollectionTraverse(nsCycleCollectionTraversalCallback& aCallback,
Nullable<T>& aNullable, const char* aName,
uint32_t aFlags = 0) {
if (!aNullable.IsNull()) {
ImplCycleCollectionTraverse(aCallback, aNullable.Value(), aName, aFlags);
}
}
template <typename T>
void ImplCycleCollectionUnlink(Nullable<T>& aNullable) {
if (!aNullable.IsNull()) {
ImplCycleCollectionUnlink(aNullable.Value());
}
}
} // namespace mozilla::dom
Bug 742217. Reduce the use of nested namespaces in our binding code. r=peterv,bent In the new setup, all per-interface DOM binding files are exported into mozilla/dom. General files not specific to an interface are also exported into mozilla/dom. In terms of namespaces, most things now live in mozilla::dom. Each interface Foo that has generated code has a mozilla::dom::FooBinding namespace for said generated code (and possibly a mozilla::bindings::FooBinding_workers if there's separate codegen for workers). IDL enums are a bit weird: since the name of the enum and the names of its entries all end up in the same namespace, we still generate a C++ namespace with the name of the IDL enum type with "Values" appended to it, with a ::valuelist inside for the actual C++ enum. We then typedef EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to refer to the values, but means that values from different enums don't collide with each other. The enums with the proto and constructor IDs in them now live under the mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively. Again, this lets us deal sanely with the whole "enum value names are flattened into the namespace the enum is in" deal. The main benefit of this setup (and the reason "Binding" got appended to the per-interface namespaces) is that this way "using mozilla::dom" should Just Work for consumers and still allow C++ code to sanely use the IDL interface names for concrete classes, which is fairly desirable. --HG-- rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
2012-05-03 08:35:38 +04:00
#endif /* mozilla_dom_Nullable_h */