Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Add strong qualifier to backgroundColor. #37761

Closed
wants to merge 1 commit into from
Closed

Add strong qualifier to backgroundColor. #37761

wants to merge 1 commit into from

Conversation

chingjun
Copy link
Contributor

This is causing issue when -Wobjc-property-no-attribute is turned on.

Since LLVM 3.1, strong has been the default value so this change is effectively a no-op, but improves readability.

Similar to #36929, this is needed internally.

Also, can we consider enabling -Wobjc-property-no-attribute in the engine tree? I can do that if someone points me to where this is specified. Thanks

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@chingjun
Add strong qualifier to backgroundColor.
81664b4 
This is causing issue when -Wobjc-property-no-attribute is turned on.

Since LLVM 3.1, strong has been the default value so this change is effectively a no-op, but improves readability.

Similar to flutter#36929
@chingjun chingjun requested a review from jmagman November 18, 2022 22:19
@jmagman
Copy link
Member

jmagman commented Nov 18, 2022

Re #36929 generally properties with mutable variants, like NSMutableArray, should be copy not `strong.

Also, can we consider enabling -Wobjc-property-no-attribute in the engine tree? I can do that if someone points me to where this is specified. Thanks

@cbracken is this the right spot?

engine/common/config.gni

Line 68 in 965f87d

flutter_cflags_objc_arc = flutter_cflags_objc + [ "-fobjc-arc" ] 

flutter_cflags_objc_arc = flutter_cflags_objc + [
  "-fobjc-arc",
  "-Wobjc-property-no-attribute",
]

@cbracken cbracken requested a review from a-wallen November 19, 2022 00:24
cbracken
cbracken reviewed Nov 19, 2022
View reviewed changes
shell/platform/darwin/macos/framework/Headers/FlutterViewController.h
@@ -115,6 +115,6 @@ FLUTTER_DARWIN_EXPORT
* }
* ```
*/
@property(readwrite, nonatomic, nullable) NSColor* backgroundColor;
@property(readwrite, nonatomic, nullable, strong) NSColor* backgroundColor;
Copy link
Member

@cbracken cbracken Nov 19, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use copy here rather than strong.

Suggested change
@property(readwrite, nonatomic, nullable, strong) NSColor* backgroundColor;
@property(readwrite, nonatomic, nullable, copy) NSColor* backgroundColor;

NSColor is immutable but there's no guarantee someone hasn't subclassed it. IIRC NSColor is actually a tagged pointer these days so yeah, this is probably inconsequential, but really copy is the right semantics to express.

@cbracken
Copy link
Member

cbracken commented Nov 19, 2022 •
edited
Loading

@cbracken is this the right spot?

@jmagman that is indeed the right spot (just above with the other warnings in flutter_cflags_objc). Go for it!

Actually let me check -- normally we do warnings in buildroot. But can't remember if we have separate objc bits in there. One sec and I'll check.

Checked; thinking about it we only want to apply to flutter not any third_party/ bits etc. Yes chuck it in there. There are a couple "-Werror=..." lines right above you can toss it in with.

@cbracken
Copy link
Member

cbracken commented Nov 19, 2022 •
edited
Loading

This is causing issue when -Wobjc-property-no-attribute is turned on.

Did some playing around with this and this diagnostic is enabled by default in clang. We don't disable it in our build, and therefore it should already be enabled. You can see that it was enabled internally in cl/257817073 by removing the "-Wno-error=objc-property-no-attribute" option rather than by adding anything.

I experimented with turning it on (and making it an error) but it had no effect. A bit of digging suggests that warning is disabled when ARC is enabled (the macOS embedder uses ARC):

engine/shell/platform/darwin/macos/BUILD.gn

Line 136 in f81ac3b

cflags_objcc = flutter_cflags_objcc_arc

I'm assuming we're compiling with ARC enabled internally? I'd imagine we must be since otherwise __weak annotations should upset the compiler.

@cbracken
Copy link
Member

cbracken commented Nov 19, 2022 •
edited
Loading

I've sent out #37768 which adds explicit annotations to all the cases of NSObject properties that weren't already explicitly annotated in the macOS embedder and that fixes the annotation introduced in #36929.

I'm happy to enable the warning explicitly in that patch, but as I say, it should be enabled by default. We don't disable it externally, but enabling ARC via -fobjc-arc (which we do) does appear to disable it when I tested, and I'm not sure how to force it back on. I see a few mentions of this elsewhere on the web.

@chingjun
Copy link
Contributor Author

Thanks for taking on this Chris! I'll close this PR in favor of #37768

Regarding the flag, internally the warning behaves weird too, it only appeared when I was working on b/254864882. Once b/254864882 is completed, it would be great if we can catch the same warning here as well.

@chingjun chingjun closed this Nov 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@cbracken cbracken cbracken left review comments

@jmagman jmagman Awaiting requested review from jmagman

@a-wallen a-wallen Awaiting requested review from a-wallen

Assignees
No one assigned
Labels
platform-macos
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@chingjun @jmagman @cbracken