Tiny v2 spec: new standard property - check-package-access

[liach]

In the aftermath of FabricMC/yarn#2057 (comment), it's obvious that sometimes informative mappings need to sacrifice package access.

Hence, I propose a new standard property (see #9):
check-package-access.

This property can exist in two forms:

• <tab> check-package-access: indicates that for all namespaces, there may be illegal package access issues
• <tab> check-package-access <values> where <values> is a string that
  • each element is t or f
  • has length no more than the count of namespaces

In the array case, whether each namespace has illegal access package issues is determined by the value (t for true, f for false) at the corresponding (by the order namespaces appear in header) index in the array. If the index we want to seek exceeds the check package access array's length, we assume this namespace does have package access issues (like having a t).

So for each future yarn mapping, we will have something like

tiny	2	0	official	intermediary	named
	check-package-access	fft

indicating that illegal package access are not of concern for official and intermediary namespaces, but should be considered for the named namespace.

This can also solve the TODO for https://github.com/FabricMC/fabric-loader/blob/77b793599803a250b5ed840fe0c637975e5f4d78/src/main/java/net/fabricmc/loader/launch/common/MappingConfiguration.java#L72-L73 and increase compatibility for other 3rd-party mappings like bukkit (which can be hurt due to proguard removing some classes in a package, like that observed in FabricMC/yarn#2074 (comment))

@sfPlayer1 for review and triage.

[liach]

@sfPlayer1 Since you are active right now, I hope you make a short comment on this proposal, such as if this is needed or not, or if there is a better alternative.

[sfPlayer1]

Not sure, I think this effectively falls into performance tweak territory since enabling the access checker/fixer shouldn't cause any other harm. Fabric's uses may be best served by leaving it on always, caching the remapped jars supersedes any modest perf boost.

[liach]

Hmm, does fabric generate a cached remapped jar for dev env? It probably should do so, but its current way of handling package access problems does not seem to cache at all. Guess this should be moved to loader as well.

But yes, if a namespace has no access issue, turning on access fix shouldn't affect the result bytecode at all.