When using `@DebugDescription`, only allow use of [LLDB Summary
Strings](https://lldb.llvm.org/use/variable.html#summary-strings) syntax from
`lldbDescription` properties. When `@DebugDescription` is applied to existing
`debugDescription` properties, escape any `$`, as the output of `debugDescription` is
never interpreted by LLDB.
Depends on #75305
From feedback, replace the name `_debugDescription`, which was confusing because of the
underscore, with `lldbDescription`. This new name also indicates that this property may
contain [LLDB Summary Strings](https://lldb.llvm.org/use/variable.html#summary-strings).
The macro cannot diagnose some situations, or rather, would diagnose too
aggressively, because it cannot inspect the type declarations of all
invokved types, and therefore we're unable to reliably report errors
only when necessary.
Originally I thought we don't want to emit macro code that "may fail to
compile" but we don't really have a choice.
This patch removes a manual diagnostic, and enables more correct code to
properly use @Resolvable protocols.
* `@Observable` Macro supports properties with the `package` access modifier #71060
* Cherry-pick "Move the tests for package scopes to the module interface tests" 4e274ce0a5
---------
Co-authored-by: Philippe Hausler <phausler@apple.com>
On windows (PECOFF), the `static let` properties produced by `DebugDescriptionMacro`
are not constants, and as a result the `@_section` macro cannot be applied. The error
message is:
> global variable must be a compile-time constant to use `@_section` attribute
Until this issue is addressed, DebugDescriptionMacro is disabled for windows targets.
The data emitted by `DebugDescriptionMacro` is constant. For that reason, it was placed
in `__DATA_CONST`. However, this causes a problem with the linker, which emits an error
if the `__DATA_CONST` segment is _not_ marked `SG_READ_ONLY`.
After discussion, it was pointed out that if the constant data has no fixups, then it
can and should be in the the `__TEXT` segment. The `__DATA_CONST` segment is for data
that is essentially constant but contains dyld fixups.
Fixes the way `DebugDescriptionMacro` produces a regex type name.
The problem was use of backslash escapes that weren't sufficiently escaped. They needed
to be double escaped. To avoid this trap, the regexes now use `[.]` to match a dot,
instead of the more conventional `\.` syntax.
Some data types cannot modify their `description` or `debugDescription` properties, as
modification to those properties could result in breakage to their users. To support
these conditions, `DebugDescriptionMacro` should support and prioritize an independent
property (one that that is not being reused).
This change adds support for `_debugDescription`. The macro will now prioritize the
description properties in this order:
1. `_debugDescription`
2. `debugDescription`
3. `debugDescription`
rdar://120498021
Implementation of the DebugDescription macro pitched on the forums:
https://forums.swift.org/t/pitch-debug-description-macro/67711. In this initial commit,
the macro is named `_DebugDescription` to indicate it's internal use at this time,
pending Swift Evolution.
rdar://115180949
Windows uses the runtime component for the DLL, the library component
for the import library, and archive component for static archives. This
is in contrast to Darwin that uses library for the DLL and archive for
static archives.
This is required to enable packaging the ObservableMacros.
Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
"Support Macros in Linux" patches was inconsistent with checking
platforms. Some only checked 'LINUX' but some matches
'LINUX|ANDROID|OPENBSD|FREEBSD'. Although I don't have tested other
platoforms than Linux at all, there's no reason to limit it to Linux.
So use the consistent check to match 'LINUX|ANDROID|OPENBSD|FREEBSD'
For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
* [Observation] Forward availability and defines to extensions
* Simplify availability slightly from review feedback
* Simplify availability for extensions to use `.with`
