Rename some keyword locations for consistency

[Earlopain]

Prism is generally good about their naming but these had some inconsistencies compared to others:

• InNode was missing the keyword in the name
• MatchPredicateNode in was named operator instead
• UnlessNode/UntilNode/WhenNode/WhileNode has more than one keyword, with one generic keyword_loc
• UntilNode/WhileNode named their end keyword closing_loc

Left the old names around for compatibility

[kddnewton]

I'm generally okay with doing this, but I just want to check — can you enumerate our rules for naming? Maybe we should explicitly write them down? Is it keyword_loc if there's only one and then *_keyword_loc when there are multiple?

[Earlopain]

Yeah, you got that right basically.

Some like {/do for blocks are just opening since it's not exclusively for keywords.

IfNode is a bit messy since it's for both keyword and ternary and it reuses the keyword locations for :/? with ElseNode. Conceptually they are very close but structure is pretty different. Seems like that should maybe have been a separate node but I don't want to touch that.

I don't really know what where to put docs about general rules, is there a place that would fit? I can write something if you want (although I don't think it would be relevant very often, should just look at rdoc)

[kddnewton]

I think it's probably fine to leave it out of the docs, I hope this won't change again.

Can you actually get rid of the node_ext stuff? In theory the next release is 2.0.0, people will have to update stuff anyway. Let's just make this a breaking change.

[eregon]

Can you actually get rid of the node_ext stuff? In theory the next release is 2.0.0, people will have to update stuff anyway. Let's just make this a breaking change.

Is that worth it?

It seems like the compatibility cost of keeping the old node_ext aliases is pretty small, while removing them could cause a lot of ecosystem churn.

A few cases I’m worried about:

• Gems that depend on prism without a < 2 constraint would break immediately, with no deprecation period.
• Gems that want to support Ruby 4.1 syntax will have to migrate to Prism 2, since Prism 1 won’t support Ruby 4.1. So there will be some time after the Ruby 4.1 release where such gems will not work, but it would have otherwise.
• Default gems and gems that use Prism when available but don’t directly depend on it, like error_highlight, would need conditionals for Prism 1 vs 2 naming. That seems pretty cumbersome for a fairly small cleanup.

I looked at #3990, but I don’t see a strong motivation there for intentionally breaking the Ruby API unless we need to. Is there enough value in removing these aliases now, rather than keeping them around for compatibility?

[Earlopain]

(just rebased)

Yes, I would prefer to keep the old ones around as well. irb for example would need to be updated immediatly because it uses one of the impacted locations (and also doesn't pin the major)

[kddnewton]

Okay, that's convincing. Can we use alias for them though?

[Earlopain]

Let me check, I think I didn't because typechecking doesn't like that at all

[Earlopain]

Ah, yeah. So I think rbs has support for them but the rbi compiler currently has all the aliases explicitly listed out

prism/rakelib/typecheck.rake

Line 141 in d290a34

when RBS::AST::Members::Alias

and I don't really know what to do about that. Currently it just falls through to the else which just raises.