Skip to content

properly handle isolated and _const type reprs when printing #58729

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

Merged
merged 2 commits into from
May 12, 2022

Conversation

QuietMisdreavus
Copy link
Contributor

Resolves rdar://92756749

When using the ASTPrinter to print functions with isolated or @const parameters, the printer currently doesn't know how to handle these attributes. A build with assertions will crash, while a build without assertions will render it as inout. This PR adds branches for these in SpecifierTypeRepr::printImpl, so that they can be properly printed.

@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please smoke test

break;
case TypeReprKind::CompileTimeConst:
Printer.printKeyword("_const", Opts, " ");
break;
default:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is why I dislike default :)

Copy link
Contributor

@daniel-grumberg daniel-grumberg May 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@QuietMisdreavus I am confused how this led to "inout" being printed. Is that the default for function parameters in the SGF? If no one is relying on this switch being exhaustive we could just remove the default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's an issue with builds that have assertions disabled. With assertions enabled, the code (correctly) crashes when seeing _const or isolated. Without assertions, though, the llvm_unreachable macro turns the branch into UB - which i assume in this case just picks a different branch arbitrarily.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense! should we just remove the default case if no one cares about being exhaustive though?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having the default there is still useful - this is a problem of test coverage (i don't know what else uses the AST Printer, TBH), not necessarily the switch being incorrect.

@QuietMisdreavus QuietMisdreavus force-pushed the QuietMisdreavus/const-decls branch from 8b940db to ba17e42 Compare May 6, 2022 23:34
@QuietMisdreavus
Copy link
Contributor Author

I added another test to check isolated and not just _const.

@swift-ci Please smoke test

// CHECK-NEXT: },
// CHECK-NEXT: {
// CHECK-NEXT: "kind": "text",
// CHECK-NEXT: "spelling": ": "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a "_const" fragment after this or is this handled further down the stack from TypeRepr

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is correct without the _const fragment; SymbolGraphGen filters out any decl attributes that begin with an underscore. If/when the @const feature is accepted, the attribute will be changed to one without an underscore (if the SE discussion continues to hold up, it should be @const), at which point SymbolGraphGen will stop filtering it.

@QuietMisdreavus
Copy link
Contributor Author

It looks like there were some CI issues last week; here goes nothing...

@swift-ci Please smoke test

@QuietMisdreavus
Copy link
Contributor Author

After some offline discussion, i've pushed a commit that removes the default branch in this switch. It does this by adding a new macro SPECIFIER_TYPEREPR to TypeReprNodes.def and uses this to delineate between SpecifierTypeRepr kinds and other TypeRepr kinds. This should make this issue more apparent in the future, if/when more SpecifierTypeRepr kinds are added.

@swift-ci Please test

@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please test

@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please test macOS

@QuietMisdreavus
Copy link
Contributor Author

@swift-ci Please test Windows

@QuietMisdreavus QuietMisdreavus merged commit e819415 into main May 12, 2022
@QuietMisdreavus QuietMisdreavus deleted the QuietMisdreavus/const-decls branch May 12, 2022 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants