search for: iwyu

Hi Michael, On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > > Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on > LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong). There are known problems with running IWYU over LLVM/Clang -- Zachary Turner made an attempt a while back to get it up and running. Since the LLVM tree uses all...

Hey all, IWYU maintainer here. I wanted to make a small observation. Surprisingly, IWYU will most often *add* includes to a reasonably well-factored codebase, and this ties into Chris' comment: > Beyond that though, this seems like obvious > goodness to reduce coupling in the codebase. Just blindly...

...v < cfe-dev at lists.llvm.org> wrote: > Hi Kim, > > On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at gmail.com> wrote: > > Hi Michael, > > On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin > <mzolotukhin at apple.com> wrote: > > > Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on > LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong). > > > There are known problems with running IWYU over LLVM/Clang -- Zachary > Turner made an attempt a while back to get it up and running. Since &gt...

...? If so, seems like probably more aggressive than we want to be, because it makes our codebase fragile: If someone removes class1.h from class2.h, it may break foo.cc. I'm sure we can find many situations like this today, but this approach seems it would make that situation much more common. IWYU would avoid this pitfall, although I know IWYU has its own problems. Alternatively maybe if the tool only removed headers whose removal significantly decreased the preprocessed size of the file, we'd know that we actually removed "something interesting". -Justin On Tue, Dec 5, 2017...

...>> Hi Kim, >> >> On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at gmail.com> wrote: >> >> Hi Michael, >> >> On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin >> <mzolotukhin at apple.com> wrote: >> >> >> Nice to IWYU developers here:) I wonder how hard it would be to run IWYU >> on >> LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong). >> >> >> There are known problems with running IWYU over LLVM/Clang -- Zachary >> Turner made an attempt a while back to get...

...llvm-dev < llvm-dev at lists.llvm.org> wrote: > I, for one, want faster builds. > > Beyond that though, this seems like obvious goodness to reduce coupling in > the codebase. I’ve only skimmed the patch, but this seems like a clearly > amazingly great ideas. Did you use the IWYU tool or something else? > > -Chris > > > On Dec 5, 2017, at 3:40 PM, Mikhail Zolotukhin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi, > > Recently I've done some experiments on the LLVM/Clang code and discovered > that many of our source file...

Hi, Recently I've done some experiments on the LLVM/Clang code and discovered that many of our source files often include unnecessary header files. I wrote a simple tool that eliminates redundant includes and estimates benefits of doing it, and the results were quite nice: for some files we were able to save 90% of compile time! I think we want to apply some of the cleanups I found, but

Hello, For the IWYU project, we have a buildbot on Ubuntu 16.04 and its bundled GCC (which I think is some GCC 5 variant). We're getting a number of -Wstrict-aliasing warnings from JSON.h on this line: https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/JSON.h#L455 I'm not sure if GCC has a...

Hi all, Not sure if there's a better forum for lit discussion, please advise. I'm experimenting with lit for IWYU testing. We're a little sensitive to relative vs absolute paths, especially when trying to determine the include-name for various headers. I've noticed lit always expands substitutions (e.g. %s) to absolute paths, and I'd like to be able to introduce substitutions for the source path re...

...means that removing the include to `foo.h` in `bar.h` would break the client of bar that relied on this transitive includes. That makes refactoring of a components harder since it may break some of the clients of the components for no other reason than this transitive include. I suspect this is why IWYU would instead *add* these includes when they're missing. -- Mehdi > > > I suggest that from here we go as follows: maintainers/interested people > take a look at files related to their components and pick the parts of the > patches that they consider correct. I'll also...

~~~ Not to be applied, for discussion only ~~~ I think we need some kind of "checkpatch" script to catch all the annoying, nitpicky code style issues that submitters trip up on. I looked at a few scripts that exist, primarily the ones from Linux and qemu (massive and complicated), and libvirt (small and sane). There are a couple of problems: (1) Linux/qemu-style checkpatch only

Hello Clang folks, I was using -ftime-trace to see where the compiler spends time parsing clang's own headers, and it pointed me to Type.h. Many AST headers need QualType to be complete, but they do not need the full type class hierarchy. To improve compile time, I have attempted to create a new header, QualType.h, that defines only the QualType wrapper class. I have started to transition

....llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > I, for one, want faster builds. > > Beyond that though, this seems like obvious goodness to reduce coupling in the codebase. I’ve only skimmed the patch, but this seems like a clearly amazingly great ideas. Did you use the IWYU tool or something else? > > -Chris > > >> On Dec 5, 2017, at 3:40 PM, Mikhail Zolotukhin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> >> Recently I've done some experiments on the LLV...

Hi, I tweaked my scripts to avoid removing includes when it doesn't give any significant benefits, which made the patches significantly smaller. This time the patches should not try to remove includes of header files, which are transitively included from other included header files. The gains mostly remained the same (plus/minus noise), the tables are in the end of the email. I also included

...(Reported by Ray Crumrine) * ASTERISK-25670 - Add regcontext to PJSIP (Reported by Daniel Journo) * ASTERISK-25660 - Add sipp-sendfax.xml and spandspflow2pcap.py to contrib/scripts. (Reported by Walter Doekes) * ASTERISK-25591 - [patch] Complete List of Header Files (#include): iwyu (Reported by Alexander Traud) * ASTERISK-25551 - [patch]Ability to add channel to an existing bridge by specifying an existing channel prefix (Reported by Alec Davis) * ASTERISK-25419 - Dialplan Application for Integration of StatsD (Reported by Ashley Sanders) * ASTERISK-25549...

...t;https://issues.asterisk.org/jira/browse/ASTERISK-25660>] - Add sipp-sendfax.xml and spandspflow2pcap.py to contrib/scripts. (Reported by Walter Doekes) - [ASTERISK-25591 <https://issues.asterisk.org/jira/browse/ASTERISK-25591>] - [patch] Complete List of Header Files (#include): iwyu (Reported by Alexander Traud) - [ASTERISK-25551 <https://issues.asterisk.org/jira/browse/ASTERISK-25551>] - [patch]Ability to add channel to an existing bridge by specifying an existing channel prefix (Reported by Alec Davis) - [ASTERISK-25419 <https://issues.asterisk.org/ji...