* chore: chunk filenames when linting C++ files
* chore: refactor code for better readability
Co-authored-by: Charles Kerr <charles@charleskerr.com>
* chore: further tweak
* chore: limit all platforms to 4095 characters on command line
* chore: use python3
* Revert "chore: use python3"
Co-authored-by: Charles Kerr <charles@charleskerr.com>
Co-authored-by: Cheng Zhao <zcbenz@gmail.com>
Extending the `testing` GN profile with the arguments documented to
allow breakpoint debugging
(https://www.electronjs.org/docs/latest/development/debugging#breakpoint-debugging)
doesn't quite work on macOS:
```sh
is_debug = true
symbol_level = 2
forbid_non_component_debug_builds = false
```
The build eventually fails on both Intel and Apple Silicon with the
following (summarized) error:
```sh
[S:41062 R:1 (41062:41247) (C/s:0.1 O/s:13.6)] SOLINK 'obj/electron/electron_framework_shared_library/Electron Framework' 'obj/electron/electron_framework_shared_library/Electron Framework.TOC'
FAILED: obj/electron/electron_framework_shared_library/Electron Framework obj/electron/electron_framework_shared_library/Electron Framework.TOC
...
Undefined symbols for architecture x86_64:
"platform_util::GetViewForWindow(gfx::NativeWindow)", referenced from:
BoundsOverlapWithAnyOpenPrompt(gfx::Rect const&, content::WebContents*) in libchrome.a(autofill_popup_view_utils.o)
"platform_util::GetParent(gfx::NativeView)", referenced from:
BoundsOverlapWithAnyOpenPrompt(gfx::Rect const&, content::WebContents*) in libchrome.a(autofill_popup_view_utils.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
...
```
This symbol is defined on a file that is not declared as a dependency of
`libchrome` on the GN definitions. Why the problem is not reproducible
on plain testing or release builds remains a mystery to me. I'm guessing
some non-debug path somewhere in the GN definitions does eventually
require that file.
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
fix: performance problem in crashReporter.start() on macOS
This change reduces the duration of crashReporter.start() on Intel macOS
from 622 milliseconds to 257 milliseconds!
Backports https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
posix: Replace DoubleForkAndExec() with ForkAndSpawn()
The DoubleForkAndExec() function was taking over 622 milliseconds to run
on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
some custom traces and found that the fork() syscall is the bottleneck
here, i.e., the first fork() takes around 359 milliseconds and the
nested fork() takes around 263 milliseconds. Replacing the nested fork()
and exec() with posix_spawn() reduces the time consumption to 257
milliseconds!
See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
slow on macOS and why posix_spawn() is a better replacement.
Another point to note is that even base::LaunchProcess() from Chromium
calls posix_spawnp() on macOS -
8f8d82dea0:base/process/launch_mac.cc;l=295-296
Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Fixes: https://github.com/electron/electron/issues/34321
Signed-off-by: Darshan Sen <raisinten@gmail.com>
* feat: add immersive dark mode
* fix syntax and add header
* add me
* Update fuses.json5
* fix: redraw title bar on dark mode change
* chore: SetWindowTheme doesn't seem to be needed
* chore: separate out Win 10 dark mode implementation
* final touches
* final touches
* chore: limit Win 10 to >= 20H1 and drop fuse
* fix types
* fix lint
Co-authored-by: Micha Hanselmann <micha.hanselmann@gmail.com>
Co-authored-by: David Sanders <dsanders11@ucsbalum.com>
