| 1 | ! audit31 Finding 10: `allocate(arr(i)%alloc_comp(n))` used to be |
| 2 | ! rejected by validate_allocatable_item. It ran extract_base_name |
| 3 | ! on the target and checked attrs on the ROOT (`pools`) instead of |
| 4 | ! the leaf component (`tokens`). Sema doesn't track per-field |
| 5 | ! attribute metadata today, so component-access targets now skip |
| 6 | ! the pre-lowering allocatability check; the lowering path still |
| 7 | ! requires the leaf to be allocatable. Task #491. |
| 8 | ! |
| 9 | ! This test verifies ALLOCATE itself is accepted and produces a |
| 10 | ! runnable binary. Reading back the allocated data (size() and |
| 11 | ! element access through `pools(i)%tokens(j)`) is a distinct |
| 12 | ! lowering gap and is deferred. |
| 13 | ! CHECK: ok |
| 14 | program audit31_alloc_component |
| 15 | implicit none |
| 16 | type :: pool_t |
| 17 | integer, allocatable :: tokens(:) |
| 18 | integer :: capacity = 0 |
| 19 | end type |
| 20 | type(pool_t) :: pools(4) |
| 21 | allocate(pools(1)%tokens(10)) |
| 22 | print *, 'ok' |
| 23 | end program |
| 24 |