History log of /llvm-project/clang/test/CodeGenObjC/objc-alloc-init.m (Results 1 – 11 of 11)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4
# 0f1c1be1 28-Aug-2023 Aaron Ballman <aaron@aaronballman.com>

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.

This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.

Differential Review: https://reviews.llvm.org/D158071

show more ...


Revision tags: llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init
# e0ac46e6 17-Jul-2023 Mehdi Amini <joker.eph@gmail.com>

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it land

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

Differential Revision: https://reviews.llvm.org/D155509

show more ...


# d618f1c3 07-Jul-2023 Aaron Ballman <aaron@aaronballman.com>

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-rev

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847

show more ...


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7
# 9466b491 12-Dec-2022 Nikita Popov <npopov@redhat.com>

[Clang] Convert various tests to opaque pointers (NFC)

These were all tests where no manual fixup was required.


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 532dc62b 07-Apr-2022 Nikita Popov <npopov@redhat.com>

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be p

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

Differential Revision: https://reviews.llvm.org/D123115

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# 46b0d0ee 16-Feb-2022 Aaron Ballman <aaron@aaronballman.com>

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a protot

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

void func();

becomes

void func(void);

This is the twelfth batch of tests being updated (the end may be in
sight soon though).

show more ...


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init
# d18fbfc0 15-Jan-2020 Pierre Habouzit <phabouzit@apple.com>

Relax the rules around objc_alloc and objc_alloc_init optimizations.

Today the optimization is limited to:
- `[ClassName alloc]`
- `[self alloc]` when within a class method

However it means that wh

Relax the rules around objc_alloc and objc_alloc_init optimizations.

Today the optimization is limited to:
- `[ClassName alloc]`
- `[self alloc]` when within a class method

However it means that when code is written this way:

```
@interface MyObject
- (id)copyWithZone:(NSZone *)zone
{
return [[self.class alloc] _initWith...];
}

@end
```

... then the optimization doesn't kick in and `+[NSObject alloc]` ends
up in IMP caches where it could have been avoided. It turns out that
`+alloc` -> `+[NSObject alloc]` is the most cached SEL/IMP pair in the
entire platform which is rather silly).

There's two theoretical risks allowing this optimization:

1. if the receiver is nil (which it can't be today), but it turns out
that `objc_alloc()`/`objc_alloc_init()` cope with a nil receiver,

2. if the `Clas` type for the receiver is a lie. However, for such a
code to work today (and not fail witn an unrecognized selector
anyway) you'd have to have implemented the `-alloc` **instance
method**.

Fortunately, `objc_alloc()` doesn't assume that the receiver is a
Class, it basically starts with a test that is similar to

`if (receiver->isa->bits & hasDefaultAWZ) { /* fastpath */ }`.

This bit is only set on metaclasses by the runtime, so if an instance
is passed to this function by accident, its isa will fail this test,
and `objc_alloc()` will gracefully fallback to `objc_msgSend()`.

The one thing `objc_alloc()` doesn't support is tagged pointer
instances. None of the tagged pointer classes implement an instance
method called `'alloc'` (actually there's a single class in the
entire Apple codebase that has such a method).

Differential Revision: https://reviews.llvm.org/D71682
Radar-Id: rdar://problem/58058316
Reviewed-By: Akira Hatanaka
Signed-off-by: Pierre Habouzit <phabouzit@apple.com>

show more ...


Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2
# 48566aaa 04-Jun-2019 Akira Hatanaka <ahatanaka@apple.com>

[CodeGen][ObjC] Convert '[self alloc]' in a class method to a call to
'objc_alloc(self)'

Also convert '[[self alloc] init]' in a class method to a call to
'objc_alloc_init(self)'.

rdar://problem/50

[CodeGen][ObjC] Convert '[self alloc]' in a class method to a call to
'objc_alloc(self)'

Also convert '[[self alloc] init]' in a class method to a call to
'objc_alloc_init(self)'.

rdar://problem/50855121

Differential Revision: https://reviews.llvm.org/D62643

llvm-svn: 362521

show more ...


Revision tags: llvmorg-8.0.1-rc1
# f6c645f9 15-May-2019 Erik Pilkington <erik.pilkington@gmail.com>

[CodeGenObjC] invoke objc_autorelease, objc_retain when necessary

Any of these methods can be overridden, so we need to invoke these functions.

Differential revision: https://reviews.llvm.org/D6195

[CodeGenObjC] invoke objc_autorelease, objc_retain when necessary

Any of these methods can be overridden, so we need to invoke these functions.

Differential revision: https://reviews.llvm.org/D61957

llvm-svn: 360802

show more ...


Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3
# 55e703a5 25-Feb-2019 Erik Pilkington <erik.pilkington@gmail.com>

[CodeGenObjC] Fix a nullptr dyn_cast

ObjCMessageExpr::getInstanceReceiver returns nullptr if the receiver
is 'super'. Make this check more strict, since we don't care about
messages to super here.

[CodeGenObjC] Fix a nullptr dyn_cast

ObjCMessageExpr::getInstanceReceiver returns nullptr if the receiver
is 'super'. Make this check more strict, since we don't care about
messages to super here.

rdar://48247290

llvm-svn: 354826

show more ...


# ec389b08 14-Feb-2019 Erik Pilkington <erik.pilkington@gmail.com>

[CodeGenObjC] Emit [[X alloc] init] as objc_alloc_init(X) when available

This provides a code size win on the caller side, since the init
message send is done in the runtime function.

rdar://449870

[CodeGenObjC] Emit [[X alloc] init] as objc_alloc_init(X) when available

This provides a code size win on the caller side, since the init
message send is done in the runtime function.

rdar://44987038

Differential revision: https://reviews.llvm.org/D57936

llvm-svn: 354056

show more ...