Remove `p` prefix on repository data, generate and publish non-prefixed export

[sciwhiz12]

Discussion in internal channels have determined consensus for the following actions:

• Remove the requirement of the p prefix in the mapping standards for parameter names (namely, #2, #6, #8).
• Remove the p prefix in the repository data.
• Have two exports: the main prefixed version (prefixing all parameter names with p and capitalizing the second letter), and a non-prefixed version (the raw parameter names).

This was driven and supported by the following reasons:

• Users would rather prefer using parameter names which do not have a mandatory prefix, for readability purposes.
• The original reason for the prefix was to prevent conflicts between the parameter names and local variable names (as determined by the decompiler). However, loaders may choose to do their own adjustments to ensure that parameter names do not conflict with the parameter names, which would not be difficult to do.
  • Additionally, it is usually rare that a local variable will conflict to a parameter name, as usually local variable names outputted by decompilers are in a deterministic and simplisitic format.
• Contribution to parameter names would be easier without needing to keep in mind the p prefix.
• Parameter names are simple enough (as constrained by the standards) that auto-prefixing of the data with p is very possible.

While the possibility of exporting only a non-prefixed version of the data was discussed, one of the goals of the exports is that they are 'working mappings', in that they do not need modification by the loaders/consumers to ensure they work as the p prefix ensures that it never matches any decompiler's output for local variables, whereas the unprefixed names have a possibility of conflicting with decompiler output. Therefore, we will export both a prefixed and non-prefixed version, and loaders can opt to use the non-prefixed version if they chooose to do so.

One further question that needs to be addressed is how to publish the unprefixed version. There are two possbilities: exporting it as a separate artifact under a different classifier (possibly even being the no classifier version), or exporting it as an additional file in the no classifier artifact (possibly under the file name of unprefixed.json).

[mcenderdragon]

I guess exporting it as its own artifact would be easier to implement in FG and similar tools, as it is just a different maven path.

[alcatrazEscapee]

A bit of an addendum to this:

Motivation for the prefixed export is to solve point 1. in ParchmentMC/Compass#5. Namely, avoid conflicts between local variables, and other parameter names.

Also detailed in the linked issue are two other types of possible parameter-name-induced-compile-errors, and the motivation for why that is a problem for Forge, and only Forge.

To the possibility of creating an "unprefixed" export, and a prefixed one, another possible suggestion would be to create a "clean" export, and a "ensured-no-compile-errors" export.

• The former would be exactly as is discussed here: removal of the p prefix (or any form of global prefixing to avoid conflicts.)
• The latter would involve the following safeguards, all motivated from ParchmentMC/Compass#5
  • Inclusion of the p prefix
  • Removal of any mapped lambda parameter names
  • Removal of any mapped parameters belonging to anonymous classes.