Ecma262: Some old section permalinks are not valid anymore

[bendtherules]

Some old section permalinks used in the spec are not valid anymore. Can we map them back?

I found these while looking through the engine262 codebase (https://github.com/engine262/engine262/issues/106) . Here is a list of those invalid ids - checked against the current hosted version.

Same gist contains a script to test against any version of the spec - that can be used to figure out when it did exist.

1. Should I try to make a table showing when these ids existed and what they should map to now?
2. What is the mechanism to make these links valid again?

I'll be happy to raise a PR or help investigate this further.

[jmdyck]

Some old section permalinks used in the spec are not valid anymore. [...] Here is a list of those invalid ids

I ran git log -S (and, just to make sure, git log -G) on all of these. Most returned no results, suggesting that these strings have never existed on the master branch. Probably they come from a proposal or a PR. E.g., sec-weakref-execution comes from engine262's reference to
https://tc39.es/proposal-weakrefs/#sec-weakref-execution
You should exclude such documents from your collection process. (Or collect them, but be sure to check them against the ids defined in that document, not the main spec.)

Of the ones that do return results, most are just truncations of valid ids. E.g.
sec-proxy-object-internal-methods-and-internal-slots-call-thisargument-argume
is a truncation of
sec-proxy-object-internal-methods-and-internal-slots-call-thisargument-argumentslist
(The truncation appears to be a bug in your collection process; engine262 has 2 occurrences of the correct id, but none of the truncated form.)

And git log -S shows hits for sec-promise. and sec-string.prototype. because they're prefixes of lots of valid ids, but it's pretty unlikely that they themselves were ever ids, because of the trailing dot. (Again, this appears to be a bug in your collection process, as those strings don't appear as complete ids in the engine262 source.)

If you revise your collection process, I suspect the only cases it will find will be:
sec-evaluate-expression-key-property-access
sec-evaluate-identifier-key-property-access
which existed on master for a couple months, between the merges of PR #1646 and PR #1787.

2. What is the mechanism to make these links valid again?

It would be to add an "oldids" attribute to the appropriate HTML element.

[bendtherules]

@jmdyck Thanks for the detailed look. There were indeed lot of problems with my collection.

I have tried to fix them now and verified the items manually. This is the shorter 6-item list -

// first 3 from proposal ??
sec-numeric-types-bigint-unsighedRightShift
sec-allocatedtypedarray
sec-typedarray-species-create
// 
sec-running-execution-context
sec-evaluate-expression-key-property-access
sec-evaluate-identifier-key-property-acces

First 3 items look like they were recently added. Can those be actually proposal sections? @devsnek.
Rest look like old sections (including the two you mentioned).

[devsnek]

```diff
- sec-numeric-types-bigint-unsighedRightShift
+ sec-numeric-types-bigint-unsignedRightShift

• sec-allocatedtypedarray

• sec-allocatetypedarray

• sec-typedarray-species-create

• typedarray-species-create

• sec-running-execution-context

• running-execution-context

• sec-evaluate-expression-key-property-access

• sec-evaluate-property-access-with-expression-key

• sec-evaluate-identifier-key-property-acces

• sec-evaluate-property-access-with-identifier-key

[bendtherules]

@devsnek So first 4 are typos on engine262 repo and rest 2 are still old ids?

[devsnek]

@bendtherules looks like it.

[ljharb]

a PR to fix those 2 oldIDs would be appreciated.

[bendtherules]

@ljharb Added PR #2071 😀

[bakkot]

If you revise your collection process, I suspect the only cases it will find will be:
sec-evaluate-expression-key-property-access
sec-evaluate-identifier-key-property-access
which existed on master for a couple months, between the merges of PR #1646 and PR #1787.

For anyone else confused by why #1787 doesn't appear to touch these IDs, it's because the relevant commit, 384978f22bea3e6b13d6058aaaf25e6a2ffec0c1, was pulled in apart from the rest of that PR.

[jmdyck]

For anyone else confused by why #1787 doesn't appear to touch these IDs, it's because the relevant commit, 384978f, was pulled in apart from the rest of that PR.

Ah right, I forgot. So the 'old' ids from 1646 only existed on master for about 3 weeks.