This is an archive of the discontinued LLVM Phabricator instance.

[clang] Emit SARIF Diagnostics: Create `clang::SarifDocumentWriter` interface
ClosedPublic

Authored by vaibhav.y on Sep 13 2021, 9:05 AM.

Details

Summary

Create an interface for writing SARIF documents from within clang:

The primary intent of this change is to introduce the interface clang::SarifDocumentWriter, which allows incrementally adding diagnostic data to a JSON backed document. The proposed interface is not yet connected to the compiler internals, which will be covered in future work. As such this change will not change the input/output interface of clang.

Previous discussions:

See also:

SARIF Standard (2.1.0):

Diff Detail

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
vaibhav.y updated this revision to Diff 385813.Nov 9 2021, 7:31 AM

Format code using patch from buildkite

Ping.

clang-format is the only check failing as of now (attempting to reformat the <a> links in doc comments.

Thanks for your patience with this review! I'm currently in WG14 meetings this week and out on vacation next week, so my review availability is a bit limited at the moment (sorry for that).

I think this is heading in the right direction, but there are some lifetime issues we need to figure out how to resolve. I pointed out a few such places, but I did not do an exhaustive search to catch them all.

clang/include/clang/Basic/Sarif.h
81–83

One thing that's worth calling out is that StringRef is non-owning which means that the argument passed to create the SarifArtifactLocation has to outlive the returned object to avoid dangling references. This makes the class a bit more dangerous to use because Twine or automatic std::string objects may cause lifetime concerns.

Should these classes be storing a std::string so that the memory is owned by SARIF?

117

Loc is already a SarifArtifactLocation, did you mean SarifArtifact by any chance?

(Note, this suggests to me we should mark the ctor's here as explicit.)

230–231
244–246

This comment looks incorrect to me.

368

It'd be good to explain why createRule() returns a value here and above.

379
clang/include/clang/Basic/SourceLocation.h
441–456 ↗(On Diff #385813)

Looks like unrelated formatting changes; feel free to submit these as an NFC change if you'd like, but the changes should be reverted from this patch for clarity.

clang/lib/Basic/Sarif.cpp
200

This seems like it'll be a use-after-free because the local std::string will be destroyed before the lifetime of the SarifArtifactLocation ends.

208–210

No worries! Our style is not... all that typical... so it can be hard to remember.

vaibhav.y updated this revision to Diff 390396.Nov 29 2021, 9:56 AM
vaibhav.y marked 6 inline comments as done.

Rebase on upstream/main:

  • [clangBasic] Format code
  • [clangBasic] Mark all constructors taking single values explicit
  • [clangBasic] Convert StringRef to std::string fields that own the data
  • [clangBasic] Fixup outdated comments
clang/include/clang/Basic/Sarif.h
81–83

Good point! Will change it to std::string to start with.

Some fields such as MimeType, RuleID would probably do better with SmallString, I haven't been able to find any good measurements on how the lengths of those two are distributed, can it be made into SmallString<N> in a future PR?

117

Agree, I've marked all constructors taking a single parameter as explicit.

244–246

Ack, fixed that as well. the right rationale for uint32_t is that it is the largest non-negative type that can be safely promoted to int64_t (which is what LLVM's json encoder supports)

clang/include/clang/Basic/SourceLocation.h
441–456 ↗(On Diff #385813)

Ack, these are definitely a result of a bad rebase.

clang/lib/Basic/Sarif.cpp
200

Will run it through a pass of asan & msan, is the best way to add: -fsanitize=memory -fsanitize=address to the test CMakeLists.txt & run them?

I've changed all strings to std::string, so this one should no longer be a problem but I wonder if there's any others I have missed as well.

Rename enum members

vaibhav.y marked 11 inline comments as done.Nov 30 2021, 9:18 PM

Mark completed comments as done

ping: This is ready for review now.

Thanks for your patience with the review as well!

ping: Requesting review

Thank you for your patience! I finally had the chance to go through this a bit more. I identified a bunch of tiny nits (the review feedback may look scary, but most should be trivial changes), but a few larger things about the design as well that are worth thinking about.

One thing that I'm still a bit worried about is validating the output document. The unit tests are a good start and the sort of thing we need for this functionality, but I'm also worried we won't find substantial design issues until we finally get SARIF results out of Clang or the static analyzer so we can see whether tools can actually *import* the SARIF we produce. I don't think we need in-tree tests for that sort of thing, but it'd definitely make me feel a lot more comfortable if we had external evidence that we're producing valid SARIF given that this is an exchange format. That said, I also don't want this to become a cumbersome patch for you to work on or for us to review, so I'm not certain what the best answer is here yet.

clang/include/clang/Basic/Sarif.h
47

Having thought about this a bit more, I think this line should be removed because it's within a header file, so all includes of this header file will be impacted and likely without knowing it. I'm very sorry for the churn, but I think this should go and the llvm:: prefixes should be brought back within the header file. Within the source file, it's fine to use the using.

81–83

Some fields such as MimeType, RuleID would probably do better with SmallString, I haven't been able to find any good measurements on how the lengths of those two are distributed, can it be made into SmallString<N> in a future PR?

Yeah, I think that can be done in a follow-up if we find a performance benefit from it.

113

Should we delete the default ctor?

163

One question this raises for me is whether we should be enforcing invariants from the SARIF spec as part of this interface or not. Currently, you can create a thread flow that has no importance or a rule without a name/id, etc. That means it's pretty easy to create SARIF that won't validate properly. One possible way to alleviate this would be for the create() methods/ctors to require these be set when creating the objects. However, I can imagine there will be times when that is awkward due to following the builder pattern with the interface. Another option would be to have some validation methods on each of the interfaces and the whole tree gets validated after construction, but this could have performance impacts.

What are your thoughts?

249
340
341

Once you use the default ctor, there's no way to associate language options with the document writer. Is it wise to expose this constructor? (If we didn't, then we could store the LangOptions as a const reference instead of making a copy in the other constructor. Given that we never mutate the options, I think that's a win.)

343
345
347
401
407
408
clang/lib/Basic/Sarif.cpp
55–57
73–75
114–121
200

Will run it through a pass of asan & msan, is the best way to add: -fsanitize=memory -fsanitize=address to the test CMakeLists.txt & run them?

Yup! The critical part will be test coverage -- code paths that aren't executed won't get issues reported with them.

220
236–237
249

(At this point, I'll stop commenting on these -- can you go through the patch and make sure that all comments have appropriate terminating punctuation?)

vaibhav.y updated this revision to Diff 414743.Mar 11 2022, 1:53 PM
vaibhav.y marked 15 inline comments as done.

Fixup comments
Mark clang::FullSourceRange as returning const & to its locs
rebase on upstream main

Herald added a project: Restricted Project. · View Herald TranscriptMar 11 2022, 1:53 PM
vaibhav.y added a comment.EditedMar 11 2022, 2:03 PM

Hi,

Apologies for the long delay! I was on a break to focus to other projects. I have some changes in mind such as:

  • Creating the SarifLog object to represent the top-level document. Currently we store this as a JSON object which ends up rather mucky. Having a separate structure can release internal state in SarifDocumentWriter. That way the writer will end up only dealing with the serialization of a SarifLog.

Regarding how to validate documents, I think having a SarifLog::validate() that checks everything underneath is the way to go. Ideally I'd prefer handling on the interface level, but I'm uncertain what would be a good approach. What do you think?

I'll comb through the previous comments again to make sure I'm not missing punctuations, will signal when this is ready for review again.

Thanks!

clang/include/clang/Basic/Sarif.h
113

Agreed, there's no reason for it to be callable. Will do the same for SarifArtifactLocation.

341

That's a good observation, I will delete this constructor and expose SarifDocumentWriter(const LangOptions &LangOpts) instead.

clang/lib/Basic/Sarif.cpp
249

Ack, sincere apologies again!

Hi,

Apologies for the long delay! I was on a break to focus to other projects.

Not a problem at all!

I have some changes in mind such as:

  • Creating the SarifLog object to represent the top-level document. Currently we store this as a JSON object which ends up rather mucky. Having a separate structure can release internal state in SarifDocumentWriter. That way the writer will end up only dealing with the serialization of a SarifLog.

That seems like an interesting idea (though I think it could be done in a follow-up).

Regarding how to validate documents, I think having a SarifLog::validate() that checks everything underneath is the way to go. Ideally I'd prefer handling on the interface level, but I'm uncertain what would be a good approach. What do you think?

I think that's a reasonable idea for assert builds to let us know if there are issues with the internal consistency of the data; we do something similar for IR verification in LLVM. But the kind of validating that will tell us whether this is successful is validating against another tool (the whole point to SARIF is to be an exchange format between tools, so self-testing only gets you so much information about how well the implementation works). However, there's no good way to automate that kind of testing in our test suite, so this is more of a request to try the output in tools that can consume SARIF to see if they're successful, and if they're not, see if we can come up with unit tests for those cases.

I'll comb through the previous comments again to make sure I'm not missing punctuations, will signal when this is ready for review again.

Thanks!

clang/lib/Basic/Sarif.cpp
249

No worries! These sort of nits are really easy to miss, it happens to me too. :-)

vaibhav.y updated this revision to Diff 434802.Jun 7 2022, 6:35 AM

Update tests to check serialization as well

  • SARIF text generated is validated externally against [Microsoft's online validator][1]

[1]: https://sarifweb.azurewebsites.net/Validation

@aaron.ballman Would it be possible that I add ::validate through a follow-up PR?

I'm currently checking the JSON output from the writer using Microsoft's online validator, and it is passing. Though it tends to complain about things outside of the spec (e.g. the spec doesn't constrain the toolComponent version to be numeric but the tool requires it to be).

vaibhav.y added a comment.EditedJun 7 2022, 11:10 AM

https://discourse.llvm.org/t/rfc-improving-clang-s-diagnostics/62584

There is an ongoing RFC similar to the work here, worth noting.

vaibhav.y added a subscriber: cjdb.Jun 9 2022, 6:12 AM
vaibhav.y updated this revision to Diff 436030.Jun 10 2022, 1:37 PM

Rebase on main branch from upstream git

vaibhav.y marked 2 inline comments as done.

Fix bug detected from ASAN run

Passes -fsanitize=address

Aside from some minor nits and the open question about validation, I think this is getting pretty close. I'm curious about the next steps with this though, given that there are no in-tree uses for it currently. You had mentioned you planned to work on an adapter so that we could eventually start to remove the existing SARIF implementation work at: https://github.com/llvm/llvm-project/blob/main/clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp. Are you still intending to work on that, or has the work from @cjdb changed your plans for the next steps? (I mostly am trying to figure out whether we should land this now because there's enough momentum that it will start being used "Real Soon Now" or whether we should wait for a bit until there's a patch to make use of this and then land the whole patch stack.)

clang/include/clang/Basic/Sarif.h
83

We don't typically use top-level const like this (same applies elsewhere) unless it's on a pointee/reference.

163

Are you still intending to add a validate() interface to take care of this, or are you still thinking about how to enforce invariants during construction (or some combination of the two)?

303–306

FWIW, this use of top-level const is fine (we do use it for data member variables).

vaibhav.y marked an inline comment as done.Jun 22 2022, 10:30 AM

Thanks, will push changes to address the comments soon.

As I understood from our discussion the work @cjdb has planned would create a new DiagnosticsConsumer, it can be started in parallel but would need the changes in D109701 to complete. I have other work planned for SARIF as well, some notes here: https://gist.github.com/envp/6abc3230dcc5043416c86aefb3d24419 (@cjdb plans to address the "BRIDGE" component)

For validation, I think having a hybrid approach is best here. As much as possible we should try to be correct by construction, but we certainly need to have validation before we serialize on the data.

My plan is to iterate on the interface as follows:

  1. To decompose SarifDocumentWriter, into: SarifLog & other builders, along with a SarifLogSerializer whose sole responsibility is to construct the json::Value. This should improve the number of properties that are correct by construction.
  2. Try to use this newer interface with https://github.com/llvm/llvm-project/blob/main/clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp, and incorporate any new features I think might be useful

Do you think it would it better to use the changes here in libStaticAnalyzer before they land & then iterate on it? I don't have a strong preference for either approach so I'd defer to your experience.

I'm also unfamiliar with the workflow for stacking patches in phabricator, is there documentation I can refer to for this? My guess is: I make a git branch whose base is that of D109701, and then arc diff D109701..OTHER_BRANCH to create the phabricator that would use these changes?

clang/include/clang/Basic/Sarif.h
163

Definitely! I plan to add that in a follow-up patch. The goal would be to have as much as possible be correct by construction (through small builders having a limited field set), but we'll still need a validate().

Discard top-level const specifier where target isn't pointee/ref

cjdb added a subscriber: abrahamcd.EditedJun 22 2022, 11:46 AM

I think this CL (which is quite large) might be worth just getting the functionality in, and deferring the in-tree usage to a second CL. That second CL probably should just lift the existing diagnostics so that they're in the message component if the SARIF flag is enabled: nothing fancy. I also expect this to be fairly non-intrusive with respect to the compiler, but I expect that the diagnostic engine will need some teaching here.

We're intending @abrahamcd to pilot proper true integration, by getting overload resolution failure diagnostics to be SARIF-operational. That can be done in parallel to the aforementioned CL 2, or at least in a staged pipeline after CL 2 is up for review.

vaibhav.y updated this revision to Diff 439153.Jun 22 2022, 2:08 PM

Fix formatting in Sarif.h

aaron.ballman accepted this revision.Jun 23 2022, 11:06 AM

Okay, thanks both for your perspective on this. This LGTM as-is and we can handle validation and integration in subsequent patches. Thank you for this, @vaibhav.y!

This revision is now accepted and ready to land.Jun 23 2022, 11:06 AM
vaibhav.y added a comment.EditedJun 23 2022, 12:37 PM

Thanks for your patience with the review as well!

Just noticed that I need to add a link to revision in the commit messages as well: (https://www.llvm.org/docs/Phabricator.html#committing-a-change)

I will update the commit messages, but I cannot commit to trunk.

Regarding further work on validation and integration, I couldn't find any documentation on how to work with stacked changes. Could you please direct me to some documentation for that?

Thanks for your patience with the review as well!

Likewise!

Just noticed that I need to add a link to revision in the commit messages as well: (https://www.llvm.org/docs/Phabricator.html#committing-a-change)

Yup, you'd link the commit message back to this review, like: Differential Revision: https://reviews.llvm.org/D109701

I will update the commit messages, but I cannot commit to the github repo.

Ah, thank you for letting me know. I can land the changes on your behalf. What name and email address would you like me to use for patch attribution? (I probably won't land it until tomorrow at this point though.)

Regarding further work on validation and integration, I couldn't find any documentation on how to work with stacked changes. Could you please direct me to some documentation for that?

You shouldn't need to use a patch stack once we land the changes in this review (because they'll then be on the main branch). As for documentation on stacked changes, I don't think we have any community specific documentation for it, so I'd recommend using your favorite search engine. If you still don't find much on it, we can discuss it more later.

Reword commit messages

  • Prefix [tag] specifying which components are affected
  • Append link to D109701 in commit message per commit message guidelines

I will update the commit messages, but I cannot commit to the github repo.

Ah, thank you for letting me know. I can land the changes on your behalf. What name and email address would you like me to use for patch attribution? (I probably won't land it until tomorrow at this point though.)

Please use:

  • Name: Vaibhav Yenamandra
  • email address: vyenamandra@bloomberg.net
This revision was landed with ongoing or failed builds.Jun 24 2022, 4:18 AM
This revision was automatically updated to reflect the committed changes.
aaron.ballman reopened this revision.Jun 24 2022, 4:36 AM

Unfortunately, I had to roll this back in 7a3918b540c30cc630aaae9124c67e5e4db123c2 because there's a layering violation. I've commented on it in the review.

clang/lib/Basic/Sarif.cpp
162

I didn't catch this during the review -- but this is a layering violation that caused link errors on some of the build bots. Lexer can call into Basic, but Basic cannot call into Lexer. So we'll need to find a different way to handle this.

This revision is now accepted and ready to land.Jun 24 2022, 4:36 AM
aaron.ballman requested changes to this revision.Jun 24 2022, 4:36 AM

Marking as needing changes so it's clear this shouldn't be re-landed yet.

This revision now requires changes to proceed.Jun 24 2022, 4:36 AM
vaibhav.y added inline comments.Jun 24 2022, 6:23 AM
clang/lib/Basic/Sarif.cpp
162

Would moving the code to Support, having it depend on Basic & Lex work?

vaibhav.y marked an inline comment as not done.Jun 24 2022, 6:23 AM
aaron.ballman added inline comments.Jun 24 2022, 8:44 AM
clang/lib/Basic/Sarif.cpp
162

I don't think so -- Support is supposed to be a pretty low-level interface; it currently only relies on LLVM's Support library. I think the layering is supposed to be: Support -> Basic -> Lex.

As I see it, there are a couple of options as to where this could live. It could live in the Frontend library, as that's where all the diagnostic consumer code in Clang lives. But that library might be a bit "heavy" to pull into other tools (maybe? I don't know). It could also live in AST -- that already links in Basic and Lex. But that feels like a somewhat random place for this to live as this has very little to do with the AST itself.

Another approach, which might be better, is to require the user of this interface to pass in the token length calculation themselves in the places where it's necessary. e.g., json::Object whatever(SourceLocation Start, SourceLocation End, unsigned EndLen) and then you can remove the reliance on the lexer entirely while keeping the interface in Basic. I'm not certain how obnoxious this suggestion is, but I think it's my preferred approach for the moment (but not a strongly held position yet). WDYT of this approach?

vaibhav.y updated this revision to Diff 440270.Jun 27 2022, 9:35 AM

Factor dependency on Lexer::MeasureTokenLength into externally provided functor

Introduces a type: TokenLengthMetric which measures the length of a token
starting at the given SLoc

vaibhav.y added inline comments.Jun 27 2022, 9:41 AM
clang/lib/Basic/Sarif.cpp
162

I think the approach to injecting the function is better here. I've tried to make the smallest change possiblew with passing in a function whose interface is almost identical to Lexer::MeasureTokenLength. The intent was to hint at this being the "canonical metric" for token lengths (with an example in the tests for the same).

I tried passing start, end locs but couldn't find a strong use case yet since end would likely always be: Lexer::getLocForEndOfToken(start, 0)

vaibhav.y updated this revision to Diff 440279.Jun 27 2022, 9:47 AM

Discard unused includes

aaron.ballman added inline comments.Jun 27 2022, 11:22 AM
clang/include/clang/Basic/Sarif.h
297–298

I worry about the performance aspects of using a callback for this. Calls across DSO boundaries can be slower (due to having to call through a thunk), and it necessitates calling back to the user to calculate information that the user could simply pass in directly. That's on top of std::function already being pretty heavy-weight.

clang/lib/Basic/Sarif.cpp
162

I'm not convinced that the less obtrusive change is a good design in this case. But I also agree that we should not use start/end *locations* either. SourceLocation traditionally points to the *start* of a token, so it would be super easy to get the end location wrong by forgetting to pass the location for the end of the token.

My suggestion was to continue to pass the start of the starting token, the start of the ending token, and the length of the ending token. With the callback approach, you have to call through the callback to eventually call Lexer::MeasureTokenLength(); with the direct approach, you skip needing to call through a callback (which means at least one less function call on every source location operation).

vaibhav.y added inline comments.Jun 27 2022, 11:59 AM
clang/lib/Basic/Sarif.cpp
162

Ah, I think I misunderstood your initial suggestion (json::Object whatever(SourceLocation Start, SourceLocation End, unsigned EndLen)) seemed like a function call to me, when it seems the suggested change was to pass in an object? Apologies, will fix that up.

vaibhav.y marked an inline comment as not done.Jun 27 2022, 11:59 AM

Comment isn't done.

aaron.ballman added inline comments.Jun 27 2022, 12:24 PM
clang/lib/Basic/Sarif.cpp
162

Sorry for the confusion! Just to make sure we're on the same page -- my suggestion was to change the function interfaces like SarficDocumentWriter::createPhysicalLocation() so that they would take an additional unsigned EndLen parameter.

However, now that I dig around a bit, it seems like CharSourceRange is what you'd want to use there -- then you can assert that what you're given is a char range and not a token range. So you won't need the unsigned EndLen parameter after all!

vaibhav.y added inline comments.Jun 27 2022, 12:45 PM
clang/lib/Basic/Sarif.cpp
162

Interesting!

Asking for my understanding: If a CharSourceRange is a valid character range, then the End SLoc points to the last character in the range (even if it is mid token)? (Unlike slocs where it the first character of the last token).

vaibhav.y marked an inline comment as not done.Jun 27 2022, 12:59 PM
vaibhav.y updated this revision to Diff 440371.EditedJun 27 2022, 1:43 PM

Use CharSourceRange instead of FullSourceRange so we no longer need to compute
the length of the last token. This should already be encoded in the end location
of the CharSourceRange by the caller

TODO(@vaibhav.y): Once accepted, drop the commit that introduces: clang::FullSourceRange

vaibhav.y updated this revision to Diff 440374.Jun 27 2022, 1:47 PM

Discard include: clang/Lex/Lexer.h

Thanks, I think this is heading in the right direction!

clang/include/clang/Basic/Sarif.h
168

Should we assert this source range is not a token range?

281

In an asserts build, should we additionally have a loop to assert that each location is a char range rather than a token range?

clang/lib/Basic/Sarif.cpp
162

Your understanding is correct.

vaibhav.y added inline comments.Jun 29 2022, 11:47 AM
clang/include/clang/Basic/Sarif.h
168

I don't have a strong opinion here (since these are validated downstream in createPhysicalLocation) but it makes sense to be defensive & assert early.

I'll preserve the downstream one as well in case a new type gets added that feeds data into createPhysicalLocation as well.

281

Will do, I had the asserts in createPhysicalLocation initially. Adding them at the site of creation makes sense as well.

Assert that CharSourceRanges passed to Threadflow, SarifResult are
character Ranges.

aaron.ballman accepted this revision.Jun 30 2022, 10:12 AM

LGTM! Thank you for the fixes to this! I'll land this again on your behalf with the same information as before.

This revision is now accepted and ready to land.Jun 30 2022, 10:12 AM
This revision was landed with ongoing or failed builds.Jun 30 2022, 10:26 AM
This revision was automatically updated to reflect the committed changes.

I had to roll it back because of failures with test bots:

https://lab.llvm.org/buildbot/#/builders/91/builds/11328

So this was reverted in b46ad1b5be694feefabd4c6cd112cbbd04a7b3a7, can you take a look when you get the chance?

aaron.ballman reopened this revision.Jun 30 2022, 10:41 AM
This revision is now accepted and ready to land.Jun 30 2022, 10:41 AM
vaibhav.y added a comment.EditedJun 30 2022, 10:49 AM

I had to roll it back because of failures with test bots:

https://lab.llvm.org/buildbot/#/builders/91/builds/11328

So this was reverted in b46ad1b5be694feefabd4c6cd112cbbd04a7b3a7, can you take a look when you get the chance?

Odd! I'll try to reproduce that at the earliest. check-clang-unit was passing on my local machine last I checked. I'll try to build this on a RHEL system to be closer to what the buildbot reports.

Apologies for having to revert again!

vaibhav.y updated this revision to Diff 443654.EditedJul 11 2022, 8:30 AM

Discard most likely culprit in test code causing unexpected crash.

@aaron.ballman I was unable to reproduce the issue on my end using the buildbot instructions and ASAN, UBSAN.

Is it possible for you to trigger a pre-merge check on the LLVM cluster?

I have suspicions that it was the SarifResult && type in the test so I changed it to a const SarifResult &.

I've tried running it on a RHEL 7, Darwin on my end.

Discard most likely culprit in test code causing unexpected crash.

@aaron.ballman I was unable to reproduce the issue on my end using the buildbot instructions and ASAN, UBSAN.

Is it possible for you to trigger a pre-merge check on the LLVM cluster?

Unfortunately, there isn't.

I have suspicions that it was the SarifResult && type in the test so I changed it to a const SarifResult &.

I've tried running it on a RHEL 7, Darwin on my end.

If you think you've got it fixed, I think the best we can do is to re-commit and watch the bots to see how they react. I'll commit again for you and watch them.

I have suspicions that it was the SarifResult && type in the test so I changed it to a const SarifResult &.

I've tried running it on a RHEL 7, Darwin on my end.

If you think you've got it fixed, I think the best we can do is to re-commit and watch the bots to see how they react. I'll commit again for you and watch them.

Thank you! Let us try that.

This revision was landed with ongoing or failed builds.Jul 11 2022, 9:19 AM
This revision was automatically updated to reflect the committed changes.
aaron.ballman reopened this revision.Jul 11 2022, 9:31 AM

Unfortunately, it still seems to be causing failures (I had to revert again):

https://lab.llvm.org/buildbot/#/builders/91/builds/11840

It looks to be the same failure as before (https://lab.llvm.org/buildbot/#/builders/91/builds/11328). :-(

This revision is now accepted and ready to land.Jul 11 2022, 9:31 AM
vaibhav.y added a comment.EditedJul 11 2022, 9:44 AM

Unfortunately, it still seems to be causing failures (I had to revert again):

https://lab.llvm.org/buildbot/#/builders/91/builds/11840

It looks to be the same failure as before (https://lab.llvm.org/buildbot/#/builders/91/builds/11328). :-(

Thanks, this seems to be reproducible. Perhaps there's something special about my environment making it work. I'll try to pare down more (possibly try to build inside a container).

The buildbot properties say its Linux aurora is there an official container / build spec I can use to mimic the environment?

Unfortunately, it still seems to be causing failures (I had to revert again):

https://lab.llvm.org/buildbot/#/builders/91/builds/11840

It looks to be the same failure as before (https://lab.llvm.org/buildbot/#/builders/91/builds/11328). :-(

Thanks, this seems to be reproducible. Perhaps there's something special about my environment making it work. I'll try to pare down more (possibly try to build inside a container).

Hopefully!

The buildbot properties say its Linux aurora is there an official container / build spec I can use to mimic the environment?

I don't know that there is such a thing, unfortunately. (Many of the bots are bots hosted by various different companies with different views on access to servers, I'd imagine.)

Hi! I'm interning with @cjdb and @denik this summer and I was working on adding a -fdiagnostics-format=sarif option to start off my project, but I just found that a previous abandoned version of this change (D109697) was intending to add it. Seeing as the flag is no longer included in this version of the change, is it okay for me to go on and add it myself, or are you still planning on adding it here? Thanks!

Hi! I'm interning with @cjdb and @denik this summer and I was working on adding a -fdiagnostics-format=sarif option to start off my project, but I just found that a previous abandoned version of this change (D109697) was intending to add it. Seeing as the flag is no longer included in this version of the change, is it okay for me to go on and add it myself, or are you still planning on adding it here? Thanks!

Sure, feel free to use D109697 as you see fit!

Hi! I'm interning with @cjdb and @denik this summer and I was working on adding a -fdiagnostics-format=sarif option to start off my project, but I just found that a previous abandoned version of this change (D109697) was intending to add it. Seeing as the flag is no longer included in this version of the change, is it okay for me to go on and add it myself, or are you still planning on adding it here? Thanks!

Sure, feel free to use D109697 as you see fit!

Great, thank you!

vaibhav.y added a comment.EditedJul 14 2022, 11:40 AM

@aaron.ballman

The culprit turned out to be the difference in release flags on the build server vs my environment. I had unfortunately run the configuration command once in Debug mode, and hadn't re-configured. Not a bright moment :)

The ASSERT_DEATH tests that I had written weren't gated by NDEBUG, GTEST_HAS_DEATH_TEST (other unit tests use some combination two). This was causing them to pass on my machine but fail pre-merge (which is RelWithDebInfo)

I will gate the tests similar to what https://github.com/llvm/llvm-project/blob/main/clang/unittests/Serialization/InMemoryModuleCacheTest.cpp#L48-L52 does, but force a skip instead.

Running another clean build on my end to ensure I have the right culprit. Thank you for your patience!

vaibhav.y updated this revision to Diff 444764.EditedJul 14 2022, 12:26 PM

Gate death tests on NDEBUG and available of GTEST_HAS_DEATH_TEST

This should fix recent post-merge failures

vaibhav.y edited the summary of this revision. (Show Details)Jul 14 2022, 12:38 PM
vaibhav.y edited the summary of this revision. (Show Details)Jul 14 2022, 12:49 PM
vaibhav.y updated this revision to Diff 444960.Jul 15 2022, 6:19 AM

Undo test case renames

aaron.ballman accepted this revision.Jul 15 2022, 6:38 AM

LGTM assuming precommit CI comes back happy with it, thank you! I'll land it once I see things are green.

This revision was landed with ongoing or failed builds.Jul 18 2022, 5:38 AM
This revision was automatically updated to reflect the committed changes.