All devs do incremental builds. Of course incremental builds should work.

Sounds like that puts it in the "takes a while to figure out" category, so revert for now?

This seems to break tests everywhere, eg http://45.33.8.238/linux/28628/step_11.txt

I believe I used this (by hacking up the gn files) locally on mac a while ago, but I'm not sure. LG, I'll try asan on mac and relax the assert if it works.

I agree, it does look pretty complicated :)

Which header do you think is missing? It built fine on several machines over here.

lg assuming we have tests for float literals containing an e in them somewhere already.

Looks like this doesn't build: http://45.33.8.238/linux/27982/step_4.txt

This seems to break tests on most bots, e.g. http://45.33.8.238/linux/27972/step_12.txt

Looks like this breaks tests: http://45.33.8.238/linux/27942/step_12.txt

Looks like this breaks tests on mac: http://45.33.8.238/mac/20491/step_11.txt

It's not blocking us because we added an explicit flag to force this off to our build config for "normal" builds. (We still get the default-on behavior on our bots that build with trunk clang.) But if others are seeing problems with this too, I think it makes sense to revert so others don't spend time tracking down miscompiles to this commit.

(marking this "request changes" to get it off my dashboard. please ping if you do add a test :) )

Maybe have a test covering the parse error case too.

Heads-up: We're seeing fairly widespread test failures with this in Chromium that go away when we force this flag off. It's possible that it's due to only a small number of issues and they might be previously-benign UB (no idea), but I figured I'd give an early note. We'll send an update once we've reduced a failing test.

The fix-up breaks tests: http://45.33.8.238/linux/27687/step_12.txt

Looks like this broke check-llvm: http://45.33.8.238/linux/27555/step_12.txt

test?

Reverted this (and some follow-ups that caused conflicts during the revert) in rGdbf04aaade235a0d76c6ad549c091c9fd0ada0e8 to unbreak the Windows build.

(I fixed this in the GN build in rGc88a77620436ee475d54d3b5ced30286101e0dc9 and don't care all that much about what happens in the cmake build, so if y'all are happy with what currently happens, it's fine to not change anything here, but it looks strange to me.)

(ps: No need to touch files in llvm/utils/gn at all, keeping that code updates is up to folks using the gn build.)

This puts #!/usr/bin/python3.8 instead of #!/usr/bin/env python3.8 in llvm-bulid/bin/llvm-lit (in a cmake build). That seems undesirable?

rG82f3c5d4a66 cross-ref so i can find this faster next time

Generally seems fine, nits below:

I don't think this should become the default.

Thanks!

Looks like this broke tests on windows: http://45.33.8.238/win/23171/step_7.txt

Thanks for updating the GN files! I just wanted to point out that updating them is completely optional.

One of the N patches that landed 9:45 pm eastern yesterday seems to break check-lld on mac: http://45.33.8.238/mac/19510/step_10.txt

In D86496#2235124, @aganea wrote:

@thakis Do you think you can add printenv.exe into https://commondatastorage.googleapis.com/chromium-browser-clang/tools/gnuwin-XX.zip so we can enable the test again on Windows? Please see https://reviews.llvm.org/D86170#inline-799301

(I'm guessing it was failing under cmd previously and fails in msys/gig bash now?)

This breaks check-llvm on windows: http://45.33.8.238/win/22625/step_11.txt

(I made the crbug public again)