-
-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
driver: add support for a more generic diagnostic handler #4302
base: master
Are you sure you want to change the base?
Conversation
Perhaps, we can get rid of default llvm diagnostic printer and use DMD error/warning functions. |
Do you have a test case for this? |
ef1460b
to
65c7215
Compare
tests/codegen/attr_warn_stack_size.d
Outdated
|
||
import ldc.attributes; | ||
|
||
// CHECK: {{.*}}Warning: stack frame size (8) exceeds limit (1) in '_D20attr_warn_stack_size6foobarFiZf' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm defering to LLVM demangler. I'm working on upstreaming the demangler, but for now it like this, should I abstract this from the test too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can also use {{.*}}foobar
to not depend on yes/no demangling. If demangling works, I'd make it part of the test, if it doesn't then remove demangling yes/no assumption from the test.
From my PR description :)
|
#if LDC_LLVM_VER > 1400 | ||
llvm::StringRef fname; | ||
unsigned line, column; | ||
DISS.getLocation(fname, line, column); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is getting the location generalizable for all cases? (i.e. call it before switch
using DI
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I can change this to use the IR state loc, when its not available through the diagnostic info object.
#else | ||
const auto loc = Loc(nullptr, 0, 0); | ||
#endif | ||
switch (DISS.getSeverity()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this also seems generalizable (i.e. not individual switches for severity for each kind of diag info type?)
error(loc, "stack frame size (%ld) exceeds limit (%ld) in '%s'", | ||
DISS.getStackSize(), | ||
DISS.getStackLimit(), | ||
llvm::demangle(DISS.getFunction().getName().str()).c_str() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we use the LLVM demangler anywhere else in the codebase? Not better to use D's own demangler?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(because then it is always up-to-date, when building LDC with itself)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(because then it is always up-to-date, when building LDC with itself)
I don't think so. Makes sense to use the official one due to that, but the tradeoff is that is very slow. core.demangle
use exceptions for control flow, which is an horrible implementation. I have a project to update the official demangler to a decent and fast parser, but I endedup getting out of time for these things :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The compiler is erroring, don't worry about performance, it's fine if it takes an extra second even. ;)
Nice. I wonder if there are other LLVM attributes that can generate errors/warnings, such as Edit: even if we defer for other diagnostic kinds to the default LLVM's diagnostic function, we can still ++ global.errors or warnings, such that -w is respected. |
a539f13
to
2e943f8
Compare
2e943f8
to
2fe9396
Compare
Yeah, makes sense to me, but keep in mind that apparently, warning severities does write to stdout. |
I can't really understand what I'm doing wrong in the test. Maybe its trivial but I'm not getting there. |
Signed-off-by: Luís Ferreira <[email protected]>
2fe9396
to
626823c
Compare
Btw, wrt. |
To run lit-based tests locally, go into your build folder, go to |
|
||
// REQUIRES: atleast_llvm1400 | ||
|
||
// RUN: %ldc -wi -c %s 2>&1 | FileCheck %s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be a not
if you want it to error out, I think you had that correct in the first commit. But you need a fix for kinke's comment: #4293
Yes, it fixes it! I'll also add a test case for it. |
…m errors Based on Luís' ldc-developers#4302.
…m errors Based on Luís' ldc-developers#4302; fixes ldc-developers#4293.
…op compilation Based on Luís' ldc-developers#4302; fixes ldc-developers#4293.
…op compilation Based on Luís' ldc-developers#4302; fixes ldc-developers#4293.
Signed-off-by: Luís Ferreira [email protected]
Fixes #4293.
I can't add you as a reviewer @JohanEngelen since I don't have permissions on LDC org. This is something I need cherry-picked in weka to diagnose traces with possibly bigger stack usage than permitted.
The default seem to warn on stdout rather than stderr and also doesn't respect
-w
and-wi
command line options and therefore it seem to not working on our build system diagnostics.This also further improves the existing logic on diagnostic handler as it was wrongly checking the
DiagnosticInfoSrcMgr
severity and not incrementing the error counter.I'm going to add tests for this tomorrow.