[DebugInfo] Stop handling InOut types, they'll be gone soon.

[dcci]

rdar://problem/46043909

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

[dcci]

@swift-ci please test

[dcci]

@adrian-prantl @slavapestov I would be grateful if you can take a look.

[dcci]

Also, FWIW, I checked the lldb test suite locally to make sure this doesn't introduce new regressions.

[jrose-apple]

This worries me. Are you representing the address-ness some other way now?

[dcci]

I think this code was unused.

[dcci]

But I didn't write this, so I guess @adrian-prantl is in a better position to judge.

[adrian-prantl]

We need to check whether LLDB attaches any semantics to InOut or if it is pure sugar. If it's the latter then this is safe.

[adrian-prantl]

Do we have any tests in LLDB that exercise inout types?

[jrose-apple]

I'd put a regular Int field in the struct too, then, and make sure you can print that. That's easier than checking the weak reference, though of course that should also be correct.

[dcci]

@jrose-apple this is what I'm seeing.

(lldb) target create "./run"
b -l Current executable set to './run' (x86_64).
(lldb) b -l 8
Breakpoint 1: where = run`run.test(run.X) -> () + 50 at run.swift:8:9, address = 0x0000000100001742
(lldb) r
Process 16896 launched: '/Users/davide/build/Ninja-ReleaseAssert+stdlib-Release/swift-macosx-x86_64/bin/run' (x86_64)
Process 16896 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100001742 run`test(x=run.X @ 0x00007ffeefbff9b0) at run.swift:8:9
   5   	
   6   	func test(_ x: X) {
   7   	  var y = x
-> 8   	  print(y)
   9   	}
   10  	
   11  	test(X(foo: 23 as AnyObject, patatino: 23))
Target 0: (run) stopped.
(lldb) frame var y
(run.X) y = {
  foo = nil
  patatino = 23
}

struct X {
  weak var foo: AnyObject?
  var patatino : Int
}

func test(_ x: X) {
  var y = x
  print(y)
}

test(X(foo: 23 as AnyObject, patatino: 23))

[jrose-apple]

That looks like correct behavior, although it would be a better test if you had a class instance that was kept alive until after you were done calling test. If that works with and without your change, then I think it's all good.

[dcci]

@jrose-apple Looks like that case is broken with and without my change

(lldb) frame var y
(run.X) y = {
  foo = (instance = 0x0000000100a00002) {
    instance = 0x0000000100a00002
  }
  patatino = 23
}

class Tinky {
  var x : Int
  init(_ x : Int) {
    self.x = x
  }
}

struct X {
  weak var foo: AnyObject?
  var patatino : Int
}

func test(_ x: X) {
  var y = x
  print(y)
}

var a = Tinky(23)
test(X(foo: a, patatino: 23))
print(a)

[dcci]

@jrose-apple given it seems unrelated, I'll open a rdar for this and look at it next.

[adrian-prantl]

Will the user-facing inout type disappear, too? Or do we still need to mangle inout types so we can preserve the sugar in LLDB (i.e.: should p result show (inout Int)result ?)

[dcci]

@adrian-prantl I had a quick discussion with @slavapestov yesterday and he suggested we shouldn't print anything at all.

[dcci]

In fact, it's been pointed out that InOut types are not real types but InOut is more a property of function parameters so if we want to model we should model it as such.

[adrian-prantl]

I suppose it is not particularly useful information.

[slavapestov]

Thank you @dcci!

@adrian-prantl To be clear we're not changing language semantics and certainly not removing inout parameters -- just making InOutType an implementation detail of Sema and eventually removing it altogether since it doesn't model what it should be modeling very well.

[adrian-prantl]

Thanks for the explanation. It really doesn't seem to add any valuable information to the user, so even removing the entire inout sugar in the debugger wouldn't hurt.

[dcci]

I'll let this one bake for a bit, then I'll remove the support from TypeReconstruction and the debugger.

[slavapestov]

Don't bother removing anything from TypeReconstruction, I'm replacing that with the new TypeDecoder entry point soon (see #20252)