The `DebugDescription` macro has been accepted. Additionally, the `DebugDescriptionMacro` feature was not providing conditional declaration as I originally intended. References to the feature are not needed and can be removed.
(cherry-picked from #77738)
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
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).
Use the correct source file.
Previously, the location of declaration macros were sent to executable
plugins as if the were in the source file of the attribute. This was
problematic when the attribute is synsthesized by a macro. When source
location were used in the plugin, for example, as a diagnostic location,
it ended up with an unknown location.
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
