-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Lldb cleanups #19166
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
Lldb cleanups #19166
Conversation
The file doesn't adhere to the python standard, but this will let vi do The Right Thing by default
Be more idiomatic and rely less on fiddly construction of output
|
||
if has_field_names: | ||
output += " { \n" | ||
template = "{\n%(type_name)s%(body)s\n}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it would put the type name inside the braces instead of in front of them.
Apart from the comments above this looks good to me. If you fix these, please run |
I'm fixing the issues now. The test harness looks broken on master. Poking now. |
template = "%(type_name)s(%(body)s)" | ||
separator = ", " | ||
|
||
if not type_name.startswith("("): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like it's the same predicate as has_field_names
, but I haven't dug far enough or thought hard enough about it to verify. If it is, this can be cleaned up further by just removing the $(type_name)s
from the second template. Is that accurate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's a bit different. Tuple structs have a type name but no field names, as in struct MyInt(int)
. The same is true for tuple-like enum variants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, as opposed to a type alias for a tuple type, eg type Foobar = (int, f64)
?
Ignore that, it's just namespaced enums fall out. Patch will go out on this PR in a sec. |
Ok, the non ignored tests are all green, and the compiletest harness works (is there a reason this doesn't happen in CI? something something bors doesn't have debuggers handy?) |
Thanks, @richo. This looks good to me now.
part at the top should have taken care of that. @alexcrichton, any idea what that's about? |
Yeah that's fine, the stage0 compiler inserted that import automatically (essentially), so it's flagged as unused, but the stage1+ compiler doesn't do that, so we have to add it explicitly. |
Yeah, but even with the explicit use statement, these changes in |
Oh now that I wouldn't expect! |
It may just be some stage0/stage1 weirdness though, I wouldn't worry too too much about it. |
Thanks Alex! I'll try to give bors the OK on the PR. |
While poking at rust in lldb I found a few nits to clean up.
fix: Fix sorting of runnables
While poking at rust in lldb I found a few nits to clean up.