Cannot use macro return value in another macro's parameter(indirectly)

[codehz]

What version of Bun is running?

v1.0.8

What platform is your computer?

Darwin 23.1.0 arm64 arm

What steps can reproduce the bug?

import { keyframes, create } from "css-in-bun" assert { type: "macro" };

const test = keyframes({
  "0%": {
    opacity: 0,
  },
  "100%": {
    opacity: 1,
  },
});

const styles = create({
  test: {
    animationName: test,
    color: "red",
  },
});

console.log(test, styles);

What is the expected behavior?

the identifier "test" should be treated as statically-known value, since it is macro's return value

What do you see instead?

error: Cannot convert identifier to JS. Try a statically-known value

Additional information

If I manually inline the call, it is working

const styles = create({
  test: {
    animationName: keyframes({
      "0%": {
        opacity: 0,
      },
      "100%": {
        opacity: 1,
      },
    }),
    color: "red",
  },
});

[Jarred-Sumner]

Is this at runtime or in bun build? If it's bun build, does it work if you pass bun build --minify?

[codehz]

Is this at runtime or in bun build? If it's bun build, does it work if you pass bun build --minify?

using the build script

import { getGeneratedCss } from "css-in-bun/build";
const result = await Bun.build({
  entrypoints: ["./test.ts"],
  outdir: "dist",
});
console.log(result);
console.log(getGeneratedCss());

[codehz]

Is this at runtime or in bun build? If it's bun build, does it work if you pass bun build --minify?

Ok, it is working if enable the minify, but I don't think it should affect the behavior..

[codehz]

I think the problem here is a bit tricky. if we inline all object which returned from macro, the object equality will be violated (see #7196), it will also prevents you from modifying the object at runtime. But if not inline the object, you will not be able to use value in other macro. I hope that the semantics here can maintain consistency to a certain extent, and at the same time not cause too much trouble to users (such as preventing users from modifying the returned object), because there is no zig-like comptime keyword to distinguish between runtime values and comptime values. I think we can accept that the value at bundle time may not be consistent with the value at runtime, for example, if user modified the object in the runtime, the macro still get the original value in bundle time.