This is an archive of the discontinued LLVM Phabricator instance.

Add FixItHint for missing #include (err_module_unimported_use_header)
AbandonedPublic

Authored by sammccall on Oct 6 2016, 4:45 AM.

Details

Reviewers
rsmith
Summary

The line is inserted using clang-format's logic with LLVM style.
Users must run clang-format afterwards if they want some other style.

Alternatives:

respect .clang-format: this would be surprising in the compiler
insert at offset 0: this is bad people who don't use clang-format
apply $simple_heuristic: clang-format handles lots of special cases for us

Event Timeline

sammccall updated this revision to Diff 73763.Oct 6 2016, 4:45 AM
sammccall retitled this revision from to Add FixItHint for missing #include (err_module_unimported_use_header).
sammccall updated this object.
sammccall added a subscriber: cfe-commits.

(First patch, so please spell out mistakes!)

I think the big question is whether it's okay to depend on Format.

ioeric added a subscriber: ioeric.Oct 6 2016, 4:57 AM

Ping - let me know if there's a more appropriate reviewer!

bruno added a subscriber: bruno.Oct 19 2016, 2:27 PM

Thanks for looking into this. It's a nice FixIt to have.

I don't see any dep cycle; clangFormat depends on clangToolingCore, which also depends clangRewrite, which means there are going to be 3 new dependencies for libSema in the end: clangToolingCore, clangRewrite and clangFormat.

I don't know the history behind the desired dependencies, I'll let others comment whether this is OK, but my guess it that it depends on the tradeoff, it's hard to justify 3 new deps for a change that is supposed to be simple. How hard is to implement this without using libFormat?

lib/Sema/SemaLookup.cpp
39

You also want clangToolingCore to be listed as a explicit dep since you're including from it.

I don't know the history behind the desired dependencies, I'll let others comment whether this is OK, but my guess it that it depends on the tradeoff, it's hard to justify 3 new deps for a change that is supposed to be simple. How hard is to implement this without using libFormat?

What libFormat does is fairly complex:

  • it parses header guards/file comments to avoid violating them
  • it locates existing includes to insert nearby
  • it is aware of "main header", and system vs user headers
  • it avoids generating a fixit if the header is already included somewhere
  • it preserves sort order within include blocks (I forgot to include this!)

This is fixCppIncludeInsertions in Format.cpp plus its helpers, and sortCppIncludes.

Altogether this looks like being around 500LOC that would be directly duplicated, plus some replacements for policy handled by LLVMStyle, plus tests (a new impl would need to be more thoroughly tested).
I also don't know what the costs of the dependency are.

ioeric: is my estimate about right?

lib/Sema/SemaLookup.cpp
4997

Hmm, I probably want to formatReplacements here for sorting...

I don't know the history behind the desired dependencies, I'll let others comment whether this is OK, but my guess it that it depends on the tradeoff, it's hard to justify 3 new deps for a change that is supposed to be simple. How hard is to implement this without using libFormat?

I think clang already depends on libclangRewrite. libclangToolingCore is tiny, it's basically just the Replacement class and a couple of utilities. While it would be possible to hoist just the include handling and its dependencies out of libclangFormat into a separate library I'm not convinced that it's worth it. libclangFormat is tiny, the .a file is less than a megabyte and the impact on the clang binary is 400kB in a Release+Asserts build, a 0.5% increase.

rsmith edited edge metadata.Nov 3 2016, 2:38 PM

I think clang already depends on libclangRewrite. libclangToolingCore is tiny, it's basically just the Replacement class and a couple of utilities. While it would be possible to hoist just the include handling and its dependencies out of libclangFormat into a separate library I'm not convinced that it's worth it. libclangFormat is tiny, the .a file is less than a megabyte and the impact on the clang binary is 400kB in a Release+Asserts build, a 0.5% increase.

Nonetheless, from a layering perspective, it doesn't make much sense for libSema to depend on libFormat. The functionality in question sounds like it belongs in Lex.

sammccall abandoned this revision.Nov 17 2017, 12:38 AM