)]}'
{
  "commit": "22ac2d9b258c0769d1a989fa8ad81521ca7777e5",
  "tree": "efbec2c36b84d5067ada1c24365424decc9b6145",
  "parents": [
    "fc04cb217d79b3a1edca7f846547934ca04d417d"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Fri Jul 20 10:07:56 2018 -0400"
  },
  "committer": {
    "name": "Adam Langley",
    "email": "agl@google.com",
    "time": "Mon Jul 23 19:07:41 2018 +0000"
  },
  "message": "Fail the build if MSan is built with assembly.\n\nMSan works by instrumenting memory accesses in the compiler. Accesses from\nuninstrumented code, such as assembly, are invisible to it. MSan will\nincorrectly report reads from assembly-initialized memory as uninitialized.\n\nTo avoid confusing downstream consumers with false positives, catch this at\ncompile-time with a more useful error.\n\nUpdate-Note: BoringSSL with MSan and assembly doesn\u0027t work, but now rather than\ncrashing at runtime, it will fail to build altogether. It\u0027s possible someone\nwas building BoringSSL with MSan and either not running it at all or just not\nexercising the codepaths that break.\n\nBug: 252\nChange-Id: I0c8b0fa3c2d1e584b3f40d532a668a8c9be06cb7\nReviewed-on: https://boringssl-review.googlesource.com/29928\nReviewed-by: Adam Langley \u003cagl@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "c4e2e517772bda6390ad18fb45f0d9141e1e75bc",
      "old_mode": 33188,
      "old_path": "crypto/internal.h",
      "new_id": "3f0ff6d155e2541832d1710ef682cc13a59f9a96",
      "new_mode": 33188,
      "new_path": "crypto/internal.h"
    }
  ]
}