On 2/11/19 8:45 AM, Erik Skultety wrote: > On Mon, Feb 11, 2019 at 08:33:32AM -0500, John Ferlan wrote: >> >> >> On 2/11/19 7:44 AM, Erik Skultety wrote: >>> On Fri, Feb 08, 2019 at 01:37:26PM -0500, John Ferlan wrote: >>>> Let's make use of the auto __cleanup capabilities cleaning up any >>>> now unnecessary goto paths. >>>> >>>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> >>>> --- >>> ... >>>> target->backingStore->type = VIR_STORAGE_TYPE_NETWORK; >>>> target->backingStore->path = meta->backingStoreRaw; >>>> @@ -3430,8 +3428,6 @@ storageBackendProbeTarget(virStorageSourcePtr target, >>>> target->format = meta->format; >>>> >>>> /* Default to success below this point */ >>>> - ret = 0; >>>> - >>> >>> Not sure how much sense the comment makes without ^this hunk, I think we can >>> drop it too >> >> 50/50 coin flip, I can remove >> >>> >>> MinGW is still stuborn about inlining in certain VIR_AUTO cases, I'm wondering >>> why GCC and Clang are okay with that and whether we should drop -Winline or go >>> without the cases that MinGW is sad about, I tried to lookup something related, >>> but it doesn't seem to be a recent bug in MinGW. >>> >>> I'm okay with the changes, but I don't want to have a failing build for the >>> next X weeks, so I'd say drop the violators: >> >> I don't know which violators exist as I don't build MinGW nor do I have >> whatever nifty environment generates that type of build as my normal >> process. > > You can either set up your own environment with Andrea's lcitool or you can $ grep lcitool docs/*.in ;-)... IOW: Maybe we should document the procedure in our hacking for "everyone" to use. > make use of github's travis integration: > https://travis-ci.org/eskultety/libvirt/jobs/491591878 > So from your output it seems: virStorageFileMetadataNew virStorageFileGetMetadataFromFD virStorageSourceCopy virStorageSourceUpdateCapacity virStorageSourceNewFromBackingAbsolute virStorageSourceNewFromBacking virStorageFileGetMetadataRecurse virStorageFileGetBackingStoreStr or IOW everything in src/util/virstoragefile.c other than I think virStorageSourceNewFromBackingRelative, although there is one pile of compiler output without an "In function '%s':" before the compiler error output "inlining failed in call to" before it which I assume is the *Relative call. Dropping those means dropping a bunch of patches before too since the only reason to change was to do this AUTOPTR magic. As a side note I find it really odd that the order listed in the compiler output doesn't exactly follow the order in the source. In particular starting with virStorageSourceUpdateCapacity (line 3832) is listed in the output before virStorageSourceNewFromBackingAbsolute (line 3613). Still it makes me wonder what's different in src/util from others that causes src/util to throw up, while src/conf, src/qemu, tests/, etc. don't throw up. Reading m4/extern-inline.m4 doesn't help me. John
