ladybird/Userland/Libraries/LibIPC/Forward.h

/*
 * Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#pragma once

namespace IPC {

class Decoder;
class Dictionary;
class Encoder;
class Message;
class File;
class Stub;

template<typename T>
bool encode(Encoder&, T const&);

template<typename T>
ErrorOr<T> decode(Decoder&);

}
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00			`/*`
			`* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>`
			`*`
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt * 2021-04-22 01:24:48 -07:00			`* SPDX-License-Identifier: BSD-2-Clause`
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00			`*/`

			`#pragma once`

			`namespace IPC {`

			`class Decoder;`
LibIPC: Add a simple IPC::Dictionary type (String key -> String value) 2020-05-03 22:15:27 +02:00			`class Dictionary;`
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00			`class Encoder;`
			`class Message;`
LibIPC: Support sending file descriptors :^) It is now possible to use the special IPC::File type in message arguments. In C++, the type is nothing more than a wrapper over a file descriptor. But when serializing/deserializing IPC::File arguments, LibIPC will use the sendfd/recvfd kernel APIs instead of sending the integer inline. This makes it quite convenient to pass files over IPC, and will allow us to significantly tighten sandboxes in the future :^) Closes https://github.com/SerenityOS/serenity/issues/3643 2020-11-21 21:59:12 +03:00			`class File;`
LibIPC: Add IPC::Stub to forwarding header 2021-10-23 21:40:07 +02:00			`class Stub;`
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00
LibIPC: Forward declare the encode() and decode() template functions For the most part, we try to provide specializations of these functions in various headers by including "LibIPC/Forward.h" and then declaring encode() and decode() specializations. However, without any forward declaration of these types, we aren't actually specializing anything. Rather, we are just declaring overloads, which trips up the base encode and decode template definitions. The result is that LibIPC is very sensitive to include order, and the DependentFalse<> static assertion would fail if the includes weren't perfectly ordered. By properly forward declaring these templates, we can make sure the specializations receive precedence over the base templates. 2022-11-15 10:01:23 -05:00			`template<typename T>`
			`bool encode(Encoder&, T const&);`

			`template<typename T>`
LibIPC+Everywhere: Change IPC decoders to construct values in-place Currently, the generated IPC decoders will default-construct the type to be decoded, then pass that value by reference to the concrete decoder. This, of course, requires that the type is default-constructible. This was an issue for decoding Variants, which had to require the first type in the Variant list is Empty, to ensure it is default constructible. Further, this made it possible for values to become uninitialized in user-defined decoders. This patch makes the decoder interface such that the concrete decoders themselves contruct the decoded type upon return from the decoder. To do so, the default decoders in IPC::Decoder had to be moved to the IPC namespace scope, as these decoders are now specializations instead of overloaded methods (C++ requires specializations to be in a namespace scope). 2022-12-22 20:40:33 -05:00			`ErrorOr<T> decode(Decoder&);`
LibIPC: Forward declare the encode() and decode() template functions For the most part, we try to provide specializations of these functions in various headers by including "LibIPC/Forward.h" and then declaring encode() and decode() specializations. However, without any forward declaration of these types, we aren't actually specializing anything. Rather, we are just declaring overloads, which trips up the base encode and decode template definitions. The result is that LibIPC is very sensitive to include order, and the DependentFalse<> static assertion would fail if the includes weren't perfectly ordered. By properly forward declaring these templates, we can make sure the specializations receive precedence over the base templates. 2022-11-15 10:01:23 -05:00
LibIPC: Add forwarding header for LibIPC 2020-03-29 18:57:53 +02:00			`}`