in-statements are resolved before inheritance and this is unintuitive. Explain that one can instead re-declare blocks and macros that were inherited, effectively yielding similar results. Signed-off-by: Dominick Grift <dominick.grift@xxxxxxxxxxx> --- secilc/docs/cil_container_statements.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/secilc/docs/cil_container_statements.md b/secilc/docs/cil_container_statements.md index 41a4612c..0259778c 100644 --- a/secilc/docs/cil_container_statements.md +++ b/secilc/docs/cil_container_statements.md @@ -282,6 +282,8 @@ Allows the insertion of CIL statements into a named container ([`block`](cil_con Not allowed in [`macro`](cil_call_macro_statements.md#macro), [`booleanif`](cil_conditional_statements.md#booleanif), and other [`in`](cil_container_statements.md#in) blocks. +Note that [`in`](cil_container_statements.md#in) statements referencing blocks and macros that were inherited cannot be resolved and that instead it is allowed to re-declare blocks and macros that were inherited, resulting in similar behavior. + [`tunable`](cil_conditional_statements.md#tunable) and [`in`](cil_container_statements.md#in) statements are not allowed in [`in`](cil_container_statements.md#in) blocks. **Statement definition:** -- 2.32.0
