Yikes. @jckarter, is this intentional?

I don't think we intentionally changed anything here, at least, not in the runtime that I know of. There's a possibility that our code gen broke and introduced a leak.

The problem seems to specifically be with willSet/didSet codegen. Remove the willSet/didSet accessors, and the property appears to zero out correctly.

The problem appears to be a memory leak; the original value never gets deallocated if there are observers on a weak var.

Making the property strong with observers also appears to work around the problem.

Reduced it further. Referencing newValue in a string interpolation during willSet seems to cause the leak:

  weak var value: HeldBase? {
    willSet {
      _ = "\(newValue)"
    }
  }

Making the willSet empty, or referring to newValue outside of an interpolation, doesn't seem to cause a leak. @gribozavr, are you aware of any recent changes to printing that might have introduced leaks? Interestingly print(newValue) seems to be OK.

Found it—printing an Optional leaks in 2.2. @atrick, can you take a look? Here's a reduced test case:

class Wut {
  deinit { print("x") }
}

do {
  _ = "\(Optional(Wut()))"
}
// should print x, but prints nothing

This is either directly due to or exposed by my extending swift_dynamicCast to handle Optional casts. This is the case that leaks:

// .Some
// Single payload enums are guaranteed layout compatible with their
// payload. Only the source's payload needs to be taken or destroyed.
srcType = payloadType;

It's not clear to me how the runtime cast itself could leak, although I'll try to debug that tomorrow. It's possible that by allowing the cast to succeed (as it must by language rules), I've exposed a leak somewhere in the stdlib.

@jckarter No, I'm not.

When casting an optional that itself conforms to an existential, I'm double copying into that existential container, resulting in an extra retain of the Optional payload. At least that's my theory. I'm trying out a fix.

Fix in apple/swift.git 9cf84c2.

Comment by Michael Henson (JIRA)

What's the standard practice for bug report titles that turn out to be inaccurate? Should I update it or leave it as-is?

Good question. I probably should have changed the title before committing and cross referencing the bug. I left it as-is because that was the symptom you observed.