1251936 - Stand up Windows x86 debug static analysis builds

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[(no longer active)]

I did this in bug 1015018 for Mac.  Time to do it for Windows!

Comment 1

[(no longer active)]

Attachment: Part 1: Add a mozconfig for Windows x86 static analysis builds

Comment 2

[(no longer active)]

Attachment: Part 2: Add a mozharness config script for 32-bit Windows static analysis builds

Comment 3

[(no longer active)]

Attachment: Part 3: Add buildbot configs for Windows x86 static analysis buillds

Comment 4

[(no longer active)]

Jordan, please note that these are mostly untested stuff I copied based on the existing configs, since as far as I remember there is no way to test them on try without committing the buildbot-configs and ash-mozharness changes.  Once we do that and the builds turn green on try, I can move them to the default set for m-c.

Comment 5

[Jordan Lund (:jlund)]

Comment on attachment 8724548 [details] [diff] [review]
Part 3: Add buildbot configs for Windows x86 static analysis buillds

Review of attachment 8724548 [details] [diff] [review]:
-----------------------------------------------------------------

so while this patch will do exactly what you need and it lgtm, we can add an intermediate step in to test this only on try without risk closing inbound/central.

to add this to try and have it run only when you explicitly call it in try commit msg, could you take this example and apply it your win32-st-an-debug needs before you land this patch: https://hg.mozilla.org/build/buildbot-configs/diff/34925337358e/mozilla/config.py

I throw in tips on how to do that in in-line comments below

::: mozilla/config.py
@@ +71,5 @@
>          'linux64-av': {},
>          'macosx64-debug': {},
>          'macosx64-st-an-debug': {},
>          'win32-debug': {},
> +        'win32-st-an-debug': {},

remove this line (as it adds it across all branches by default)

@@ +1513,5 @@
>              'dep_signing_servers': 'dep-signing',
>              'tooltool_manifest_src': 'browser/config/tooltool-manifests/win32/releng.manifest',
>              'tooltool_script': ['python', '/c/mozilla-build/tooltool.py'],
>          },
> +        'win32-st-an-debug': {

keep this

@@ +2889,5 @@
>  BRANCHES['try']['platforms']['linux64-sh-haz']['slaves'] = TRY_SLAVES['mock']
>  BRANCHES['try']['platforms']['linux64-br-haz']['slaves'] = TRY_SLAVES['mock']
>  BRANCHES['try']['platforms']['linux64-cc']['slaves'] = TRY_SLAVES['mock']
>  BRANCHES['try']['platforms']['win32-debug']['slaves'] = TRY_SLAVES['win64-rev2']
> +BRANCHES['try']['platforms']['win32-st-an-debug']['slaves'] = TRY_SLAVES['win64-rev2']

keep this

@@ +3013,5 @@
>          del branch['platforms']['linux64-st-an-debug']
>      if 'macosx64-st-an-debug' in branch['platforms']:
>          del branch['platforms']['macosx64-st-an-debug']
> +    if 'win32-st-an-debug' in branch['platforms']:
> +        del branch['platforms']['win32-st-an-debug']

remove this for now.

add: https://hg.mozilla.org/build/buildbot-configs/diff/34925337358e/mozilla/config.py#l1.129

Comment 6

[Jordan Lund (:jlund)]

Comment on attachment 8724546 [details] [diff] [review]
Part 1: Add a mozconfig for Windows x86 static analysis builds

Review of attachment 8724546 [details] [diff] [review]:
-----------------------------------------------------------------

I'm probably not the best to review the mozconfig. if it works for you, it works for me but if you want reassurance, I'd r? someone from #build

Comment 7

[Jordan Lund (:jlund)]

Comment on attachment 8724547 [details] [diff] [review]
Part 2: Add a mozharness config script for 32-bit Windows static analysis builds

Review of attachment 8724547 [details] [diff] [review]:
-----------------------------------------------------------------

patch looks good but mozharness lives in tree now: http://hg.mozilla.org/mozilla-central/file/9da51cb4974e/testing/mozharness/README.txt

this repo isn't used anywhere

Comment 8

[(no longer active)]

(In reply to Jordan Lund (:jlund) from comment #7)
> Comment on attachment 8724547 [details] [diff] [review]
> Part 2: Add a mozharness config script for 32-bit Windows static analysis
> builds
> 
> Review of attachment 8724547 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> patch looks good but mozharness lives in tree now:
> http://hg.mozilla.org/mozilla-central/file/9da51cb4974e/testing/mozharness/
> README.txt
> 
> this repo isn't used anywhere

Oh fun!  Thanks, I'll rework this patch in-tree and will address your comments on the other patch.

Comment 9

[(no longer active)]

Attachment: Part 3: Add buildbot configs for Windows x86 static analysis buillds

Comment 10

[(no longer active)]

Attachment: Part 2: Add a mozharness config script for 32-bit Windows static analysis builds

Comment 11

[Jordan Lund (:jlund)]

Comment on attachment 8726794 [details] [diff] [review]
Part 3: Add buildbot configs for Windows x86 static analysis buillds

Review of attachment 8726794 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm with one line addition. see comment below

::: mozilla/config.py
@@ +1512,5 @@
>              'dep_signing_servers': 'dep-signing',
>              'tooltool_manifest_src': 'browser/config/tooltool-manifests/win32/releng.manifest',
>              'tooltool_script': ['python', '/c/mozilla-build/tooltool.py'],
>          },
> +        'win32-st-an-debug': {

I forgot, can you add the following to this dict:

'try_by_default': False,

Comment 12

[Jordan Lund (:jlund)]

Comment on attachment 8726796 [details] [diff] [review]
Part 2: Add a mozharness config script for 32-bit Windows static analysis builds

Review of attachment 8726796 [details] [diff] [review]:
-----------------------------------------------------------------

looks sane to me :)

Comment 13

[(no longer active)]

Thanks for the reviews!

Should I wait for a reconfig after landing part 3?

Comment 14

[(no longer active)]

https://hg.mozilla.org/build/buildbot-configs/rev/ae056e1b3ad7

Comment 15

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/59538ea54b42
https://hg.mozilla.org/integration/mozilla-inbound/rev/54b69944747b

Comment 16

[Jordan Lund (:jlund)]

(In reply to :Ehsan Akhgari from comment #13)
> Thanks for the reviews!
> 
> Should I wait for a reconfig after landing part 3?

yep. you'll need to wait till this is on production (usually happens once every two days):

> https://hg.mozilla.org/build/buildbot-configs/rev/ae056e1b3ad7

it will take at most 1.5h for buildbot masters to reconfig after it merges to prod. after that, you are good to try on try

Comment 17

[Jordan Lund (:jlund)]

(In reply to Jordan Lund (:jlund) from comment #16)
> (In reply to :Ehsan Akhgari from comment #13)
> > Thanks for the reviews!
> > 
> > Should I wait for a reconfig after landing part 3?
> 

I triggered a reconfig and thought about this. you can try this on try from now on wards: http://hg.mozilla.org/build/buildbot-configs/rev/82435f4d7281

Comment 18

[(no longer active)]

Thanks, Jordan!

I tried pushing this to try: <https://treeherder.mozilla.org/#/jobs?repo=try&revision=1de8fd0f726f>.  The build fails with:

13:29:08     INFO - Using in-tree mozconfig
13:29:08     INFO - Reading from file c:\builds\moz2_slave\try-w32-st-an-d-00000000000000\build\src\browser/config/mozconfigs/win32/debug-static-analysis
13:29:08    FATAL - unable to open c:\builds\moz2_slave\try-w32-st-an-d-00000000000000\build\src\browser/config/mozconfigs/win32/debug-static-analysis: No such file or directory

It looks like this error is coming from <https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/mozharness/mozilla/building/buildbase.py#1107>, but I'm not sure why.

This is from a normal successful Windows x86 debug build:

13:33:55     INFO - Using in-tree mozconfig
13:33:55     INFO - Reading from file c:\builds\moz2_slave\try-w32-d-00000000000000000000\build\src\browser/config/mozconfigs/win32/debug
13:33:56     INFO - Contents:
...

There is no difference that I can think of which might be causing this.  Can you think of what's happening here?

Comment 19

[(no longer active)]

Note that I pushed another experiment <https://treeherder.mozilla.org/#/jobs?repo=try&revision=914b8ecbe7a2> where I changed "debug-static-analysis" to "debug" in the name of the mozconfig, and the same error occurred.  It seems like c:\builds\moz2_slave\try-w32-st-an-d-00000000000000\build\src either doesn't exist or doesn't point to a valid source directory.  This might be caused by the "checkout-sources" step missing from testing/mozharness/configs/builds/releng_sub_windows_configs/32_stat_and_debug.py.  Pushing another try job to see if that's the problem: <https://treeherder.mozilla.org/#/jobs?repo=try&revision=11c78ab80409>

Comment 20

[(no longer active)]

Looks like that was the issue!

Comment 21

[Jordan Lund (:jlund)]

yeah sorry, 'checkout-sources' clones gecko. I missed that in the review

Comment 22

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/59538ea54b42
https://hg.mozilla.org/mozilla-central/rev/54b69944747b

Comment 23

[(no longer active)]

Attachment: Part 4: Include checkout-sources in the mozharness config for Win32 static analysis builds

Comment 24

[(no longer active)]

Attachment: Part 5: Include the rustc toolchain in the tooltool manifest for Win32 static analysis builds

Comment 25

[(no longer active)]

Attachment: Part 6: Update clang-cl to LLVM r262971

Comment 26

[Jordan Lund (:jlund)]

Comment on attachment 8728162 [details] [diff] [review]
Part 4: Include checkout-sources in the mozharness config for Win32 static analysis builds

Review of attachment 8728162 [details] [diff] [review]:
-----------------------------------------------------------------

sorry for the delay. was dealing with bustage all day yesterday.

Comment 27

[Jordan Lund (:jlund)]

Comment on attachment 8728163 [details] [diff] [review]
Part 5: Include the rustc toolchain in the tooltool manifest for Win32 static analysis builds

Review of attachment 8728163 [details] [diff] [review]:
-----------------------------------------------------------------

lgtm

Comment 28

[(no longer active)]

No worries, thanks for the reviews so far!

Comment 29

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3624170aa734
https://hg.mozilla.org/integration/mozilla-inbound/rev/abbfaaa02be9
https://hg.mozilla.org/integration/mozilla-inbound/rev/1f0cba8fdb13

Comment 30

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3624170aa734
https://hg.mozilla.org/mozilla-central/rev/abbfaaa02be9
https://hg.mozilla.org/mozilla-central/rev/1f0cba8fdb13

Comment 31

[Ting-Yu Chou [:ting] (away)]

I don't see this on treeherder, is it disabled/hidden or I missed anything?

Comment 32

[Nathan Froyd [:froydnj]]

(In reply to Ting-Yu Chou [:ting] from comment #31)
> I don't see this on treeherder, is it disabled/hidden or I missed anything?

I believe this is only available on try at the moment.

Comment 33

[Ting-Yu Chou [:ting] (away)]

I used "try: -b do -p win32-st-an -u none -t none" to run the task [1], and the results are all (3/3) busted:

 01:00:55     INFO - Calling ['c:\\mozilla-build\\python27\\python.exe', 'mach', '--log-no-times', 'build', '-v'] with output_timeout 4800
 01:00:56     INFO -  Error loading mozconfig: c:/builds/moz2_slave/try-w32-st-an-d-00000000000000/build/src/.mozconfig
 01:00:56     INFO -  Evaluation of your mozconfig exited with an error. This could be triggered
 01:00:56     INFO -  by a command inside your mozconfig failing. Please change your mozconfig
 01:00:56     INFO -  to not error and/or to catch errors in executed commands.
 01:00:56     INFO -  mozconfig output:
 01:00:56     INFO -  ------BEGIN_MK_OPTION
 01:00:56     INFO -  AUTOCLOBBER=1
 ...
 01:00:56     INFO -  --enable-clang-plugin
 01:00:56     INFO -  ------END_AC_OPTION
 01:00:56     INFO -  c:/builds/moz2_slave/try-w32-st-an-d-00000000000000/build/src/build/win32/mozconfig.vs2015-win64: line 6: cd: /c/builds/moz2_slave/try-w32-st-an-d-00000000000000/build/src/vs2015u3: No such file or directory
 01:00:56    ERROR - Return code: 1
 01:00:56  WARNING - setting return code to 2
 01:00:56    FATAL - 'mach build' did not run successfully. Please check log for errors.
 01:00:56    FATAL - Running post_fatal callback...
 01:00:56    FATAL - Exiting -1 

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=ddb75313fff8

Comment 34

[Ting-Yu Chou [:ting] (away)]

It seems that browser/config/tooltool-manifests/win32/clang.manifest needs to include vs2015u3. Try again: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4bfe72e4a66f

Comment 35

[Ting-Yu Chou [:ting] (away)]

(In reply to Ting-Yu Chou [:ting] from comment #34)
> It seems that browser/config/tooltool-manifests/win32/clang.manifest needs
> to include vs2015u3. Try again:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=4bfe72e4a66f

Added cargo to the manifest as well, but fails building clang-plugin.dll with unresolved external symbols, I guess it's because of this:

18:26:22     INFO -  clangASTMatchers.lib(ASTMatchersInternal.cpp.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1800' doesn't match value '1900' in clang-plugin.obj
18:26:22 INFO - clangASTMatchers.lib(ASTMatchFinder.cpp.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1800' doesn't match value '1900' in clang-plugin.obj 

[1] https://treeherder.mozilla.org/logviewer.html#?job_id=30048095&repo=try#L5242-L5487

Comment 36

[Ting-Yu Chou [:ting] (away)]

We need a newer clang build on x86 for vs2015u3, specifically r270458 needs to be included. I assume bug 1306650 patch part 13 [1] would get us a new build on https://api.pub.build.mozilla.org/tooltool/, which later I can update browser/config/tooltool-manifests/win32/clang.manifest for the newer version.

[1] https://hg.mozilla.org/mozilla-central/rev/402494fd3465

Comment 37

[Ting-Yu Chou [:ting] (away)]

(In reply to Ting-Yu Chou [:ting] from comment #36)
> to be included. I assume bug 1306650 patch part 13 [1] would get us a new
> build on https://api.pub.build.mozilla.org/tooltool/, which later I can

Unfortunately this does not happen and I don't have the token tooltool.upload.public in https://api.pub.build.mozilla.org for uploading.

Comment 38

[Ting-Yu Chou [:ting] (away)]

How could I get the permission of tooltool.upload.public in https://api.pub.build.mozilla.org? If I can't, should I follow bug 1042132 comment 1 for uploading?

Comment 39

[Chris AtLee [:catlee]]

Ehsan / Nathan - can you vouch that Ting-Yu should have tooltool upload permissions?

Comment 40

[Nathan Froyd [:froydnj]]

I vouch for Ting-Yu.  (Ehsan is on PTO for a while.)

Comment 41

[Nathan Froyd [:froydnj]]

I was attempting to wait to do this until m-c was buildable by default with clang-cl for 32-bit; https://reviews.llvm.org/D26335 is the last blocker that I know of, although I think bug 1313280 might break things is easily fixable ways.  64-bit requires a few additional changes to m-c.

Once that's done, I was going stand up ordinary clang-cl (no static analysis) builds in taskcluster to ensure that m-c remains buildable with clang-cl; the buildbot stuff might work, but I think releng would be much happier if the buildbot code went away sooner rather than later, and it's much, much easier to work with the taskcluster infrastructure than buildbot.  Then that build can be converted to a static analysis build...there are probably a number of things to fix in our Windows-specific code with respect to our static analysis tools.

Comment 42

[Justin Wood (:Callek)]

(In reply to Ting-Yu Chou [:ting] from comment #38)
> How could I get the permission of tooltool.upload.public in
> https://api.pub.build.mozilla.org? If I can't, should I follow bug 1042132
> comment 1 for uploading?

Per nathan's vouch, I've added `tchou@m.c` to the permissions group. If instead this is your @gmail or some other ldap, feel free to n-i me and I'll adjust.

You'll need to logout and log in again on relengapi in order to be able to get a token that has the upload permission.

Comment 43

[Ting-Yu Chou [:ting] (away)]

I failed uploading the files with this message, retried 5 times but not working and I found there're now 5 the same batches in https://api.pub.build.mozilla.org/tooltool/...

$ python tooltool.py upload --authentication-file=.tooltool-token --message "Bug 1251936 - New Windows clang for x86
/x64, r283955"
INFO - clang64.tar.bz2: starting upload
INFO - clang32.tar.bz2: starting upload
ERROR - clang32.tar.bz2: failed
Traceback (most recent call last):
  File "tooltool.py", line 791, in _s3_upload
    (resp.status, resp.reason, resp_body))
RuntimeError: Non-200 return from AWS: 400 Bad Request
<?xml version="1.0" encoding="UTF-8"?><Error><Code>RequestTimeout</Code><Message>Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed.</Message><RequestId>20E806D572EAA723</RequestId><HostId>tIFXayLqhUbP7PZ17XSaKW+PyUMNFBtCbGiUb3QFT37phf7xQmSjo3gvDosD7FvYo1i7PR+jDB8yxOEfus9fuI51i/5OM3oV</HostId></Error>
ERROR - clang64.tar.bz2: failed
Traceback (most recent call last):
  File "tooltool.py", line 791, in _s3_upload
    (resp.status, resp.reason, resp_body))
RuntimeError: Non-200 return from AWS: 400 Bad Request
<?xml version="1.0" encoding="UTF-8"?><Error><Code>RequestTimeout</Code><Message>Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed.</Message><RequestId>CF7F00947BB490F2</RequestId><HostId>SpjvbaWXoeMW/vJTcNgMJ9p7gA9LAwkWvxq9P4sBzphpEHlehyytIg3ciDO8J7OhrHm8rijubqEDhVyMe9n1Y1QUCCSKktBh</HostId></Error>

Comment 44

[Justin Wood (:Callek)]

That sounds like a suspicious error message. Let me flag our current maintainer of this code for an idea.

Comment 45

[Dustin J. Mitchell [:dustin] (he/him)]

That error is from Amazon S3.  I wonder if you have some kind of network issue between you and the Amazon S3 servers?  Perhaps a tcpdump of the transaction could help to determine that.  I don't know what S3's request timeout is, but I'd guess it's not less than 30 seconds..

Comment 46

[Nathan Froyd [:froydnj]]

(In reply to Ting-Yu Chou [:ting] from comment #43)
> $ python tooltool.py upload --authentication-file=.tooltool-token --message
> "Bug 1251936 - New Windows clang for x86
> /x64, r283955"

Did you build that on your local machine or through the taskcluster stuff?  It would be better to do the latter.

Comment 47

[Ting-Yu Chou [:ting] (away)]

OK, I'll try to build it by taskcluster. But will there be any differences from taskcluster one? I built it locally with command:

  ./mach python build/build-clang/build-clang.py -c build/build-clang/clang-static-analysis-win32.json

Comment 48

[Nathan Froyd [:froydnj]]

(In reply to Ting-Yu Chou [:ting] from comment #47)
> OK, I'll try to build it by taskcluster. But will there be any differences
> from taskcluster one? I built it locally with command:
> 
>   ./mach python build/build-clang/build-clang.py -c
> build/build-clang/clang-static-analysis-win32.json

You can push patches to try with:

-b o -p none -j win32-clang-cl -t none -u none

Comment 49

[Ting-Yu Chou [:ting] (away)]

The build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ffbd5f48c967a0cf774decaea4cb6c4d8c258262. However I still failed uploading to tooltool, filed bug 1316249 for that so not spamming here.

Comment 50

[Rok Garbas [:garbas]]

i guess i'm slowly taking over ( https://api.pub.build.mozilla.org ) but i'm yet to dig into tooltool. i think :dustin: might have better understanding what is happening, but i'll keep my eye on bug 1316249

Comment 51

[Ting-Yu Chou [:ting] (away)]

Once bug 1321453 is fixed, we should be able to stand up Windows 32/64 bit opt/debug static analysis checking builds.

I'll just add new patches here as this is not closed, let me know if I should file a new one.

Comment 52

[Ting-Yu Chou [:ting] (away)]

(In reply to Ting-Yu Chou [:ting] from comment #51)
> Once bug 1321453 is fixed, we should be able to stand up Windows 32/64 bit
> opt/debug static analysis checking builds.

Nathan, are you working on this?

Comment 53

[Nathan Froyd [:froydnj]]

(In reply to Ting-Yu Chou [:ting] from comment #52)
> (In reply to Ting-Yu Chou [:ting] from comment #51)
> > Once bug 1321453 is fixed, we should be able to stand up Windows 32/64 bit
> > opt/debug static analysis checking builds.
> 
> Nathan, are you working on this?

Sure, I can do this.  Our clang-cl builds are now building without -fallback, so once we fix all the static analysis errors, I think we can just add static analysis into those builds.

Comment 54

[(no longer active)]

(In reply to Nathan Froyd [:froydnj] from comment #53)
> (In reply to Ting-Yu Chou [:ting] from comment #52)
> > (In reply to Ting-Yu Chou [:ting] from comment #51)
> > > Once bug 1321453 is fixed, we should be able to stand up Windows 32/64 bit
> > > opt/debug static analysis checking builds.
> > 
> > Nathan, are you working on this?
> 
> Sure, I can do this.  Our clang-cl builds are now building without
> -fallback, so once we fix all the static analysis errors, I think we can
> just add static analysis into those builds.

Agreed.  I also think we should rename them to show up as "S" jobs.  Thankfully with TaskCluster that's a simple patch to taskcluster/ci/build/windows.yml :-)

Comment 55

[Ting-Yu Chou [:ting] (away)]

Bug 1321453 is now fixed.  As the holidays is around the corner, let me know if you want me to take it, we have only two days off on 12/26 and 1/2 in Taipei.

Comment 56

[Nathan Froyd [:froydnj]]

Attachment: enable static analysis on clang-cl builds

I am ambivalent about renaming them to 'S' on taskcluster; let me know if you
feel strongly about that (and perhaps updating the taskcluster description).

Comment 57

[(Away)]

What I like about Ehsan's "S" suggestion is that "you broke the static analysis build" seems more likely to be fixed than "you broke this alternative compiler thing".

Comment 58

[(no longer active)]

Comment on attachment 8821591 [details] [diff] [review]
enable static analysis on clang-cl builds

Review of attachment 8821591 [details] [diff] [review]:
-----------------------------------------------------------------

I do think we should rename the jobs mostly for the reason dmajor mentioned.  I'll submit a patch for that in a minute.  :-)

Comment 59

[(no longer active)]

Attachment: Rename the Windows clang-cl builds to static analysis builds

Comment 60

[(no longer active)]

Also I think we should write to dev-platform about this.

Comment 61

[Nathan Froyd [:froydnj]]

Comment on attachment 8821602 [details] [diff] [review]
Rename the Windows clang-cl builds to static analysis builds

Review of attachment 8821602 [details] [diff] [review]:
-----------------------------------------------------------------

I was going to write to dev-platform about these builds!  Great minds think alike.

Comment 62

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5ff2c66f4020
enable static analysis on clang-cl builds; r=ehsan
https://hg.mozilla.org/integration/mozilla-inbound/rev/1f3cc2963f09
Rename the Windows clang-cl builds to static analysis builds; r=froydnj

Comment 63

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/806029a2c31d
followup - add explicit to some Windows-only IPC classes on a CLOSED TREE; r=bustage

Comment 64

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2fc498f1d5bc
followup - make nsTArray<mozilla::gfx::FilterPrimitiveDescription> use copies on a CLOSED TREE; r=bustage

Comment 65

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c4efe5014971
turn static analysis off on windows debug clang-cl builds; r=bustage

Comment 66

[Nathan Froyd [:froydnj]]

(In reply to Pulsebot from comment #65)
> Pushed by [e-mail]:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/c4efe5014971
> turn static analysis off on windows debug clang-cl builds; r=bustage

We ran into some issues with debug builds, and it also looks like there's a bug in the plugin that causes it to not consider std::atomic memmovable on Windows, leading to lots of problems.  Ehsan's looking into the plugin problem, and then we can reland things.

Comment 67

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e6fdd363cb76
Mark AutoSetXPCOMLoadOnMainThread's constructor as explicit
https://hg.mozilla.org/integration/mozilla-inbound/rev/a197222090fb
Re-enable Windows static analysis builds

Comment 68

[Ting-Yu Chou [:ting] (away)]

Ehsan & Nathan, sorry I made the mistake that didn't check the debug build, I'll be more careful and make sure I don't miss anything before I say it is fixed.

Comment 69

[(no longer active)]

No worries, it's rare for an error to only be detected in one configuration!

Comment 70

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/5ff2c66f4020
https://hg.mozilla.org/mozilla-central/rev/1f3cc2963f09
https://hg.mozilla.org/mozilla-central/rev/806029a2c31d
https://hg.mozilla.org/mozilla-central/rev/2fc498f1d5bc
https://hg.mozilla.org/mozilla-central/rev/c4efe5014971
https://hg.mozilla.org/mozilla-central/rev/e6fdd363cb76
https://hg.mozilla.org/mozilla-central/rev/a197222090fb