-
Notifications
You must be signed in to change notification settings - Fork 756
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
Fix code suggestion for PR #23473 #24179
Fix code suggestion for PR #23473 #24179
Conversation
Annotation value is restricted to true, map<anydata|readonly> or map<anydata|readonly>[] value. Changes will also make sure that annotation value is a read only clone of the given value. Therefore user cannot change annotation value via annotation access.
Uniformity for `readonly & T` and `T & readonly`. Chose `readonly & T`. Refactor java code logic. Instead of making fields readonly for implementations of abstract objects, whole object is made readonly.
switch (expr.getKind()) { | ||
case LITERAL: | ||
case NUMERIC_LITERAL: | ||
return true; | ||
case INVOCATION: | ||
BLangInvocation invocation = (BLangInvocation) expr; | ||
if (invocation.name.getValue().equals(CLONE_READ_ONLY)) { |
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.
Thinking about this a little more, currently an invocation is not a compile-time-known value right?
So I think we should differentiate between the .cloneReadOnly
we add, and what the user may have added for a field.
Shall we allow this only when this is the attachment itself, and return false for recursive checks?
Annotation expr is wrapped in cloneReadOnly by internal desugar. We unwrap only this call and prevent other calls being unwrapped.
Closing as will be introduced changes by original PR:#23473 |
Purpose
Fixes #15533
#23473 (comment)
Check List