You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[mbr] Return -1 if relative index is not in given generation (#49795)
Logically after an update is applied, tokens refer to rows in tables that are a
concatenation of all the added rows from every update. (ie: if the baseline
table 0x23 had 2 rows and then generation 1 an added 3 more rows, an index like 0x05
refers to table 0x23 row 3 from gen 1).
The way the lookup works is that the EnC map table records the logical tokens
of the update. So for table 0x23 the 3 additions in gen 1 will have entries
like encmap row 5 = 0x23000003, row 6 = 0x23000004, row 7 = 0x23000005, and
then rows for the next table and so on. The relative index in gen1 of token
0x23000005 then, is the distance of its row (ie row 7) from the first token for
the table (ie row 5), plus 1 (since tokens are 1-based). So in this case token
0x23000005 corresponds to the 7-5+1 = 3rd row of table 0x23 in the gen1 dmeta image.
The problem is that previously we returns this index-base+1 computation even in
cases where we walked either to the end of the encmap table or past the last
row for the table we care about.
In the case where we walked to the end of the encmap table, the index-base+1
could sometimes return a value that looked like a valid token. The upshot is
that we looked up an incorrect AssemblyRef (0x23 table) from the wrong
generation.
The updated code returns -1 for all cases where we didn't find an encmap row
for our given token.
Example: https://gist.github.com/lambdageek/cd7ea06bf5004ba884e7979f28623da5
0 commit comments