[Tom]
| > - Per (your) above, ship something that has a 1:1 mapping to modules
| > that is a portable representation from which BMI's can be generated. (Or
| > which the compiler / tooling can consume directly. Some tooling
| > applications may be able to use these directly and never need a BMI.) I
| > think most (all?) of us prefer this.
|
| I don't think this is feasible.
|
| Different tools have different needs. Any portable representation will
| make trade offs regarding what information is retained from the source
| code. IPR for example, doesn't record source location column numbers
| for AST nodes (just line numbers),

That is clearly a fixable shortcoming; and I imagine that if we were to use the IPR that would be corrected along with other 'nice to have'.

| nor does it record macro expansion information.

That was explicit design decision of the IPR so we could focus on the meat, but not one that blocks addition of such information.

| For some tools, e.g., Coverity, that information is
| crucial; our analysis would be compromised if we were limited to what
| IPR exposes.

I am interested in fatal flaws of the IPR design. All these you listed are fixable.

| Additionally, implementation defined behavior means that different
| implementations might produce representations of the source code that,
| while in a portable format, have different contents. For example, the
| point of instantiation of templates is implementation defined in some
| cases and that can produce observable behavior differences.
|
| Tom.

That is more "please record this is not guaranteed by the standards" note.

-- Gaby