Skip to content

[sil] Add an implicit operator bool conversion to SILDebugLocation. #33161

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

Conversation

gottesmm
Copy link
Contributor

The reason to do this is that one can now do:

if (auto debugLoc = i.getDebugLocation()) {
  // do something with debug loc.
}

I also cleaned up the style a little bit by renaming the internal ivars to be
camelCase.

The reason to do this is that one can now do:

```
if (auto debugLoc = i.getDebugLocation()) {
  // do something with debug loc.
}
```

I also cleaned up the style a little bit by renaming the internal ivars to be
camelCase.
@gottesmm gottesmm requested a review from adrian-prantl July 28, 2020 18:44
@gottesmm
Copy link
Contributor Author

@swift-ci smoke test

@gottesmm gottesmm merged commit 3f2873b into swiftlang:master Jul 29, 2020
@gottesmm gottesmm deleted the pr-bd42cfb6401f22297a2fa6a1ee127f25b7170f11 branch July 29, 2020 01:38
@@ -755,17 +755,18 @@ class SILDebugScope;

/// A SILLocation paired with a SILDebugScope.
class SILDebugLocation {
const SILDebugScope *Scope = nullptr;
SILLocation Location;
const SILDebugScope *debugScope;
Copy link
Contributor

Choose a reason for hiding this comment

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

The original code used the LLVM naming convention. Do we now have a Swift naming convention that's different from the LLVM one?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. Swift does camelCase for variables. We are slowly changing over time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And LLVM is changing more to that style as well

: Scope(DS), Location(Loc) {}
SILLocation getLocation() const { return Location; }
const SILDebugScope *getScope() const { return Scope; }
: debugScope(nullptr),
Copy link
Contributor

Choose a reason for hiding this comment

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

I prefer the = nullptr spelling, since it makes it harder to forget to initialize the member when adding a new constructor.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok. To me it just looked redundant. I am fine fixing it in a follow on commit.

: debugScope(debugScope), location(location) {}
SILLocation getLocation() const { return location; }
const SILDebugScope *getScope() const { return debugScope; }
operator bool() const { return bool(location) && debugScope; }
Copy link
Contributor

Choose a reason for hiding this comment

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

This part LGTM.

@adrian-prantl
Copy link
Contributor

The reason to do this is that one can now do:

if (auto debugLoc = i.getDebugLocation()) {
  // do something with debug loc.
}

Are there any legitimate cases where we would have an invalid location on an instruction when we're not inside of SILGen or SILParser?

@adrian-prantl adrian-prantl requested a review from vedantk July 29, 2020 22:53
@gottesmm
Copy link
Contributor Author

@adrian-prantl It can happen at any time and code (like what I am writing now) should be able to be conservative, unless there is a verification check that I can depend on this always being there.

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.

2 participants