File: ReadMe.md

package info (click to toggle)
swiftlang 6.0.3-2
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid, trixie
  • size: 2,519,992 kB
  • sloc: cpp: 9,107,863; ansic: 2,040,022; asm: 1,135,751; python: 296,500; objc: 82,456; f90: 60,502; lisp: 34,951; pascal: 19,946; sh: 18,133; perl: 7,482; ml: 4,937; javascript: 4,117; makefile: 3,840; awk: 3,535; xml: 914; fortran: 619; cs: 573; ruby: 573
file content (11 lines) | stat: -rw-r--r-- 1,397 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
These tests concern the experimental Swift feature `@_implementationOnly import`.\* Unlike a normal import, an `@_implementationOnly` import is guaranteed not to be part of a library's API or ABI, which means that client apps don't have to know about the import at all to use the library. However, the import *can* be used in the *implementation* of the library, so it's important for LLDB to handle the cases where the `@_implementationOnly` import is and isn't available when debugging.

In a scenario with a client app, a library, and an implementation-only import that the library uses, there are three situations we care about:

1. The library has no debug info, or just line tables. In this case, the implementation-only import is irrelevant; someone debugging the app can only use the public parts of the library.

2. The library has debug info and the implementation-only import is available. In this case, the debugger should make everything available like it would with a normal import.

3. The library has debug info, but the implementation-only import is not available (for whatever reason). In this case LLDB may still have to deal with internal parts of the library even though some types will not be available. (This is the least important case, but it'd be good to not crash or lie to users.)

\* Hopefully someone will remember to edit this ReadMe before the feature goes public!