A dynamic tensor's rank is assumed to be 2 at a type annotation, so a rank-1 one produces invalid MLIR

A tensor type with no dimensions lowers to memref<?x?xT> — rank 2, assumed. A dynamic value keeps its real rank, so the two disagree at a call boundary.

fn takes(t : DynTensor<f32>) -> i32 { return 0; }
fn k(n : i32) -> i32 {
  let a = Tensor<f32>([n]);   // rank-1, extent runtime
  a[0] = 1.0;
  return takes(a);
}

'memref.cast' op operand type 'memref<?xf32>' and result type 'memref<?x?xf32>' are cast incompatible
MLIR verification failed

The value lowers correctly (memref.alloc(%0) : memref<?xf32>); the parameter's type is what invents rank 2, because the type carries no rank to read.

Pre-existing and inherited, not caused by the DynTensor split (#399): the identical program with the old dims-less Tensor<f32> parameter fails the same way, since that spelling lowered to ?x? too.

The design question

Rank and extents are different kinds of unknown. MLIR already separates them — memref<?x?xf32> is known rank, unknown extents, and memref<*xf32> is unranked. Nearly all real code knows its rank statically and only learns extents at run time, which is the case DynTensor exists for.

So DynTensor<T> probably wants to carry a rank: the shape is dynamic, the rank is not. Spelling options include an explicit DynTensor<f32, 2>, or inferring it where the value is constructed. Lowering to an unranked memref<*xT> instead would be honest but pushes a rank recovery onto every index.

Until that is settled, a rank-1 dynamic tensor cannot cross a function boundary.

The issue does not name files, tests, or entry points. Start by tracing lowering for the dynamic tensor parameter and the rank-1 value at the function call boundary, then compare their MLIR types. Done means the rank-1 dynamic tensor can cross the boundary without an MLIR verification failure, after the rank representation design is settled.