-dinline-check for symbolic names?

[Simon Peyton Jones]

|  First, reading the ghc source code suggests I can only have one -ddinline-
|  check. Correct?

Yes. The last one wins.  This should be in the user manual.  Would anyone like to offer a PR?

|  Also, I'm guessing that the inlining I didn't see reported by -dinline-check
|  happened inside the simplifier pass inserted by the ConCat plugin.  (And
|  hence INLINE [0] moved it out of that pass.)  Is it possible that the flag
|  isn't getting propagated there?

I don't see how that could happen, but I only have a vague idea of what is going on.

Simon

|  -----Original Message-----
|  From: Michael Sperber <sperber at deinprogramm.de>
|  Sent: 18 August 2021 14:14
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: glasgow-haskell-users at haskell.org
|  Subject: Re: -dinline-check for symbolic names?
|  
|  
|  On Tue, Aug 10 2021, Simon Peyton Jones <simonpj at microsoft.com> wrote:
|  
|  > It's hard to tell what is happening without a repro case. Can you share
|  one?
|  
|  Haven't been able to do that with <10MB of output, I'm afraid ...
|  
|  > You suggested that it might have something to do with using an
|  > operator.  Does the same thing happen if you replace the operator with
|  > an alpha-numeric name?
|  
|  I've now concluded several things are coming together.  As things started
|  working with INLINE [0] instead of INLINE, it's not the symbolic name.
|  
|  First, reading the ghc source code suggests I can only have one -ddinline-
|  check. Correct?
|  
|  Also, I'm guessing that the inlining I didn't see reported by -dinline-check
|  happened inside the simplifier pass inserted by the ConCat plugin.  (And
|  hence INLINE [0] moved it out of that pass.)  Is it possible that the flag
|  isn't getting propagated there?
|  
|  (Sorry for being vague - if you don't know offhand, it's not worth digging
|  without more info from me.)
|  
|  --
|  Regards,
|  Mike