similar to: [RFC] Updating googletest to non-release tagged version

+Chandler who might have some thoughts on this. Could you provide an example here of the motivation for the feature you're missing? Might help motivate the discussion (and/or we'll end up nitpicking how it could be done differently without that feature... - which is sort of where I'm going with this. Combinatorial test case expansion does seem a bit suspicious to me - I'd hope we

On Thu, Mar 15, 2018 at 9:09 PM, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > +Chandler who might have some thoughts on this. > > Could you provide an example here of the motivation for the feature you're > missing? Might help motivate the discussion (and/or we'll end up nitpicking > how it could be done differently without that feature... - which

Thanks. The motivating example can be seen in this review: https://reviews.llvm.org/D44382. In that review, I am unit testing .debug_line parsing, specifically, the behaviour when the parser is fed a malformed section. Most of the code under test goes through some slight variations in the code path, depending on a) the DWARF version (interesting cases are 3, 4 and 5), and b) whether the DWARF is

On Thu, Mar 15, 2018 at 11:10 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Chandler who might have some thoughts on this. > FWIW, I have no concerns about updating to a modern googletest. More modern the better IMO if someone is willing to do the work to make sure it works on all our platforms, etc. However: > Could you provide an example here of the

On 19 March 2018 at 19:56, Chandler Carruth <chandlerc at gmail.com> wrote: > On Thu, Mar 15, 2018 at 11:10 AM David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> +Chandler who might have some thoughts on this. >> > > FWIW, I have no concerns about updating to a modern googletest. More > modern the better IMO if someone is willing to do

Hi Kees, You added some support for Minix to LLVM's copy of googletest: http://llvm.org/viewvc/llvm-project?view=rev&revision=100895 Is it still being used? If so, would you mind pushing these patches upstream to the googletest project: http://code.google.com/p/googletest/ Otherwise we may drop them, because it makes it harder to import new releases of googletest into the LLVM

2008/12/27 Mark Kromis <greybird at mac.com> > Is this something your planning as putting in the tree, >> thus require pulling in changes from google (license allowing), or does user >> need to have the libraries/headers pre-installed? >> > > Including it in the tree is the most reasonable thing to do. No point in > inconveniencing the user over tiny libraries

Hi Jay, >> yes, they are annoying aren't they. They all come from google's unittest >> library. I think it is best to fix them upstream at google. > > We're using googletest 1.5.0. These warnings seem to be fixed in > 1.6.0, so here's a patch to upgrade us. Disclaimer: I've only tested > this by doing "make check-all" on Linux/x86_64. >

> What is googletest ? Framework for units tests in llvm. http://code.google.com/p/googletest/ > Its aufully messy warnings wise on Cygwin. If you have gcc 3.X you are going to get a bunch of warnings. What gcc are you using? -Tanya

On 24 July 2011 10:59, Duncan Sands <baldrick at free.fr> wrote: > Hi Edward, > >> Building of llvm with gcc-4.5.2-1 gives these warnings: >> >> 1) Building FileManagerTest >> >> "llvm[4]: Compiling FileManagerTest.cpp for Debug+Asserts build >> C:/Programming/VersionControl/llvm/tools/clang/unittests/Basic/FileManagerTest.cpp: >> In

What is googletest ? Its aufully messy warnings wise on Cygwin. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090219/8de0a211/attachment.html>

On 01/29/2010 12:11 AM, Chris Lattner wrote: > On Jan 28, 2010, at 12:45 PM, Thomas B. Jablin wrote: > > >> Hi, >> Lately LLVM has been adding -fno-rtti to most of the compiler. I >> have a pass which uses LoopPass and which inherits from FunctionPass >> and a class of my own. If I compile my code with ENABLE_RTTI=1, I >> can't dynamically load

Thanks for the comments all. I've thought about it and I agree that I can probably reduce the number of test cases, so that it is not combinatorial, in my use case. I guess the broader question still is there as to whether a) people would be opposed to updating to a non-official-release version of googletest, and b) whether it would be worthwhile doing so. As I noted previously, there is at

On Sat, Dec 27, 2008 at 6:56 PM, Mark Kromis <greybird at mac.com> wrote: > > On Dec 27, 2008, at 7:41 PM, Misha Brukman wrote: > > 2008/12/27 Mark Kromis <greybird at mac.com> > >> Just a curiosity question, why push for gtest vs Boost Test or >> a different test suite? >> I normally use Boost, and their test suite, so I'm more familiar with

Doesn't sound like there's opposition - can't say whether or not it's wort hit, but if you're willing to give it a go/send a patch, probably can't hurt. Might be a bit of work to get all the corners right - I think there are a few local patches to the gtest in llvm, unfortunately, that you'd have to port over, etc. On Thu, Mar 22, 2018 at 3:59 AM James Henderson <

Yes, I imagine there will be some interesting issues. I'm away for a couple of weeks around Easter, so it will likely be a few weeks before I or anybody in my team get a chance to look at this further, but we'll certainly keep people updated on here with how it goes (or via reviews). James On 22 March 2018 at 15:03, David Blaikie <dblaikie at gmail.com> wrote: > Doesn't

I'm seeing some test failures for unit tests for msan (check-msan) happening in googletest, which I find weird. I'm on Arch Linux, with r342711. Below is one type of error that I see. The full log is 416MB (!) big. My guess is that those errors are related, but if anyone needs the full log, I'll provide it. Here is a reduced log from the end:

>> In my particular case from https://reviews.llvm.org/D44560, I currently >> test the following 3 different cases across the full set of DWARF >> versions and formats: >>  - Parsing a valid line table >>  - Emitting an error if the stated prologue length is greater than the >> actual length >>  - Emitting an error if the stated prologue length is

On Dec 27, 2008, at 11:01 PM, Misha Brukman wrote: > 2008/12/27 Mark Kromis <greybird at mac.com> >> Is this something your planning as putting in the tree, thus >> require pulling in changes from google (license allowing), or does >> user need to have the libraries/headers pre-installed? >> >> Including it in the tree is the most reasonable thing to do.

>> ...snip... > > Also for a note of reference, your links to the examples are the > most advanced samples. So boost can do more, thus has more weight/ > bloat behind it. > > Were the other test kits looked at? Is gtest the best solution for > the project. > > Is this something your planning as putting in the tree, thus require > pulling in changes from