profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/rjmccall/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
John McCall rjmccall @apple 2008–present @apple: impl. clang++, des. & impl. ObjC, ARC, Swift; ed. @itanium-cxx-abi / 2006–08 MS cs.pdx.edu / 2003–06 gdviz.com / 2000–03 BS math.cmu.edu

itanium-cxx-abi/cxx-abi 322

C++ ABI Summary

DougGregor/swift-evolution 35

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

rjmccall/swift-evolution 3

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

rjmccall/glamr 2

Glulx LLVM frontend

rjmccall/clang 1

Stash space for WIP on clang

rjmccall/cxx-abi 1

C++ ABI Summary

rjmccall/rjmccall.github.io 1

Build a Jekyll blog in minutes, without touching the command line.

rjmccall/swift 1

The Swift Programming Language

push eventitanium-cxx-abi/cxx-abi

Richard Smith

commit sha 896c1665740fcd7b721e933efe3bdc4aa1417922

Add a note that constexpr functions are never key functions.

view details

John McCall

commit sha d9dc0c0198f32517ea60226462fa83873cf11c99

Merge pull request #105 from zygoloid/constexpr-key-function Add a note that constexpr functions are never key functions.

view details

push time in 11 days

PR merged itanium-cxx-abi/cxx-abi

Add a note that constexpr functions are never key functions.

This is a consequence of the existing wording, and makes sense for the same reason we don't want inline functions to be key functions in general, but is not universal implementation practice: GCC does not allow constexpr virtual functions to be key functions, but Clang 10 does.

+2 -0

0 comment

1 changed file

zygoloid

pr closed time in 11 days

PR closed itanium-cxx-abi/cxx-abi

Add compression mangling for versioning namespaces in std

This is a strawman proposal to add substitutions for inline namespaces (fixing #42). I've never touched the Itanium ABI before so this is most likely wrong and/or too naive, but this is at least something concrete to get us started with.

A couple of notes on my approach:

  • We don't compress std::__1, because that's already in use.
  • I delimit with v on both sides to avoid clashing with things like St3. There may be a better way of doing this.

@zygoloid In #42, you say:

I don't have a concrete suggestion yet; whatever we pick, we'll presumably want the std::<inline namespace> part to itself be substitutable, which makes this a bit awkward to fit into the existing scheme.

Can you explain what you mean by that? I suspect this will throw my approach down the drain (but that's fine).

Fixes #42

+20 -0

20 comments

1 changed file

ldionne

pr closed time in 11 days

delete branch itanium-cxx-abi/cxx-abi

delete branch : master

delete time in 11 days

create barnchitanium-cxx-abi/cxx-abi

branch : main

created branch time in 11 days

pull request commentitanium-cxx-abi/cxx-abi

Rename <data-member-prefix> to cover non-data member cases.

This has been open for discussion quite long enough.

zygoloid

comment created time in 11 days

push eventitanium-cxx-abi/cxx-abi

Richard Smith

commit sha cd4f3ebc3a9fce023bf9e70bdabc31535ba28023

Rename <data-member-prefix> to cover non-data member cases. Extend grammar to cover additional contexts where this can be used. Fixes #94.

view details

Richard Smith

commit sha 17dbcaab3058942564d3c3a92882fd7e86dae2c9

Make the template-name in a closure-prefix substitutable.

view details

John McCall

commit sha 79d8186fdd2d91259249e71ef2e352383eaa5304

Merge pull request #126 from zygoloid/data-member-prefix Rename <data-member-prefix> to cover non-data member cases.

view details

push time in 11 days

PR merged itanium-cxx-abi/cxx-abi

Rename <data-member-prefix> to cover non-data member cases.

Extend grammar to cover additional contexts where this can be used.

Fixes #94.

+6 -7

0 comment

1 changed file

zygoloid

pr closed time in 11 days

issue closeditanium-cxx-abi/cxx-abi

mangling of lambdas for inline variables

Given the resolution of DR2300 inline variables intialized to lambda need to uniquely identify the lambda across translation units.

The document does describe this (#closure-types), but I find the wording confusing as it focusses on static data members. I hit an issue with namespace-scope variables: inline auto bob = []{};

The grammar has: <data-member-prefix> ::= <member source-name> [<template-args>] M '<member source-name>' appears nowhere else in the document. I think just '<source-name>' would suffice.

It would also be less confusing if '>data-member-prefix<' changed to '<data-prefix>', it's used in on place in the <prefix> reduction.

closed time in 11 days

urnathan

pull request commentitanium-cxx-abi/cxx-abi

Add a mangling for the _BitInt datatype from C23.

Thanks for the reminder.

AaronBallman

comment created time in 11 days

push eventitanium-cxx-abi/cxx-abi

Aaron Ballman

commit sha 2f4326a1f8a1a1430591586195e4dbba8d2497b9

Add a mangling for the _BitInt datatype from C23.

view details

Aaron Ballman

commit sha d3a135b3a87681cf62b36c341b0169d177c0b005

Use `|` rather than separate grammar productions. Also adds a mention of C23 to the comments.

view details

Aaron Ballman

commit sha 005ca7dd5e6cfdaa2dbc662d014e2df79b8ff04c

Go back to using separate grammar productions. This changes template-args to expression in the grammar as well, which was the original suggestion that I misunderstood.

view details

Aaron Ballman

commit sha 633aaba2712099305e4b55b18e8063f695941f11

Add 'instantiation-dependent' wording.

view details

John McCall

commit sha 967667b3d7b256ad50a94e1e5d0d3c7661a8ea1b

Merge pull request #129 from AaronBallman/bitint Add a mangling for the _BitInt datatype from C23.

view details

push time in 11 days

PR merged itanium-cxx-abi/cxx-abi

Add a mangling for the _BitInt datatype from C23.

C23 adds a new builtin datatype named _BitInt for a family of bit-precise integer types that can be either signed or unsigned. This adds a proper mangling for the datatype for implementations that provide this feature as an extension in C++ and for implementations that support overloading within C as an extension. This implements #128.

+4 -0

2 comments

1 changed file

AaronBallman

pr closed time in 11 days

pull request commentapple/swift-evolution

[SE 0317] `@AsyncLet` fixes.

Yeah, the purpose of this section is not to provide best-practices code that can be copy-and-pasted into someone's program. Bad syntax like the mess with @autoclosure should be fixed, but adding final just distracts from the argument. If you remove that, I'll go ahead and merge.

filip-sakel

comment created time in 11 days

pull request commentapple/swift-evolution

[SE 0317] `@AsyncLet` fixes.

Hi, Filip. This seems obviously good, except is there a reason you made the class final?

filip-sakel

comment created time in 12 days

PR closed apple/swift-evolution

Add proposal for `weak(guard)` closure capture specifier

This PR adds a proposal for a new weak(guard) closure capture specifier.

Swift Evolution discussion thread: guard capture specifier for closure capture lists

Implementation: apple/swift#38718

+203 -0

1 comment

1 changed file

calda

pr closed time in 12 days

pull request commentapple/swift-evolution

Add proposal for `weak(guard)` closure capture specifier

Per my comment in the pitch thread, the core team has elected to close this PR out for now. Thank you for the suggestion, it was certainly worth considering.

calda

comment created time in 12 days

pull request commentapple/swift-evolution

[Proposal] Make @warn_unqualified_access applicable to all accessible…

Sorry about the long delay. I left a comment on the pitch thread.

Saklad5

comment created time in 18 days

push eventapple/swift

John McCall

commit sha 1711df4ce4d15f6f4ac5792cfabc428dc8070dfc

Fix the condition for warning about implicit capture of self captures. We've always emitted an error if we saw an implicit use of a self parameter of class type from an escaping closure. In PR #35898, I fixed this to also emit an error if the reference was to an explicit capture of self that wasn't made in the current closure. That was causing some source incompatibilities that we decided were too severe, so in PR #38947 I weakened that to a warning when the diagnostic walk was within multiple levels of closures, because I have always thought of this as a fix to nested closures. However, this was the wrong condition in two ways. First, the diagnostic walk does not always start from the outermost function declaration; it can also start from a multi-statement closure. In that case, we'll still end up emitting an error when we see uses of explicit captures from the closure when we walk it, and so we still have a source incompatibility. That is rdar://82545600. Second, the old diagnostic did actually fire correctly in nested closures as long as the code was directly referring to the original self parameter and not any intervening captures. Therefore, #38947 actually turned some things into warnings that had always been errors. The fix is to produce a warning exactly when the referenced declaration was an explicit capture.

view details

John McCall

commit sha a00ed9f2dd22394257d853c878cfe3e293293bab

Merge pull request #39118 from rjmccall/implicit-self-capture-capture-warning Fix the condition for warning about implicit capture of self captures.

view details

push time in 24 days

delete branch rjmccall/swift

delete branch : implicit-self-capture-capture-warning

delete time in 24 days

PR merged apple/swift

Fix the condition for warning about implicit capture of self captures.

We've always emitted an error if we saw an implicit use of a self parameter of class type from an escaping closure. In #35898, I fixed this to also emit an error if the reference was to an explicit capture of self that wasn't made in the current closure. That was causing some source incompatibilities that we decided were too severe, so in PR #38947 I weakened that to a warning when the diagnostic walk was within multiple levels of closures, because I have always thought of this as a fix to nested closures. However, this was the wrong condition in two ways.

First, the diagnostic walk does not always start from the outermost function declaration; it can also start from a multi-statement closure. In that case, we'll still end up emitting an error when we see uses of explicit captures from the closure when we walk it, and so we still have a source incompatibility. That is rdar://82545600.

Second, the old diagnostic did actually fire correctly in nested closures as long as the code was directly referring to the original self parameter and not any intervening captures. Therefore, #38947 actually turned some things into warnings that had always been errors.

The fix is to produce a warning exactly when the referenced declaration was an explicit capture.

+32 -8

2 comments

3 changed files

rjmccall

pr closed time in 24 days

pull request commentapple/swift

Fix the condition for warning about implicit capture of self captures.

@swift-ci Please test macOS

rjmccall

comment created time in 24 days

pull request commentapple/swift

Fix the condition for warning about implicit capture of self captures.

@swift-ci Please test and merge

rjmccall

comment created time in 25 days

PR opened apple/swift

Fix the condition for warning about implicit capture of self captures.

We've always emitted an error if we saw an implicit use of a self parameter of class type from an escaping closure. In #35898, I fixed this to also emit an error if the reference was to an explicit capture of self that wasn't made in the current closure. That was causing some source incompatibilities that we decided were too severe, so in PR #38947 I weakened that to a warning when the diagnostic walk was within multiple levels of closures, because I have always thought of this as a fix to nested closures. However, this was the wrong condition in two ways.

First, the diagnostic walk does not always start from the outermost function declaration; it can also start from a multi-statement closure. In that case, we'll still end up emitting an error when we see uses of explicit captures from the closure when we walk it, and so we still have a source incompatibility. That is rdar://82545600.

Second, the old diagnostic did actually fire correctly in nested closures as long as the code was directly referring to the original self parameter and not any intervening captures. Therefore, #38947 actually turned some things into warnings that had always been errors.

The fix is to produce a warning exactly when the referenced declaration was an explicit capture.

+32 -8

0 comment

3 changed files

pr created time in 25 days

push eventrjmccall/swift

John McCall

commit sha 1711df4ce4d15f6f4ac5792cfabc428dc8070dfc

Fix the condition for warning about implicit capture of self captures. We've always emitted an error if we saw an implicit use of a self parameter of class type from an escaping closure. In PR #35898, I fixed this to also emit an error if the reference was to an explicit capture of self that wasn't made in the current closure. That was causing some source incompatibilities that we decided were too severe, so in PR #38947 I weakened that to a warning when the diagnostic walk was within multiple levels of closures, because I have always thought of this as a fix to nested closures. However, this was the wrong condition in two ways. First, the diagnostic walk does not always start from the outermost function declaration; it can also start from a multi-statement closure. In that case, we'll still end up emitting an error when we see uses of explicit captures from the closure when we walk it, and so we still have a source incompatibility. That is rdar://82545600. Second, the old diagnostic did actually fire correctly in nested closures as long as the code was directly referring to the original self parameter and not any intervening captures. Therefore, #38947 actually turned some things into warnings that had always been errors. The fix is to produce a warning exactly when the referenced declaration was an explicit capture.

view details

push time in 25 days

push eventrjmccall/swift

John McCall

commit sha 89b9f6412f02ad692f292fb197c88cbcda8589b3

Fix the condition for warning about implicit capture of self captures. We've always emitted an error if we saw an implicit use of a self parameter of class type from an escaping closure. In #35898, I fixed this to also emit an error if the reference was to an explicit capture of self that wasn't made in the current closure. That was causing some source incompatibilities that we decided were too severe, so in within multiple levels of closures, because I have always thought of this as a fix to nested closures. However, this was the wrong condition in two ways. First, the diagnostic walk does not always start from the outermost function declaration; it can also start from a multi-statement closure. In that case, we'll still end up emitting an error when we see uses of explicit captures from the closure when we walk it, and so we still have a source incompatibility. That is rdar://82545600. Second, the old diagnostic did actually fire correctly in nested closures as long as the code was directly referring to the original self parameter and not any intervening captures. Therefore, #38947 actually turned some things into warnings that had always been errors. The fix is to produce a warning exactly when the referenced declaration was an explicit capture.

view details

push time in 25 days

create barnchrjmccall/swift

branch : implicit-self-capture-capture-warning

created branch time in 25 days

push eventrjmccall/swift

John McCall

commit sha 8d288b3cfbde9a78310f48deb52bd428bd1ab7f7

Fix the condition for warning about implicit capture of self captures. We've always emitted an error if we saw an implicit use of a self parameter of class type from an escaping closure. In #35898, I fixed this to also emit an error if the reference was to an explicit capture of self that wasn't made in the current closure. That was causing some source incompatibilities that we decided were too severe, so in within multiple levels of closures, because I have always thought of this as a fix to nested closures. However, this was the wrong condition in two ways. First, the diagnostic walk does not always start from the outermost function declaration; it can also start from a multi-statement closure. In that case, we'll still end up emitting an error when we see uses of explicit captures from the closure when we walk it, and so we still have a source incompatibility. That is rdar://82545600. Second, the old diagnostic did actually fire correctly in nested closures as long as the code was directly referring to the original self parameter and not any intervening captures. Therefore, #38947 actually turned some things into warnings that had always been errors. The fix is to produce a warning exactly when the referenced declaration was an explicit capture.

view details

push time in 25 days

pull request commentapple/swift

[Concurrency] repair cooperative global executor

I have no problem landing this without testing in the short term, but yeah, I think it should be a goal to bring up CI to test the WebAssembly target ASAP.

kateinoigakukun

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent