Inconsistent {{@type}} expansion in macros

[bcardiff]

If the macro is inside a module, the @type is referring to the container module instead of the type where the macro is expanded.

Running the docs tool with the following code exhibits the differences. But the issue affects also the generated code.

I was expecting to always be the type were the macro is executed (since the otherone can be explicitly mentioned)

module XXX
  macro m
    # This will be XXX (not ideal) `{{@type}}`
    def foo
      {{@type}}
    end
  end
end

macro m
  # This will be Foo (ideal) `{{@type}}`
  def bar
    {{@type}}
  end
end

class Foo
  XXX.m
  m
end

pp! Foo.new.foo # => XXX
pp! Foo.new.bar # => Foo

Extracted from #8994

[asterite]

Right now you can do:

UInt8.slice(1, 2, 3)

That generates:

Slice(UInt8)...

The macro uses {{@type}} to get the UInt8 type.

Essentially, it seems there's no way to fix this unless we have a way to refer to where the macro is called, and where the macro is defined.

[asterite]

Right now self inside macros gives an error because it has no meaning. We could make self work for this purpose: it's the type where the macro is defined. On the other hand, @type is the type where the macro is expanded.

When the macro happens inside a method, like:

class Foo
  def foo
    {{@type}}
  end
end

then @type and self will be the same. In the examples provided by @bcardiff @type will work as he expects it, which I think is what's expected, and self will return XXX inside XXX.m but will give an error saying "there's no self" inside the top-level macro m... just like what happens with regular methods.

However, this is a breaking change.