dblaikie added a comment.

> This pass prints a TON of (helpful) information...we have a lot of 
> -Wframe-larger-than= instances triggered in our codebase...I think having 
> this on by default would blow our logs significantly. That's why it might be 
> nice to have a Note suggest a flag (default off) for more info on a case by 
> case basis.

I'm not sure we'd need/want to optimize a diagnostic experience for a codebase 
that's got a lot of latent warnings. If people have lots of existing warnings 
they should probably turn the warning off (in those instances, at least) & I 
think saying "this function has a frame that's too big" without any info is 
pretty hard to act on, so it doesn't seem totally outside the realm of good 
diagnostics for this particular diagnostic to print a lot of info to help a 
user act on it/fix the issue when they get it. If most of the time you see this 
warning and want to fix it, you had to run your build again with an extra flag 
- I'd say that was a bad diagnostic experience, we should give them enough info 
the first time around.

If most of the time you don't need this info - yeah, that's something we should 
figure out, how to provide the right amount of info to be actionable, but in 
this case I suspect more-often-than-not you want some kind of report/breakdown. 
If it's a case of not having a way to make it more targeted/actionable and we 
just have two options ("too terse" and "too verbose") fairly evenly split (it's 
not clear that most of the time one or the other is the right answer) - I guess 
two different warning flags or some kind of modifier flag could be suitable. I 
guess we have that for template recursion things, maybe? Where you can ask if 
you want the full expansion, but by default we give you a summarized one, 
skipping expansions we don't think are relevant (I might be misremembering).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135488/new/

https://reviews.llvm.org/D135488

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to