12 Commits

Author SHA1 Message Date
Aaron Ballman
0f1c1be196 [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
2023-08-28 12:13:42 -04:00
Mehdi Amini
e0ac46e69d 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
2023-07-17 18:08:04 -07:00
Aaron Ballman
d618f1c3b1 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
2023-07-07 08:41:11 -04:00
Reid Kleckner
ab9b179f4f Give some obj-c rewriter tests that use MS pragmas a triple as a speculative fix
llvm-svn: 231320
2015-03-05 00:04:18 +00:00
David Blaikie
218b783192 Update Clang tests to handle explicitly typed gep changes in LLVM.
llvm-svn: 230783
2015-02-27 19:18:17 +00:00
John McCall
5fb5df9c83 Restructure how the driver communicates information about the
target Objective-C runtime down to the frontend:  break this
down into a single target runtime kind and version, and compute
all the relevant information from that.  This makes it
relatively painless to add support for new runtimes to the
compiler.  Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime.  This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.

As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.

I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.

llvm-svn: 158793
2012-06-20 06:18:46 +00:00
Fariborz Jahanian
2e7f638b23 modern objc translator: used size_t in couple
of places. // rdar://11375908

llvm-svn: 156106
2012-05-03 21:44:12 +00:00
Fariborz Jahanian
cc1722818b modern objective-c translator: translation of implicit
cast to/from block pointer types. // rdar://11202764
Also, many more modern translator tests.

llvm-svn: 154869
2012-04-16 22:14:01 +00:00
Fariborz Jahanian
42d05f2faf Also, these objc++ rewriter tests are meant to run in NeXt's
fragile-abi mode.

llvm-svn: 149788
2012-02-04 19:06:06 +00:00
Fariborz Jahanian
83e7d5a90a Fix rewriter to match recent changes in property ref
AST.

llvm-svn: 120919
2010-12-04 21:22:13 +00:00
John McCall
34376a68c4 Although we currently have explicit lvalue-to-rvalue conversions, they're
not actually frequently used, because ImpCastExprToType only creates a node
if the types differ.  So explicitly create an ICE in the lvalue-to-rvalue
conversion code in DefaultFunctionArrayLvalueConversion() as well as several
other new places, and consistently deal with the consequences throughout the
compiler.

In addition, introduce a new cast kind for loading an ObjCProperty l-value,
and make sure we emit those nodes whenever an ObjCProperty l-value appears
that's not on the LHS of an assignment operator.

This breaks a couple of rewriter tests, which I've x-failed until future
development occurs on the rewriter.

Ted Kremenek kindly contributed the analyzer workarounds in this patch.

llvm-svn: 120890
2010-12-04 03:47:34 +00:00
Fariborz Jahanian
086a24a2be Fixes a rewrite bug, rewriting nested property usage
inside blocks. Fixes //rdar: //8608293.

llvm-svn: 118425
2010-11-08 18:37:50 +00:00