-
-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring of target properties and their validation #2008
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great improvement! I haven't looked carefully at all the changes yet, but I left some comments in places where I noticed issues or had questions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a big effort that makes target properties more robust by relying less on String operations. Looks good to me overall. Thanks for working on this @lhstrh. :-)
This PR reworks the way we deal with target properties. It makes them easier to specify, manipulate, and verify. It cuts down on the use of lambda functions, which makes the code a bit more verbose, but also more reusable and more readable. The
TargetProperty
class that had become a depository of random helper classes has been cleaned and brought down from 1800 LOC to less than 300.While the goal of this refactoring is to retain the same functionality, some changes were made in the name of enforcing consistency:
--target-compiler
CLI argument changed to--compiler
so that it matches thecompiler
target propertyElement
instead ofKeyValuePair
) and with simpler messages--no-compile
flag/target propertyDebug
)Target
class and revise "supported by" mechanismlingo
)Fixes #1558.
Fixes #2001.
Fixes #1919.
Fixes #1859.