[knQzx]

is_intronic only recognized introns on coding (c.) coordinates because it gated on the interval being a BaseOffsetInterval. RNA (r.) coordinates parse to a plain Interval whose endpoints are still BaseOffsetPosition, so intronic r. variants slipped past the "Intronic HGVS variants are not supported" guard

inspect the interval endpoints instead of the interval type. g./p. coordinates have no base-offset positions and stay non-intronic

closes #628

[korikuzma]

Thanks @knQzx ! I was wondering if we should include the entire tests that @theferrit32 included in addition to the ones you added?

@theferrit32 did you want to review this?

[knQzx]

Good call - added theferrit32's four ClinVar r. examples from #628 as exonic (non-intronic) regression pins. They parse offline so the fixture stays network-free, all 11 cases pass locally.

[MargoSolo]

Confirming this on hgvs 1.5.7, with one data point that I think strengthens the case for merging.

The missed guard is not only a missing ValueError. AlleleTranslator.from_hgvs goes through
HgvsTools.extract_allele_values, so when is_intronic returns False the expression falls
through to get_position_and_state, which reads pos.start.base and drops the offset:

NM_000551.3:r.100+5a>g  ->  (99, 100, 'g')

That is the Allele for exonic base 100, returned without any warning. So on current main these
inputs produce a silently incorrect VRS object rather than an error. I also checked that g.,
m. and p. positions stay non-intronic under the endpoint-based check, and that
c.*10+5A>G / c.-10+5A>G keep working.

[theferrit32]

I'm okay with merging this as-is to main.

I think there is additional follow-up needed to handle a few more edge cases but that can be a separate piece of work from this.