Skip to content

Fully qualify extend T::Generic & T::Helpers - #1001

Draft
dejmedus wants to merge 4 commits into
mainfrom
jb-qualify-extend-t
Draft

Fully qualify extend T::Generic & T::Helpers#1001
dejmedus wants to merge 4 commits into
mainfrom
jb-qualify-extend-t

Conversation

@dejmedus

@dejmedus dejmedus commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

To ensure T::Generic and T::Helpers don't conflict with user defined T constants, we can fully qualify any existing or translator inserted T::Generic/Helpers to ::T::

This raised a small bug in already_extends? logic that was previously causing a duplicate extend T::Generic/Helpers

Previously, a TypeError could be raised when we tried
to insert an `extend T::Generic` or `extend T::Helpers`
into a class that had a generic type member called `T`

This commit fully qualifies inserted extends to
`::T::Generic` and `::T::Helpers` to prevent this
Previously, `already_extends?` looked through the
child nodes to find `extends`. However, as these
are wrapped in a `Prism::StatementsNode`, they were
not being detected causing a duplicate `extend` to be inserted

This commit fixes that by checking statements instead
Generated helper calls and type members are generally
inserted at the beginning of a scope. A manually written
extend `T::Generic` or extend `T::Helpers` may then
appear too late to be useful

This commit removes hardcoded `extend`s in favor of
inserting where needed, ensuring the correct order
without duplicates
@dejmedus
dejmedus force-pushed the jb-qualify-extend-t branch from 78a7d08 to e02d892 Compare August 6, 2026 22:42
@dejmedus
dejmedus force-pushed the jb-qualify-extend-t branch from e02d892 to 90f5578 Compare August 6, 2026 23:00
unless already_extends?(node, /^(::)?T::Helpers$/)
extend_with("T::Helpers", into: node, at: insert_pos)
end
find_and_remove_existing_extend(node, /^(::)?T::Helpers$/)

@amomchilov amomchilov Aug 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we should try to fix a pre-existing extend T::Helpers like this.

It's a nice feature in theory, but narrow. There are many other explicit uses of T that would be problematic (T.untyped, T::Boolean, T.any, ...), which we couldn't patch up as easily/reliably. I'm inclined err of inaction, and require people fix their own explicit usages of T.

I suppose the distinction is: who wrote the T?

If our rewriter wrote it, we should be good stewards and ::T it. If devs wrote it explicitly in their own source, they should choose ::T if they want it (or rename their generic arg to not be called T).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Morriar wdyt?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Generic types called T can lead to TypeError

2 participants