An uppercase `AS` on an association-path join leaves its alias unresolved, switching off type checks for its columns

[ako]

What happens

When an association-path join in a view entity writes its alias with an uppercase AS, mxcli check -p … --references resolves nothing for that alias. Every column taken from it goes without type inference. The case where I found it: a pass-through System.UserRole.Name (String(100)) declared as String(200) passes check, and mxbuild then rejects the view with CE6770 "View Entity is out of sync with the OQL Query."

Found while verifying the fix for mendixlabs#1174. A DESCRIBE of a Studio Pro model prints AS in upper case, so this is the ordinary shape of round-tripped OQL, not an exotic spelling.

Repro (Mendix 11.12.1, built from 881aa7ab plus the mendixlabs#1174/mendixlabs#1175 fixes)

create persistent entity MyFirstModule.Sale1174 ( Amount: Integer );
create association MyFirstModule.Sale1174_UserRole
  from MyFirstModule.Sale1174 to System.UserRole;

then mxcli check v.mdl -p App.mpr --references on:

create view entity MyFirstModule.Q2 (
  RoleName: String(200),
  Total: Integer
) as (
  select r.Name as RoleName, sum(s.Amount) as Total
  from MyFirstModule.Sale1174 as s
  join s/MyFirstModule.Sale1174_UserRole/System.UserRole AS r
  group by r.Name
);

→ Check passed!

Control

Only the case of that one as is changed. Each variant was run against the same project; the count is how many times the check reported inherits length 100 from source attribute System.UserRole.Name:

Variant	Reported
join s/…/System.UserRole as r	1
left join s/…/System.UserRole as r	1
JOIN s/… / GROUP BY / SELECT / FROM in upper case, as lower	1
join s/…/System.UserRole AS r	0

The other keywords can be in upper case without effect. Only the AS before a path alias matters.

Cause

extractAliasMap in mdl/executor/oql_type_inference.go matches the path join case-insensitively ((?i)…(?:as\s+)?), then recovers the path from the match with a case-sensitive trim:

path = strings.TrimSpace(strings.TrimSuffix(strings.TrimSpace(path), "as"))

With AS, the path stays s/MyFirstModule.Sale1174_UserRole/System.UserRole AS. The end-anchored lastEntity regex then fails, so the alias is never added to the map. The plain from|join Entity as x pattern above it has no such trim and is unaffected.

Expected

The alias resolves regardless of the case of AS, and the check reports the same MDL031 length mismatch it reports for as. A likely fix is to capture the path as its own regex group rather than recovering it by trimming, with a unit test over extractAliasMap for both spellings.