option for not reordering #includes

[GoogleCodeExporter]

iwyu reorders #include files alphabetically. This does not work for projects 
that have a different style, such as including public headers before internal 
ones, and one particular public header before the other public ones. (For 
example, in ICU.)

Please add an option to turn off reordering. In that case, iwyu should add new 
#includes after the last existing one.

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

• Merged into: #35

[GoogleCodeExporter]

I'm happy to look at a patch!

(btw, where to add #includes is a surprisingly difficult problem.  "Add a new 
#include after the last existing one" works fine in many cases, but what about 
code like this?
---
#include "foo"
#include "bar"

class Whatever { ... };

#ifdef _MSC_VER
#include <windows.h>

Whatever* WhateverFactory() { ... }
#endif
---

But this is all an aside, I think the existing logic to handle this is 
separable from the sorting we do.  So it may not be that difficult to patch 
this.)

I've also heard complaints from one or two people that sorting #includes is ok, 
but sorting forward-declares is annoying.  So it may make sense to have two 
flags, or one flag that controls both aspects of sorting.  Sadly, turning off 
sorting for forward-declares is probably harder than turning off sorting for 
namespaces, since you'd want to insert with other forward-declares in the same 
namespace as you, not at the end.

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

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I think this will probably end up being the same as issue 35.  If we add a new 
--sort_command flag, --sort_command=cat would mean 'do not sort at all'.

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

[GoogleCodeExporter]

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

• Changed state: Duplicate