Compiling the Mac code with ARC

[Avi Drissman]

If you don't do Mac development in Chromium, you can ignore this email.

ARC is a memory management technology that was added to Objective-C in 2011, several years after the beginning of the Chromium project. Chromium on iOS switched to compiling with ARC a few years ago, but Chromium on Mac did not.

This causes issues:

- The ARC mismatch between the Mac and iOS code means that the iOS code has to maintain ARC boilerplate that would not be needed if all Objective-C code were to be compiled with ARC.

- There's utility functionality that would be subsumed by ARC if only the code were compiled with ARC.

- There's little current documentation on how to write non-ARC code, which affects engineering folks, who can't bring their skills, and which means that the Chrome Mac team must support them in learning Chromium bespoke tools rather than the standard ARC ones.

Therefore, as part of our ongoing commitment to having modern code, we're going to update the Mac Objective-C code to compile with ARC.

This will be an ongoing effort over the next few months. The primary thing to note is that ARC is enabled per target, so if you are writing Objective-C code, and you are within a target that compiles with ARC, you will need to write code that uses ARC.

Documentation on Chromium's relation to ARC is here: Automatic Reference Counting, and this work is being tracked in 1280317.

Thanks for your cooperation; please let me know if you have any questions.

Avi

[Dave Tapuska]

I think this will be good as I've run into issues in the past with having code that has scoped_cftyperef objects into ARC code and have had to come up with work arounds to make it compile.

Are we able to reduce the boilerplate of the ARC compile guard required in implementation files as per the guideline? Could this be defined as a macro itself?

git grep "#error \"This file requires ARC support.\"" | wc -l

    3740

The macro is:

#if !defined(__has_feature) || !__has_feature(objc_arc)
#error "This file requires ARC support."
#endif

This could actually be:

#if HAS_FEATURE(obj_arc)

#error "This file requires ARC support"

#endif

but I wonder if we could do something like:

REQUIRES_FEATURE(obj_arc) ?

dave.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACWgwAbT-B%2B7HO%2BSWftnjfeFLsrcYDnqOH5OOhvutyj_fcsAHA%40mail.gmail.com.

[Avi Drissman]

Note that ARC only handles CF types in Swift; in Objective-C/Objective-C++ those still need manual handling.

As for the boilerplate, I'm following the path that the iOS ARC folks went down, so I would want to want to know what their thoughts are there. I can't find a written rationale in any of their documents.

Avi

[Jeremy Roman]

On Wed, Apr 19, 2023 at 3:15 PM 'Avi Drissman' via Chromium-dev <chromi...@chromium.org> wrote:

Note that ARC only handles CF types in Swift; in Objective-C/Objective-C++ those still need manual handling.

As for the boilerplate, I'm following the path that the iOS ARC folks went down, so I would want to want to know what their thoughts are there. I can't find a written rationale in any of their documents.

Avi

On Wed, Apr 19, 2023 at 3:01 PM Dave Tapuska <dtap...@chromium.org> wrote:

I think this will be good as I've run into issues in the past with having code that has scoped_cftyperef objects into ARC code and have had to come up with work arounds to make it compile.

Are we able to reduce the boilerplate of the ARC compile guard required in implementation files as per the guideline? Could this be defined as a macro itself?

git grep "#error \"This file requires ARC support.\"" | wc -l

    3740

The macro is:

#if !defined(__has_feature) || !__has_feature(objc_arc)
#error "This file requires ARC support."
#endif

This could actually be:

#if HAS_FEATURE(obj_arc)

#error "This file requires ARC support"

#endif

but I wonder if we could do something like:

REQUIRES_FEATURE(obj_arc) ?

I don't think a preprocessor macro can internally invoke #error, but you could always define a macro like this:

inline constexpr bool HasARC() {

#if !defined(__has_feature) || !__has_feature(objc_arc)

  return false;

#else

  return true;

#endif

}

static_assert(HasARC(), "This file requires ARC support.");

 

or define a separate #include which has the three lines to yield an error, like:

#include "...../requires_arc.h"

Not sure either of these is dramatically simpler, though.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACWgwAajxbO45iMOaa4kt87qQ2qqE5cH5AxY3L5k4JdsK5krfA%40mail.gmail.com.

[Dave Tapuska]

I think something like might work:

#define REQUIRES_ARC() static_assert(HAS_FEATURE(objc_arc), "This file requires ARC support.")

REQUIRES_ARC();

But again I don't know if there is appetite for this.

dave.

[Rohit Rao]

When we started looking at ARC in ~2014, we adopted the boilerplate and guidance that google3 was proposing. It's there to prevent compiling in the wrong mode.

Non-ARC code generally won't compile with ARC, because you'll almost always have a call to retain, release, or autorelease, and the compiler will complain loudly.

It's trickier the other way around. ARC code will usually compile without ARC, and then will quietly leak everything at runtime. We try to turn this into a loud error via the boilerplate. It's not perfect, but it helps.

The motivation for the boilerplate disappears once Chromium can compile with ARC by default, and in fact google3 removed these guards a while ago. Until then, and especially while files are in transition, I think the boilerplate is useful.

I don't have an opinion on reducing the size of the boilerplate. It's added automatically by tools/boilerplate.py, so I don't spend a lot of time worrying about it.

- Rohit

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHgVhZVSMu64RiAgG2uKpWc%2BT0i0gFNfQA7n37UgntqUf_tceA%40mail.gmail.com.

[Sylvain Defresne]

The boilerplate is also automatically inserted by src/tools/boilerplate.py if the file created is a .mm file located in src/ios or below. We can update the script to automatically add the boilerplate to all .mm files regardless of where they are created. We also have a presubmit in src/ios checking that all .mm files have the boilerplate.

Since the script already takes care of the other boilerplate (license, header guards, ...) I would assume it is used by most developers, thus I don't really see a need to shorten the boilerplate. Like the license, it is something that you can just glaze over.

I don't think it is worth defining a macro to simplify this (after all the style guide discourages macros) and I'm not sure the static_assert() is easier to read.

-- Sylvain

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAFqFDwAiRBA2ph2oCpfxYNjn1oKy7a31or0_haRPC%3DmN%3D%2BFN4w%40mail.gmail.com.

[Dave Tapuska]

TIL: We have a boilerplate.py. Is this documented in the general/mac chromium workflow somewhere? (I only see it in https://source.chromium.org/chromium/chromium/src/+/main:docs/ios/xcode_tips.md?q=boilerplate.py&ss=chromium)

Since this is the desired workflow for creating files I guess reducing the boilerplate itself isn't worth it since it is generated.

dave.

[Sylvain Defresne]

I don't think it is documented, but it has existed for almost as long as I've been working on Chromium (was added in 2014).

-- Sylvain