@index cannot be used in the CPU if is not a direct rhs of an assignment

# This works flawlessly
@kernel function f()
           a = @index(Global, Cartesian)
           @print(a[1])

# This doesn't compile in CPU
@kernel function f()
           a = let 
               @index(Global, Cartesian)
               end
           @print(a[1])

My guess is that the @kernel macro, will only insert the idx parameter required for CPU indexing when the @index macro is a direct assignment. Maybe a more complex logic to retrieve the indicies should be applied?

# macros.jl line 290:
 elseif @capture(stmt, lhs_ = rhs_ | (vs__, lhs_ = rhs_))
            if @capture(rhs, @index(args__))
                push!(indicies, stmt)
                continue

# macros.jl line 242:
function emit(loop)
    idx = gensym(:I)
    for stmt in loop.indicies
        # splice index into the i = @index(Cartesian, $idx)
        @assert stmt.head === :(=)
        rhs = stmt.args[2]
        push!(rhs.args, idx)
    end

This also means that there's a bit of inconsistence about how indexing is applied in CPU and in GPU:

# This code is valid in CPU
@kernel function f()
           a = @index(Global, Cartesian)
           @print(a[1])

# But this code is invalid in CPU and valid in GPU
@kernel function f()
           a = @index(Global, Cartesian)[1]
           @print(a)

Start in macros.jl around lines 242 and 290, and reproduce the two @index forms shown in the issue on CPU and GPU. Trace how emit handles direct assignments and determine how nested or indexed uses should be recognized. Done means the demonstrated CPU forms compile consistently without regressing the GPU behavior.