sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Git - "Git: connect ENOENT" error 
Labels: bug,git

Type: <b>Bug</b>

1. Work with IDE some period of time.
2. Try to make Git Commit Amend.
3. Got "Git: connect ENOENT /var/folders/_x/pjn2dmxx0tl9dgnhgryk54n80000gp/T/vscode-git-299f631f9b.sock".

VS Code version: Code 1.82.1 (6509174151d557a81c9d0b5f8a5a1e9274db5585, 2023-09-08T08:49:22.656Z)
OS version: Darwin arm64 22.6.0
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Apple M1 Pro (10 x 24)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|3, 3, 3|
|Memory (System)|32.00GB (0.79GB free)|
|Process Argv|--crash-reporter-id 85479485-0e20-4bb1-8875-f05e0b4bf5e2|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (31)</summary>

Extension|Author (truncated)|Version
---|---|---
markdown-mermaid|bie|1.19.0
java-pmd|cra|0.6.3
xml|Dot|2.5.1
es7-react-js-snippets|dsz|4.4.3
prettier-vscode|esb|10.1.0
go|gol|0.39.1
rest-client|hum|0.25.1
Kotlin|mat|1.7.1
git-graph|mhu|1.30.0
vscode-docker|ms-|1.26.0
black-formatter|ms-|2023.4.1
python|ms-|2023.16.0
remote-containers|ms-|0.309.0
fabric8-analytics|red|0.7.0
java|red|1.22.1
vscode-yaml|red|1.14.0
rust-analyzer|rus|0.3.1657
vscode-checkstyle|she|1.4.2
code-spell-checker|str|3.0.1
code-spell-checker-russian|str|2.1.0
even-better-toml|tam|0.19.2
pdf|tom|1.2.2
intellicode-api-usage-examples|Vis|0.2.8
vscodeintellicode|Vis|1.2.30
vscode-gradle|vsc|3.12.7
vscode-java-debug|vsc|0.54.0
vscode-java-dependency|vsc|0.23.1
vscode-java-pack|vsc|0.25.14
vscode-java-test|vsc|0.39.1
vscode-maven|vsc|0.42.0
volar|Vue|1.8.11


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
vscoreces:30445986
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
vsclangdc:30486549
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
vscccc:30803845
2e4cg342:30602488
89544117:30613380
showlangstatbar:30737416
962ge761:30835153
03d35959:30757346
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30797651
pythonidxpt:30805730
pythonnoceb:30805159
dsvsc013:30795093
dsvsc014:30804076
diffeditorv2:30821572
dsvsc015cf:30829746

```

</details>

<!-- generated by issue reporter -->
Repository: pytorch
Issue: aten::squeeze exported to ONNX as an `If` node
Labels: module: onnx,triaged

### 🐛 Describe the bug

Hi,

I am exporting to ONNX llama from transformers implementation, and don't understand why `If` nodes are inserted for the export of this `squeeze` operator, where the first dims are always of shape `1` and `1`: https://github.com/huggingface/transformers/blob/7c63e6fc8c34dcf8b0121eaee776f41ccf3b1137/src/transformers/models/llama/modeling_llama.py#L182

It appears we are going into this path: https://github.com/pytorch/pytorch/blob/b6a1d3fb97ca8eeccf15a4c495fdd1af4b197f88/torch/onnx/symbolic_opset11.py#L937

because the symbolic helper `_get_tensor_sizes` give us [here](https://github.com/pytorch/pytorch/blob/b6a1d3fb97ca8eeccf15a4c495fdd1af4b197f88/torch/onnx/symbolic_helper.py#L578) `x_type.varyingSizes() = [None, None, None, None]` .

Is there a way to hint that the shapes are constant hard-coded to `1`? The intermediate captured graph is (the aten::sub is not in the original code base - added for debugging):

```
  %4407 : Float(1, 1, 17, 4, strides=[68, 68, 4, 1], requires_grad=0, device=cpu) = aten::sub(%cos.1, %4405, %4406), scope: transformers.models.llama.modeling_llama.LlamaForCausalLM::/transformers.models.llama.modeling_llama.LlamaModel::model/transformers.models.llama.modeling_llama.LlamaDecoderLayer::layers.0/transformers.models.llama.modeling_llama.LlamaAttention::self_attn # /home/fxmarty/hf_internship/transformers/src/transformers/models/llama/modeling_llama.py:183:0
  %4408 : int = prim::Constant[value=1](), scope: transformers.models.llama.modeling_llama.LlamaForCausalLM::/transformers.models.llama.modeling_llama.LlamaModel::model/transformers.models.llama.modeling_llama.LlamaDecoderLayer::layers.0/transformers.models.llama.modeling_llama.LlamaAttention::self_attn # /home/fxmarty/hf_internship/transformers/src/transformers/models/llama/modeling_llama.py:185:0
  %4409 : Float(1, 17, 4, strides=[68, 4, 1], requires_grad=0, device=cpu) = aten::squeeze(%4407, %4408), scope: transformers.models.llama.modeling_llama.LlamaForCausalLM::/transformers.models.llama.modeling_llama.LlamaModel::model/transformers.models.llama.modeling_llama.LlamaDecoderLayer::layers.0/transformers.models.llama.modeling_llama.LlamaAttention::self_attn # /home/fxmarty/hf_internship/transformers/src/transformers/models/llama/modeling_llama.py:185:0
```

A workaround is to use `cos = cos[0, 0]` - wondering if there is anything better.

Thank you!

cc @justinchuby 

### Versions

torch 2.0.1, opset_version = 12
Repository: rust
Issue: Rustdoc: always render required features, even if they are default
Labels: T-rustdoc,C-feature-request,F-doc_cfg,F-doc_auto_cfg

As best I can tell, currently Rustdoc only renders the "Availabe on crate feature xxx only." box if this feature is not default.

For various reasons, a library user may want to cut down and use `default-features = false` in their `Cargo.toml` (in fact, IMO it's good practice for libraries). In those cases, if something is gated behind one of the default features, it leads to confusion, and makes it hard to discover *which* features are required for a part of a crate to be present.

What I would like to see, is for the required feature box to be *always* present, even if something is gated behind a default feature.
Repository: rust
Issue: Cargo suggestion doesn't work with crates having a hyphen in the name
Labels: T-cargo

While hitting https://github.com/rust-lang/rust/issues/84970#issuecomment-1719441857, I got this from Cargo:
```
$ cargo check
[…]
error: internal compiler error: encountered incremental compilation error with mir_built(2b0ee002860f4e6d-86dbf79d6866cd33)
  |
  = help: This is a known issue with the compiler. Run `cargo clean -p nimiq_lib` or `cargo clean` to allow your project to compile
  = note: Please follow the instructions below to create a bug report with the provided information
  = note: See <https://github.com/rust-lang/rust/issues/84970> for more information
[…]
```

Running `cargo clean -p nimiq_lib` failed with the following error:
```
$ cargo clean -p nimiq_lib
error: package ID specification `nimiq_lib` did not match any packages

	Did you mean `nimiq-lib`?
$ cargo clean -p nimiq-lib
$
```
And indeed `cargo clean -p nimiq-lib` works.
Repository: flutter
Issue: Batch engine dependabot updates into a single commit
Labels: team-infra,P2,triaged-infra

It's not an efficient use of CI resources to update the version of each package individually in separate commits. This should behave like the framework package autoroller, and update all packages at once ~1 time a day. Looks like this was just added in https://github.com/flutter/engine/pull/45754. cc @godofredoc 

<img width="997" alt="Screenshot 2023-09-14 at 6 26 42 AM" src="https://github.com/flutter/flutter/assets/6343103/1f514e17-718c-4012-ae88-29aa92e35c74">
Repository: create-react-app
Issue: Vulnerability Issues with nth-check in react-scripts Dependencies
Labels: needs triage,issue: bug report

**Environment**:
- Operating System: Windows 11
- IDE: Visual Studio Code
- Node.js version: v18.17.1
- npm version: 10.1.0

**Description**:
I am encountering a persistent vulnerability issue with `react-scripts` related to the `nth-check` package. Despite making multiple attempts to update the dependencies manually and exploring various resolutions, the vulnerability warning remains.

**NPM Audit Output**:
nth-check <2.0.1
Severity: high
Inefficient Regular Expression Complexity in nth-check - [GHSA-rp65-9cf3-cjxr](https://github.com/advisories/GHSA-rp65-9cf3-cjxr)
fix available via npm audit fix --force
Will install react-scripts@2.1.3, which is a breaking change
node_modules/react-scripts/node_modules/nth-check
css-select <=3.1.0
Depends on vulnerable versions of nth-check
node_modules/react-scripts/node_modules/css-select
svgo 1.0.0 - 1.3.2
Depends on vulnerable versions of css-select
node_modules/react-scripts/node_modules/svgo
@svgr/plugin-svgo <=5.5.0
Depends on vulnerable versions of svgo
node_modules/react-scripts/node_modules/@svgr/plugin-svgo
@svgr/webpack 4.0.0 - 5.5.0
Depends on vulnerable versions of @svgr/plugin-svgo
node_modules/react-scripts/node_modules/@svgr/webpack
react-scripts >=2.1.4
Depends on vulnerable versions of @svgr/webpack
node_modules/react-scripts

**Steps to Reproduce**:
1. Updated to the latest version of `react-scripts`.
2. Ran `npm audit`, revealing the vulnerability issue related to `nth-check`.
3. Attempted to manually update dependencies and force resolutions.
4. Checked again with `npm audit`, but the vulnerability warning persisted.

**Expected Behavior**:
The dependencies, especially `nth-check`, should be up-to-date, ensuring no vulnerabilities when executing `npm audit`.

**Additional Context**:
I made attempts to resolve this by updating individual packages and also using the `npm-force-resolutions` package. Unfortunately, the vulnerability continues to persist.

Seeking guidance or a potential fix for this vulnerability. Thank you for your assistance!
Repository: godot
Issue: Project logs are output to the project folder instead of the specified folder (caused by WeGame client implicit Vulkan layer)
Labels: bug,platform:windows,topic:editor,needs testing

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3070 (NVIDIA; 31.0.15.3713) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

This is my project folder. 
![project folder](https://github.com/godotengine/godot/assets/33609801/243718c4-97c3-41c5-ab2c-c04c2b662a87)
This is my Log Path setting. Didn't change it.
![image](https://github.com/godotengine/godot/assets/33609801/5881f1ef-c70b-4a7e-b507-0aeb19c40912)

If you start Godot.exe as an administrator, no logs will be generated in the project folder (but I don’t know where they are). But I haven't started it as an administrator in the past few months and haven't seen this behavior. This is what I just discovered today.

### Steps to reproduce

Create a new project and start it.

### Minimal reproduction project

N/A. This problem occurs in all new projects I created, as well as old projects that have not been touched for several months.
Repository: material-ui
Issue: [Slider][material-next] Refactor style to use CSS variables
Labels: component: slider,enhancement,design: material you

Refactor `material-next`'s Slider style implementation to use CSS Variables similar to [Joy UI's Slider](https://github.com/mui/material-ui/blob/master/packages/mui-joy/src/Slider/Slider.tsx).

The goal of doing this is to make the style implementation DRYer. For example, adding a `--md-comp-slider-track-size` variable used for the track's height on horizontal sliders and the track's width on vertical sliders. This will also enable customization via CSS variables.

It should take inspiration from Joy UI's slider, using similar variables if applicable. It doesn't have to be a 1:1 copy; some variables in Joy UI might not be helpful in Material UI, and some might have to be added.

The variables should follow Material You's token syntax: `--md-comp-slider-token-in-kebab-case.`
Repository: go
Issue: go/doc: `AllMethods` mode erroneously includes methods shadowed by field declarations
Labels: NeedsFix,FixPending

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel go1.22-ee788dba Sat Sep 9 01:48:44 2023 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/usr/local/google/home/bcmills/.cache/go-build'
GOENV='/usr/local/google/home/bcmills/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/tmp/tmp.VIszpiTnn8/.gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/tmp/tmp.VIszpiTnn8/.gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/google/home/bcmills/sdk/gotip'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/google/home/bcmills/sdk/gotip/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.22-ee788dba Sat Sep 9 01:48:44 2023 +0000'
GCCGO='/usr/bin/gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/tmp/tmp.VIszpiTnn8/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build150804637=/tmp/go-build -gno-record-gcc-switches'

</pre></details>

### What did you do?

Extract the following test to a local directory and run it:

```go
-- example.go --
package example

type E struct{}

// F should be hidden within S because of the S.F field.
func (e E) F() string {
	return "blargh"
}

type S struct {
	E
	F int
}
-- example_test.go --
package example_test

import (
	"go/ast"
	"go/doc"
	"go/parser"
	"go/token"
	"testing"
)

func TestDoc(t *testing.T) {
	fset := token.NewFileSet()
	f, err := parser.ParseFile(fset, "example.go", nil, parser.ParseComments|parser.AllErrors)
	if err != nil {
		t.Fatal(err)
	}
	p, err := doc.NewFromFiles(fset, []*ast.File{f}, "example", doc.AllMethods)
	if err != nil {
		t.Fatal(err)
	}
	for _, typ := range p.Types {
		if typ.Name == "S" {
			for _, m := range typ.Methods {
				t.Fatalf("unexpected method on S: %v%s", p.Text(m.Doc))
			}
		}
	}
}
```


### What did you expect to see?

The `doc.Package` for `example.go` should not include any methods on type `S`, since the method `F` is shadowed by the field `S.F`. (For confirmation that the field actually does shadow the method, see https://go.dev/play/p/OdO3BIxNHgd.)


### What did you see instead?

```
$ go test .
--- FAIL: TestDoc (0.00s)
    example_test.go:24: unexpected method on S: F should be hidden within S because of the S.F field.
FAIL
FAIL    example 0.005s
```

(CC @griesemer @agnivade)
Repository: flutter
Issue: [Impeller] Add gallery vulkan validation layers integration test
Labels: engine,P2,e: impeller,team-engine,triaged-engine

https://github.com/flutter/flutter/pull/134685 added an integration test that just tests that hello world does not produce validation errors.  We should create a new test for expanded coverage that runs through the gallery driver test for better coverage.
Repository: flutter
Issue: [Impeller] Text rendering problem with foreground paint set to `BlendMode.clear`.
Labels: engine,P2,e: impeller,team-engine,triaged-engine

As seen in the example for https://github.com/flutter/flutter/issues/134705 the text rendered using a Clear blend mode appears as blocks rather than glyphs. This is a separate problem from the saveLayer target error mentioned in that Issue.
Repository: tensorflow
Issue: Compiled x.shape throws Tuple out-of-range error
Labels: stat:awaiting tensorflower,type:bug,comp:xla,TF 2.13

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

tf2.13, 2.15.0-dev20230913

### Custom code

Yes

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

When a tensor has shape `(2,)`, `x.shape` returns `2`, and throws an error when I try to get `x.shape[0]`. Without `@tf.function(jit_compile=True)` it works well.

### Standalone code to reproduce the issue

```shell
class Model(tf.keras.Model):

  def __init__(self):
    super(Model, self).__init__()

  @tf.function(jit_compile=True)
  def call(self, x1):
    def select_2_or_one(x):
      print(x.shape)
      if int(x.shape[0]) == 2:
        return x
      else:
        return tf.stack([x,x])
    return tf.cond(tf.less(x1[0], x1[1]),
        lambda: select_2_or_one(x1),
        lambda: select_2_or_one(x1[0]))

m = Model()

input_shape = [2,]
x1 = tf.constant([2.,3.], shape=input_shape)

y = m(x1)
print(y)
```


### Relevant log output

```shell
if int(x.shape[0]) == 2:

    IndexError: tuple index out of range


Call arguments received by layer 'model_1' (type Model):
  • x1=tf.Tensor(shape=(2,), dtype=float32)
```
Repository: material-ui
Issue: [Slider][material-next] Implement opacity-based disabled state
Labels: on hold,component: slider,enhancement,design: material you

The disabled states in Material You use colors with opacity < 1, but right now, the Slider disabled state uses a solid color. Implementing this is not straightforward because multiple elements are stacked on top of each other:

- Thumbs on top of marks, the track, and the rail
- Marks on top of the track and the rail
- Track on top of the rail

It is not possible to use opacity < 1 on these elements as those underneath show through, and colors blend. This is not the desired outcome.

This issue aims to refactor the component's structure to not stack elements and implement the correct colors with opacity.

#### Experimenting

- [Radial gradients](https://developer.mozilla.org/en-US/docs/Web/CSS/gradient/radial-gradient) would be helpful to "clip" the thumb shape into the track and rail
- Marks underneath the thumbs shouldn't be displayed
Repository: vscode
Issue: Paste in Git Bash in terminal corrupts input if length is 90 characters or more.
Labels: bug,upstream,windows,upstream-issue-linked,terminal-shell-git-bash

VS Code: 1.82.1
OS: Windows_NT x64 10.0.19045
Git: 2.42.0.windows.2

I'm using VS Code 1.82.1 on Windows 10 with the latest updates. I installed Git for Windows 2.42.0, which comes with Git Bash.

I have long used Git Bash in the VS Code terminal, and noticed that sometimes what I paste is corrupted. Now with these current versions I have taking the time to investigate.

**VS Code corrupts text input via `Ctrl+V` (or the `Paste` command generally) if the input string is 90 characters or more.**

Steps to reproduce:

1. Open Git Bash in the VS Code terminal.
2. Paste `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`

Expected: `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`
Actual: `[201~`

The key issue is the length of the text being pasted. If the text is 90 characters or more, the text is corrupted in some one, as illustrated below. If the text is 89 characters or less, the text is pasted as expected. With 90 characters or more, note the additional characters including `~` appended, until finally with 93 characters the entire string is replaced with garbage.

* `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx` (89 characters)
  > `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`
* `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx` (90 characters)
  > `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx~`
* `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx` (91 characters)
  > `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1~`
* `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx` (92 characters)
  > `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx01~`
* `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx` (93 characters)
  > `[201~`

https://askubuntu.com/q/1396132 hints that this may be related to the `Readline` library, although its unclear why the length would have anything to do with it.

_This does not happen with Git Bash standalone in a separate window, or in Git Bash in a Microsoft Terminal tab._ The bug seems to be specific to VS Code.
Repository: flutter
Issue: Add ABSL to flutter/engine
Labels: engine,c: proposal,P2,team-engine,triaged-engine

The [Google C++ style guide](https://google.github.io/styleguide/cppguide.html) recommends the usage of absl in many cases but we do not have it available in the flutter engine.  In some cases this has caused us to duplicate and maintain similar functionality in `fml` (example: fml::SharedMutex and fml::Status), in other cases it has hurt our designs (example: `IsValid()` methods in impeller instead of using `absl::status_or`).

@zanderso has made a good point that we should be careful about binary size.  This could be a problem especially if we use absl's offerings simultaneously with fml offerings which is complicated by the upfront cost to migrate existing code.

Chromium has already [adopted absl](https://chromium.googlesource.com/chromium/src/third_party/abseil-cpp/) so it should be easy to drop in technically.

There may some functionality in absl that doesn't exist today that could help us too.  I don't have experience with `absl::GetStackTrace`, but just the other day a user was asking for stacktraces when debugging c++ asserts.  If that works on any of our target platforms that could save us some debugging time too if `FML_CHECK`'s print out the stacktrace in debug builds.  I didn't explore more potential usages since what I've listed already seems valuable enough.

cc @matanlurey