search

QuiltMC / rfcs

Repository for requests for comments for proposing changes to the Quilt Project.
Other
61 stars 33 forks source link

RFC 3: A High-Level Look at Collision Handling ASM #3

Closed TheGlitch76 closed 3 years ago

TheGlitch76 commented 3 years ago

EDIT: The Processor section of this RFC is completely out-of-date, it will be updated soon:tm:

Rendered View

Earthcomputer commented 3 years ago

"Rendered view" link is broken

phase commented 3 years ago

Updated rendered view

2xsaiko commented 3 years ago

Am I reading this right in that transformers are java classes in this document? Why? Shouldn't they be data (of how to transform other classes) instead of code, that the processor then interprets?

LemmaEOF commented 3 years ago

The document just states that transformers are kept in the jar, not the form they take.

Kroppeb commented 3 years ago

Am I reading this right in that transformers are java classes in this document? Why? Shouldn't they be data (of how to transform other classes) instead of code, that the processor then interprets?

But we want the transformers to be powerful and give modmakers the ability to add their own transformers, so either we write an interpreter to run "code" in the transformer file, or we can you give the file to the build-in interpreter of the jvm.

CheaterCodes commented 3 years ago

Am I reading this right in that transformers are java classes in this document? Why? Shouldn't they be data (of how to transform other classes) instead of code, that the processor then interprets?

Well, we want a data format that can cover all possible use cases. Not just simply copy&paste transformations, but also conflict-free overwrites, conditional transformations and potentially much more. Such a data format seems complicated, but conveniently Java bytecode covers it fully.

There's other stuff I like about it, like simple tooling. I've written an annotation processor to take mixins and emit Java code. That code simply gets compiled and bundled with the rest of the mod, just waiting for the loader to get passed to the processor.

2xsaiko commented 3 years ago

The document just states that transformers are kept in the jar, not the form they take.

no it doesn't:

The Compiler is responsible for reading the Frontend as high-level metadata and emitting Transformers as low-level classes loadable by the JVM.

Such a data format seems complicated, but conveniently Java bytecode covers it fully.

Okay, I said nothing then ;) I assume they will work somewhat like Forge's old ASM transformers then (but of course with a different API for the transformers that is more safe in regards to conflicts)? I was originally thinking that if the processor loads the transformations as some data structure, then it can figure out how to combine multiple potentially overlapping transformations together because it knows everything about each of them, where that's not possible if they are code. But maybe that's not actually a problem or you've already figured it out.

LemmaEOF commented 3 years ago

...did I just completely misread it rip mea culpa

2xsaiko commented 3 years ago

All good haha

Earthcomputer commented 3 years ago

I assume they will work somewhat like Forge's old ASM transformers then

This is actually not how it's going to work. Transformers will look a lot like Forge's ASM transformers in the read phase, i.e. when they are searching for nodes to replace. However the write phase will be much more controlled. During the read phase, the transformer selects nodes that it wants to replace during the write phase. In the write phase, the transformer only constructs the new replacement node(s). The processor will know before the write phase exactly which nodes will be replaced by what transformer, this is what makes it safer than raw ASM.

CheaterCodes commented 3 years ago

but of course with a different API for the transformers that is more safe in regards to conflicts?

Detecting conflicts is something the processor can do. Avoiding conflicts is mostly left to the compilers though. E. g. two mixins overwriting the same method is still gonna be a conflict that will be detected, but can't be avoided by the processor. However, a different compiler might be able to allow two non-conflicting (e. g. conditional) overwrites. There are some tricks in place to allow for that sorta stuff, but I think that'll be for the processor RFC.

darkerbit commented 3 years ago

New name for ASMR from the 26.06. developer meeting: CHASM, short for Collision Handling ASM