- User Since
- Jan 26 2015, 9:26 AM (138 w, 5 d)
Thu, Sep 21
Wed, Sep 20
But just a thought: Is it worth doing all the work to scan for line endings for the interruption points? What if, instead, it just printed the next _n_ characters on each iteration until the entire buffer has been printed. Sure, sometimes an interruption will split a line, and sometimes it won't. I'm not sure that's important for interactive usage. It would mean less fiddly code, faster output (because you don't have to scan every character), and a zillion short lines will print as fast as a smaller number of longer lines that represents the same volume of text.
Tue, Sep 19
Mon, Sep 18
Fri, Sep 15
I haven't looked at the whole patch yet, but it seems the SIGINT fix is well isolated. That should probably be in a separate patch.
Wed, Sep 13
@sas: Do the latest changes address your concerns with this patch?
LGTM. Thanks for adding the tests.
Tue, Sep 12
Adds code-gen test. Corrects problem with first param of static method being
treated as the type of the this pointer. Addresses style suggestions.
Good tip on the lowering. Extra test coming momentarily.
Mon, Sep 11
Fri, Sep 8
I think I agree with Jim that it would be better to propagate an error from DoResume than to introduce CanResume. I could imagine situations where DoResume could fail for a reason that CanResume was unable to predict. Having one path for handling failure to resume seems cleaner.
Thu, Sep 7
I'll commit it momentarily.
Wed, Sep 6
This looks fine.
Tue, Sep 5
Nice description of the problem.
Thu, Aug 31
Aug 4 2017
Addressed additional feedback.
Simplified NativeEnumTypes by moving work to NativeSession which already had
access to Tpi and thus LazyRandomTypeCollection. NativeEnumTypes can now
exactly answer how many objects is knows about because it scans the types
when its constructed and maintains a vector of the relevant TypeIndexes.
Aug 2 2017
I'll ping when it's ready for another look.
Aug 1 2017
Enable llvm-pdbutil to list enumerations using native PDB reader
Jul 28 2017
I'm reworking NativeEnumTypes per the discussion. I'll have an update on Monday.
Jul 27 2017
Jul 21 2017
Jul 17 2017
Jul 12 2017
Jul 11 2017
Switched from std::unordered_map to llvm::DenseMap per zturner's suggestion.
Addressed feedback from zturner and rnk.
I've got one more suggestion from Zach to take care of, then I'll upload an updated patch.
Jul 10 2017
Jul 9 2017
Jul 5 2017
Jun 28 2017
So the idea is to convert the mangled name to an AST and then convert the AST to a string. That makes sense. But is the string form of the result always enough? Will there ever be a need for a caller to get the AST or some other representation?
Jun 27 2017
Fixed order of includes to comply with LLVM style
Addresses feedback from zturner.
Jun 23 2017
Thanks for doing this. This seems a reasonable alternative to fixing all the build tools upstream. And overly long paths are difficult to read.
Jun 22 2017
Thanks for the clarification.
Jun 21 2017
Jun 16 2017
Jun 13 2017
Jun 9 2017
It looks like some unrelated changes got mixed in here.
Jun 1 2017
May 24 2017
Thanks for checking! I'd like to see that conclusion in a comment somewhere appropriate and a test to make sure it doesn't regress.
I'm slightly confused by the summary. This patch changes where the names are written to. How do we know that right versus changing where the names are read from?
May 16 2017
Having just figured out some of this pipeline stuff, I really appreciate making this easier to user.
May 5 2017
May 4 2017
Thanks for the changes. Those make it much easier to understand.
Apr 26 2017
I'm satisfied, but you might want to wait to hear from at least one other reviewer.
Looks nice. I noticed just minor stuff.
Apr 20 2017
Better solution after discussion with inglorion and zturner.
Apr 19 2017
Apr 10 2017
Thanks for the review, especially for the heads up on the merge points.
Apr 7 2017
Not really in the scope of this change, but, since BitVector has these STL-like methods, 'twould be nice if there were a BitVector::npos analogous to std::basic_string::npos rather than having all the users of the class have to hardcode the magic value or make vague checks like >= 0.
With this, it seems llvm-pdbdump is becoming a more sophisticated analysis tool rather than just a dumper. It makes me wonder whether this is the best tool to do this kind of analysis. On the one hand, it works for any binary with a PDB, whether it's built by clang or MSVC. On the other hand, it's not useful for clang-built binaries targeting other platforms. It almost seems like it should be done looking at the IR rather than the final debug info.
Apr 6 2017
Clang-format did some awkward comment wrapping in some of the new code.