ladybird/Userland/Libraries/LibIPC/Forward.h

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

#pragma once

#include <AK/Error.h>

namespace IPC {

class Decoder;
class Encoder;
class Message;
struct MessageBuffer;
class File;
class Stub;

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

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

}
LibIPC: Add forwarding header for LibIPC 2020-03-29 16:57:53 +00: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 08:24:48 +00:00			`* SPDX-License-Identifier: BSD-2-Clause`
LibIPC: Add forwarding header for LibIPC 2020-03-29 16:57:53 +00:00			`*/`

			`#pragma once`

LibIPC+Everywhere: Change IPC::encode's return type to ErrorOr In doing so, this removes all uses of the Encoder's stream operator, except for where it is currently still used in the generated IPC code. So the stream operator currently discards any errors, which is the existing behavior. A subsequent commit will propagate the errors. 2023-01-02 04:37:35 +00:00			`#include <AK/Error.h>`

LibIPC: Add forwarding header for LibIPC 2020-03-29 16:57:53 +00:00			`namespace IPC {`

			`class Decoder;`
			`class Encoder;`
			`class Message;`
LibIPC: Move MessageBuffer forward declaration from Stub.h to Forward.h The type of MessageBuffer will be changing, and it was a bit awkward to look around to find where the forward declaration was. This patch just moves it to the obvious forwarding header. 2024-01-03 01:18:48 +00:00			`struct MessageBuffer;`
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 18:59:12 +00:00			`class File;`
LibIPC: Add IPC::Stub to forwarding header 2021-10-23 19:40:07 +00:00			`class Stub;`
LibIPC: Add forwarding header for LibIPC 2020-03-29 16:57:53 +00: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 15:01:23 +00:00			`template<typename T>`
LibIPC+Everywhere: Change IPC::encode's return type to ErrorOr In doing so, this removes all uses of the Encoder's stream operator, except for where it is currently still used in the generated IPC code. So the stream operator currently discards any errors, which is the existing behavior. A subsequent commit will propagate the errors. 2023-01-02 04:37:35 +00:00			`ErrorOr<void> encode(Encoder&, T const&);`
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 15:01:23 +00:00
			`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-23 01:40:33 +00: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 15:01:23 +00:00
LibIPC: Add forwarding header for LibIPC 2020-03-29 16:57:53 +00:00			`}`