allow for user-specified order for #includes

[GoogleCodeExporter]

When reordering #includes, iwyu appears to use a case-sensitive ASCII 
comparison. It would be nicer to be case-insensitive, and even better to also 
sort punctuation before digits before letters.

Original issue reported on code.google.com by markus.icu on 5 May 2011 at 8:34

[GoogleCodeExporter]

I believe everyone will have their own idea how to sort (does a dot come before 
letters or after?  What about a dash?  How do they compare to each other?)  The 
only consistent way to do it is to sort in ascii order.  This is also 
consistent with tools folks might have on their own to do sorting, within their 
editors.

I think the best thing to do (and this is perhaps relevant to issue 34 as 
well), is to have --sort_command="...", which is an external shell command we 
execute to sort a bunch of #includes.  You can then write a sorting routine of 
your choice (as a script, if necessary), which fix_includes.py will call out to.

The default will be equivalent to 'env LANG=C sort', which is what we do now 
(in python, of course; no need to call out to sort).

The existing title ('improve order of #includes') I would close as 
WorkingAsIntended.  So Instead I'm changing the title to what I think is a 
reasonable enhancement.

Original comment by csilv...@gmail.com on 12 May 2011 at 9:46

• Changed title: allow for user-specified order for #includes
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Issue 34 has been merged into this issue.

Original comment by csilv...@gmail.com on 25 Oct 2011 at 1:07

[GoogleCodeExporter]

I'm happy with the sort order currently :-), so I won't make this change 
myself, though I'm happy to look at a patch.  The line you'd want to modify is 
in fix_includes.py:
     decorated_move_spans.sort()
decorated_move_spans is a list of (reorder_span, kind, sort_key, 
all_lines_as_list) tuples.  You would want to collect all members of the tuple 
that have the same reorder_span and kind, and sort them.  If flags.sort_command 
(a new flag that would be added) is set, it would sort them by passing all the 
sort_key's to the sort-command, and then sorting the decorated_move_span 
objects based on what that returns.

The sort_key is basically the #include (or forward-declare) line with all 
whitespace and comments removed.  Kind is 'system' or 'user', so you won't need 
to worry about distinguishing those in your sort command; you can assume that 
all #include lines to a single call to sort_command are either for <>-includes 
or ""-includes.  (But of course, the input to sort_command may not be #include 
lines at all, but rather forward-declarations!)

Original comment by csilv...@gmail.com on 25 Oct 2011 at 1:17

[GoogleCodeExporter]

How could I do a user-defined ordering of includes? I have one master-include 
file that contains lots of preprocessor defines that configure the project. All 
other includes should come afterwards. How could this be done in 
fix_includes.py - could there be an extra option like a prio list of includes 
or something similar?

The current alphabetical ordering breaks my code, which - I know - is a defect 
in the code, though keeping the ordering for the first run and cleaning the 
other stuff would be a first step.

Original comment by stefan.d...@gmail.com on 10 Sep 2014 at 11:40

[GoogleCodeExporter]

I wasn't even aware that fix_include.py did any ordering, but I see from 
csilvers' response above that it does.

I know IWYU itself sorts the include lines to make sure PCHs come first, 
associated headers next, then system headers and finally other headers, all in 
alphabetical order. So even if you disabled sorting in fix_includes.py, it 
looks like all headers would be shuffled anyway.

Do you have any ideas for how you could express the desired ordering?

Original comment by kim.gras...@gmail.com on 11 Sep 2014 at 3:46