From d04b21c6d6c62e48d998f1e0c94fb49aa9096e7d Mon Sep 17 00:00:00 2001
From: Ian McInerney <ian.s.mcinerney@ieee.org>
Date: Wed, 24 Jan 2024 16:14:32 +0000
Subject: [PATCH] Ensure parameter typeinfo matches the actual object's
 typeinfo

AppleClang seems to generate different typeinfo for forward declarations
of classes than the actual class object, so the any_cast for the pointer
parameter fails due to the types not matching (even when they look the
same when printed in the error).

Instead, we must always ensure we use the actual object when defining
the parameter type when placing the object into the event.
---
 eeschema/tools/ee_actions.cpp | 5 +----
 pcbnew/tools/pcb_actions.cpp  | 4 +---
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/eeschema/tools/ee_actions.cpp b/eeschema/tools/ee_actions.cpp
index ec62cae6c5..ebb89fd34a 100644
--- a/eeschema/tools/ee_actions.cpp
+++ b/eeschema/tools/ee_actions.cpp
@@ -25,14 +25,11 @@
 #include <bitmaps.h>
 #include <core/typeinfo.h>
 #include <layer_ids.h>
+#include <sch_bitmap.h>
 #include <sch_line_wire_bus_tool.h>
 #include <tools/ee_actions.h>
 #include <tool/tool_action.h>
 
-
-// Forward-define of parameter types
-class SCH_BITMAP;
-
 // Actions, being statically-defined, require specialized I18N handling.  We continue to
 // use the _() macro so that string harvesting by the I18N framework doesn't have to be
 // specialized, but we don't translate on initialization and instead do it in the getters.
diff --git a/pcbnew/tools/pcb_actions.cpp b/pcbnew/tools/pcb_actions.cpp
index f69a94857d..3ab4ef315b 100644
--- a/pcbnew/tools/pcb_actions.cpp
+++ b/pcbnew/tools/pcb_actions.cpp
@@ -30,14 +30,12 @@
 #include <bitmaps.h>
 #include <layer_ids.h>
 #include <microwave/microwave_tool.h>
+#include <pcb_reference_image.h>
 #include <tool/tool_manager.h>
 #include <tools/pcb_selection_tool.h>
 #include <router/pns_router.h>
 #include <router/pns_routing_settings.h>
 
-// Forward declarations for types needed in the parameters
-class PCB_REFERENCE_IMAGE;
-
 // Actions, being statically-defined, require specialized I18N handling.  We continue to
 // use the _() macro so that string harvesting by the I18N framework doesn't have to be
 // specialized, but we don't translate on initialization and instead do it in the getters.