Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-10562] Imported NS_ERROR_ENUM errors have weird "related decl" description #52962

Open
lilyball mannequin opened this issue Apr 26, 2019 · 5 comments
Open

[SR-10562] Imported NS_ERROR_ENUM errors have weird "related decl" description #52962

lilyball mannequin opened this issue Apr 26, 2019 · 5 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself runtime The Swift Runtime

Comments

@lilyball
Copy link
Mannequin

lilyball mannequin commented Apr 26, 2019

Previous ID SR-10562
Radar None
Original Reporter @lilyball
Type Bug
Environment

Apple Swift version 5.0.1 (swiftlang-1001.0.82.4 clang-1001.0.46.5)
Target: x86_64-apple-darwin18.5.0

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Runtime
Assignee None
Priority Medium

md5: e29b89b358725c5ca7df0cc90a76c495

Issue Description:

When printing an error created from an Obj-C NS_ERROR_ENUM declaration, the imported error has a bizarre synthesized description that looks like "related decl 'e' for <desc>" (where <desc> is the actual expected description).

For example, with the following Obj-C header:

extern NSErrorDomain const FooErrorDomain;
typedef NS_ERROR_ENUM(FooErrorDomain, FooError) {
    FooErrorOne = 1,
    FooErrorTwo
};

Printing a FooError(.one) from Swift produces the description

related decl 'e' for FooError(_nsError: Error Domain=FooErrorDomain Code=1 "(null)")

And the debug description looks like

__C_Synthesized.related decl 'e' for FooError(_nsError: Error Domain=FooErrorDomain Code=1 "(null)")

@lilyball
Copy link
Mannequin Author

lilyball mannequin commented Apr 26, 2019

Similar output is obtained by printing FooError.self.

@belkadan
Copy link
Contributor

Yeah, I'm not sure what to do about this one. "FooError" is officially the C enum, not the wrapper struct, but maybe that doesn't matter when doing a demangling that doesn't have to be unique.

@belkadan
Copy link
Contributor

@mikeash, any opinions? (Or Lily, for that matter.) I wrote the original code here but only to fit imported errors into the existing demangling framework, not because I was finessing the output to some spec.

@mikeash
Copy link
Contributor

mikeash commented Apr 29, 2019

Seems like it would be pretty decent by just removing the "related decl 'e' for " part.

@lilyball
Copy link
Mannequin Author

lilyball mannequin commented Apr 29, 2019

Yeah, I'm not thrilled at the _nsError: output but it's at least understandable and clearly a field of the type. The "related decl 'e' for" is just confusing, and if it were removed but everything else left as-is that would be fine (and would match how e.g. CocoaError is printed).

Though I'd also suggest that the __C_Synthesized. prefix on the debug description should go away as well.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself runtime The Swift Runtime
Projects
None yet
Development

No branches or pull requests

2 participants