sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Allow custom spacing between helperText, errorText and border on InputDecoration
Labels: a: text input,framework,f: material design,c: proposal,team-design,triaged-design



## Use case

There is currently no way of adding a custom spacing between `helperText`, `errorText` and `border` in an `InputDecoration`.

The look can be altered by changing the line height of the `helperText` and `errorText`, but this solution does not work for multi-line text and is just a work-around, not a true solution.

## Proposal

Allow custom spacing between `helperText`, `errorText` and `border`.
Repository: create-react-app
Issue: [v4] Fast Refresh should not be enabled for old ReactDOM versions
Labels: stale,needs triage,issue: bug report

If Fast Refresh is unavailable then we should fall back to full reloads. Currently, if you use CRA 4 with an old version of React (e.g. 15) it just doesn't do anything on edit.
Repository: go
Issue: x/build: prevent submission of CL with an outstanding wait-* hashtag
Labels: Builders,NeedsInvestigation

There is a convention of using a wait-* hashtag to indicate a CL is waiting on some specific item before progress can be made. This is described in issue #10658, which may need to be resolved more before progress can be made here.

I suspect it may be helpful to to have an automatic mechanism that prevents a CL from being submitted if it has an active wait-* hashtag. If waiting is no longer necessary, the wait-* hashtag should be removed. This can help avoid accidental early submission. See [CL 260700](https://golang.org/cl/260700) for a recent example of a CL that was accidentally submitted too early despite having a wait-release hashtag.

Perhaps it can be implemented as gopherbot applying a -2 code review vote (and a comment?), as a Gerrit rule (similar to implementation of Trust votes), or some other way. This is related to #41722, which is about detecting a mismatch in target branch, #10658, which is about detecting large binaries, and to #18548, which is about various server-side checks.

/cc @golang/osp-team
Repository: pytorch
Issue: A race problem of JIT cpp extensions in distributed setting
Labels: oncall: jit,days

When compiling JIT cpp extensions in distributed setting for **the first time** on a machine, processes will have race problems in creating the temporary directory for compilation. This always halts the program.

```
  File "/home/zhuzhaoc/.local/envs/drug/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 677, in load
    torch_ext = cpp_extension.load("torch_ext", [os.path.join(path, "torch_ext.cpp")], extra_cflags=["-Ofast"])
  File "/home/zhuzhaoc/.local/envs/drug/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 677, in load
    build_directory or _get_build_directory(name, verbose),
  File "/home/zhuzhaoc/.local/envs/drug/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 1051, in _get_build_directory
    build_directory or _get_build_directory(name, verbose),
  File "/home/zhuzhaoc/.local/envs/drug/lib/python3.7/site-packages/torch/utils/cpp_extension.py", line 1051, in _get_build_directory
    os.makedirs(build_directory)
  File "/home/zhuzhaoc/.local/envs/drug/lib/python3.7/os.py", line 223, in makedirs
    os.makedirs(build_directory)
  File "/home/zhuzhaoc/.local/envs/drug/lib/python3.7/os.py", line 223, in makedirs
    mkdir(name, mode)
FileExistsError: [Errno 17] File exists: '/tmp/torch_extensions/torch_ext'
```

Once the directory has been created, running the program again won't cause the error.

The problem can be reproduced using the same code snap in #6353. This may be fixed by a lock (FileBaton) over the directory creation.

cc @gmagogsfm
Repository: go
Issue: testing: show diffs for incorrect output from Example tests
Labels: Proposal,Proposal-Accepted

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.1 darwin/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="/Users/home/Library/Caches/go-build"
GOENV="/Users/home/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/home/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/home/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/home/mystuff/kama/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gc/sfs6hvtd1r392kn91n3jp17m0000gn/T/go-build416873732=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?
Created test example (https://golang.org/pkg/testing/#hdr-Examples, https://blog.golang.org/examples).  
A reproducer of the issue is at https://play.golang.org/p/969hijP9sMx   


### What did you expect to see?
That example test is failing because there is a mismatch between what is been output to stdOut and what the test runner expects the output to be.   
Unfortunately for test examples(unlike normal tests), I'm not able to programmatically get the test output so that I can examine(via diffing or otherwise) it and compare it to the expected result.



### What did you see instead?
I do not have a way to access(programmatically) the output of the test.
Repository: angular
Issue: In Ivy, pipes in projected content uses viewProviders from a host component where ViewEngine did not
Labels: regression,area: core,core: di,core: pipes,P4

Closely related to: https://github.com/angular/angular/issues/36146

# 🐞 bug report

### Affected Package
@angular/core

### Is this a regression?
Yes. 
Worked with VE.
Half worked after the bugfix that closed https://github.com/angular/angular/issues/36146.
Half is broken

### Description
This time the problem happens when the pipe is used inside a template projected into the host component

## 🔬 Minimal Reproduction
https://github.com/EmaGht/ivypipe

I would love to provide an ng-run version, and God knows i tried, but apparently any package i try to install >9.1.0 simply hangs/doesn't install/crash/makes me question WHY/etc...

## 🌍  Your Environment

**Angular Version:**

Angular CLI: 10.1.6
Node: 12.18.3
OS: win32 x64

Angular: 10.1.5
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1001.6
@angular-devkit/build-angular   0.1001.6
@angular-devkit/core            10.1.6
@angular-devkit/schematics      10.1.6
@angular/cli                    10.1.6
@schematics/angular             10.1.6
@schematics/update              0.1001.6
rxjs                            6.6.3
typescript                      4.0.3

**Anything else relevant?**
Every time i try to make this behavior work in my application i have to manually edit 200+ components.

I did it once at the beginning, thinking Ivy would be backward compatible with VE, jokes on me
I did it once again today, because i trusted the fact the issue had been solved, jokes on me
they say the third is the good one, I'm counting on that!
Repository: pytorch
Issue: torch.distributions.half_normal.HalfNormal.cdf returns negative values
Labels: module: distributions,triaged

## 🐛 Bug

I've been using `torch.distributions` for a bit of probability work and noticed a strange behavior where `torch.distributions.HalfNormal` returns a _negative value_ for some CDF scores -- something that is typically bound between 0 and 1. 

## To Reproduce

Steps to reproduce the behavior:
```
from torch.distributions import HalfNormal
cdf_score = HalfNormal(scale=1).cdf(-1)

# this should always be between zero and 1
print(cdf_score)
```

Output is:
```
tensor(-0.6827)
```

## Expected behavior

Mathematically, a HalfNormal variable should always be greater than a negative value, which should yield a CDF score of zero. I'm unsure what the optimal fix is (my own hack was to simply take the max of the CDF score and `torch.tensor(0)`)

I believe [this is the line creating the issue](https://github.com/pytorch/pytorch/blob/master/torch/distributions/half_normal.py#L57), which would return a negative whenever the `base_dist` has CDF less than 0.5. 

## Environment
PyTorch version: 1.4.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Mac OSX 10.15.7 (x86_64)
GCC version: Could not collect
Clang version: 11.0.3 (clang-1103.0.32.29)
CMake version: Could not collect

Python version: 3.7 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.1
[pip3] numpydoc==0.9.2
[pip3] torch==1.4.0
[pip3] torchvision==0.5.0
[conda] blas                      1.0                         mkl  
[conda] mkl                       2019.4                      233  
[conda] mkl-service               2.3.0            py37hfbe908c_0  
[conda] mkl_fft                   1.2.0            py37hc64f4ea_0  
[conda] mkl_random                1.1.1            py37h959d312_0  
[conda] numpy                     1.19.1           py37h3b9f5b6_0  
[conda] numpy-base                1.19.1           py37hcfb5961_0  
[conda] numpydoc                  0.9.2                      py_0  
[conda] pytorch                   1.4.0                   py3.7_0    pytorch
[conda] torchvision               0.5.0                  py37_cpu    pytorch

## Additional context
This bug shows up in both a local macOS and on Google Colab


cc @fritzo @neerajprad @alicanb @vishwakftw @nikitaved
Repository: rust
Issue: feature(isa_attribute) / #[instruciton_set()] not present in the unstable book
Labels: C-enhancement,A-docs,requires-nightly,F-isa_attribute

this has been implemented in Nightly but not added to be unstable book.
Repository: flutter
Issue: [Flutter Engine] cross-compile vs host build
Labels: engine,c: proposal,P3,team-engine,triaged-engine

Flutter engine build scripts needs work in determining a host vs a cross-compile build.

Currently if the cross-compile matches the host machine architecture, it treats it like a host build.

I would suggest differentiating a host vs cross-compile using the sysroot value.  If the sysroot value doesn't match the host sysroot, then it's a cross-compile.

I use the host toolchain to cross compile, and just change the sysroot.
Repository: pytorch
Issue: [chore] Test pybind11 2.6.0 (RC 2?)
Labels: module: build,module: ci,triaged,enhancement

There [is a bug](https://bugs.python.org/issue41237) in CPython 3.9.0 (already fixed in 3.9 and master) that breaks pybind11 extensions slightly, causing them to exhibit UB (on macOS, usually segfaults on process exit). While this will be fixed in CPython 3.9.1, and has [already been patched](https://github.com/conda-forge/python-feedstock/pull/402) in Conda-forge's Python 3.9 build, it is likely to affect users. pybind11 is about to release 2.6.0 (currently on 2.6.0rc2) that [will detect 3.9.0 and leak instead of segfaulting](https://github.com/pybind/pybind11/pull/2576); can that be tested with PyTorch to make sure it is an easy upgrade and no last fixes or patches are needed? There is at least one long-standing issue requested by PyTorch fixed in 2.6, as well, though I don't remember which one, as well as better CUDA support and more.

cc @malfet @seemethere @walterddr @ezyang
Repository: pytorch
Issue: Complex Number support for torch.nn modules
Labels: module: nn,triaged,module: complex

## 🚀 Feature
This issue is meant to roll up the conversation for how PyTorch intends to extend complex number support to nn module.

## Motivation

Complex Neural Networks are quickly becoming an active area of research and it would be useful for the users to be able to create modules with complex valued parameters.

## Pitch

Some of the things intended to be discussed further are:
1. Creating modules with complex valued parameters without having to go via real. for example., `module.to(torch.cfloat)`. The downside of using `module.to(torch.cfloat)` is that the parameters initialized have imaginary value set to 0.
2. Initialization of complex valued parameters. e.g., how should the complex weights be initialized?

@albanD suggested to consider adding Complex versions of the existing modules since weight initialization logic for floating point and complex parameters would be fairly different and keep these modules out-of-tree.

I think we could consider adding a dtype kwarg argument so that user can explicitly specify the kind (complex or floating point) of parameters they would like to have and initialize the parameters accordingly.

## Tasks

- [x] Complex support for Padding #50594

cc @ezyang @anjali411 @dylanbespalko @mruberry @albanD
Repository: pytorch
Issue: JIT: error in LSTM with `flatten_parameters`
Labels: oncall: jit

## 🐛 Bug

Segfault error when tried to convert JIT on LSTM with `flatten_parameters()`.

## To Reproduce

Steps to reproduce the behavior:
```
class MyModel(nn.Module):
    def __init__(self):
        super(MyModel, self).__init__()
        self.rnn = nn.LSTM(10, 20, 2)

    def forward(self, x):
        self.rnn.flatten_parameters()
        y = self.rnn(x)
        return y

model = MyModel()
jit_model = torch.jit.script(model)
print(jit_model)
```
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

Successfully converted to JIT. 

## Environment

PyTorch version: 1.5.0+cu101
Is debug build: False
CUDA used to build PyTorch: 10.1
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux 10 (buster) (x86_64)
GCC version: (Debian 8.3.0-6) 8.3.0
Clang version: Could not collect
CMake version: version 3.16.3

Python version: 3.7 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: 10.1.243
GPU models and configuration: 
GPU 0: GeForce RTX 2080 Ti
GPU 1: GeForce RTX 2080 Ti
GPU 2: GeForce RTX 2080 Ti
GPU 3: GeForce RTX 2080 Ti

Nvidia driver version: 418.56
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.16.4
[pip3] torch==1.5.0+cu101
[pip3] torchtext==0.6.0
[pip3] torchvision==0.6.0+cu101
[conda] Could not collect
Repository: rust
Issue: Feature request: Use 'trampolines' to make most of the body of a generic function non-generic
Labels: E-hard,A-codegen,I-compiletime,T-compiler,C-feature-request,I-heavy,A-mir-opt,A-monomorphization

A common pattern in Rust, especially in the standard library, is to have two versions of a function: one generic and one with the actual implementation. For example, `Error::new()` immediately delegates to a non-generic function `_new()`:
https://github.com/rust-lang/rust/blob/5565241f65cf402c3dbcb55dd492f172c473d4ce/library/std/src/io/error.rs#L250-L260

This benefits both compile- and run-time: compiletime because LLVM has to do less work compiling the large implementation of the function body many times, and runtime because generic version can safely be marked as `#[inline]` without bloating the instruction cache.

However, most libraries do not do this, for the simple reason that it's tedious and annoying to do (and you have to already know about it). It would be amazing if rustc could do this transformation itself. I expect this would help greatly with https://github.com/rust-lang/rust/issues/65031, as well as compile times across the ecosystem.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"jumbatm"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: TypeScript
Issue: Type Selection Queries
Labels: Suggestion,Awaiting More Feedback

This might be a bit of a crazy idea, but here goes: to enable loose coupling between components we sometimes write Pick<Type, 'a' | 'b' | 'c'> 

It would be nice if we could create a type query to select properties with a similar syntax to GraphQL:

e.g:
```
prop: AType[{a, b, c: { d }]
```

This would be equivalent to
```
prop: Pick<AType, 'a' | 'b'> & {c: Pick<AType['c'], 'd'>}
```

How often would you do that in "the real world" ? definitely more often if you could
How often should you do that? unclear ?


Some real-world code:
```typescript
    const testFetch = jest.fn()

    class TestOptions extends GraphQlClient.Options {
      public fetch = testFetch
    }
    const response: Pick<Response, 'ok' | 'json'> = {
      ok: true,
      async json() {
        return { data: { auth: { token: testToken } } }
      }
    }
    testFetch.mockResolvedValue(response)
```

`Pick<Response, 'ok' | 'json'>` could be `Response[{ok, json}]`

edit: that's not a great example use case, cause you could just as well do `Partial<Response>`
Repository: go
Issue: runtime: heap pageAlloc.searchAddr strategy may be wrong
Labels: NeedsInvestigation,compiler/runtime

i read the heap alloc code. and find the pageAlloc.searchAddr may  have a  problem, as the comment say 
i hope someone can review it @mknyszek 

```
type pageAlloc struct {
	// The address to start an allocation search with. It must never
	// point to any memory that is not contained in inUse, i.e.
	// inUse.contains(searchAddr) must always be true.
	//
	// When added with arenaBaseOffset, we guarantee that
	// all valid heap addresses (when also added with
	// arenaBaseOffset) below this value are allocated and
	// not worth searching.
	//
	// Note that adding in arenaBaseOffset transforms addresses
	// to a new address space with a linear view of the full address
	// space on architectures with segmented address spaces.
	searchAddr offAddr
```

why i think it may have problem?  when we find the continue npages in radix tree（code is  below）,  the searchAddr will increase when j++ into  new entry in  the same level.  but it only  mean  below searchAddr just not enough contiguous space to alloc npages。but it may can alloc mpages(mpages < npages) below searchAddr。 so  next time when we want to alloc mpages, we give up the change to alloc mpages which address below searchAddr, so we can't use the heap Efficiently。
and we may alloc more memory  because when we can't find mpages we will grow the  memory.
```
func (s *pageAlloc) find(npages uintptr) (uintptr, offAddr) {
   for j := j0; j < len(entries); j++ {
			..
			// We've encountered a non-zero summary which means
			// free memory, so update firstFree.
			foundFree(levelIndexToOffAddr(l, i+j), (uintptr(1)<<logMaxPages)*pageSize)
			....
		if size >= uint(npages) {
			addr := levelIndexToOffAddr(l, i).add(uintptr(base) * pageSize).addr()
			return addr, firstFree.base
		}
}

```

and , the  searchAddr can only recover when free npages
```
func (s *pageAlloc) free(base, npages uintptr) {
	// If we're freeing pages below the s.searchAddr, update searchAddr.
	if b := (offAddr{base}); b.lessThan(s.searchAddr) {
		s.searchAddr = b
	}
```
Repository: flutter
Issue: styling PopupMenuDivider divider color
Labels: framework,f: material design,c: proposal,team-design,triaged-design

in this simple implementation code i added some `PopupMenuButton` items into `AppBar` actions argument and now i want to styling `PopupMenuDivider` color which that have default color.

i try to use `ThemeData` but i get error:

```dart
ThemeData(
  child: const PopupMenuDivider(
    height: 10,
  ),
),
```

my code:

```dart
PopupMenuButton<int>(
  onSelected: null,
  icon: const Icon(Icons.more_vert),
  color: const Color(0xFF32313C).withOpacity(0.9),
  elevation: 8.0,
  shape: RoundedRectangleBorder(borderRadius: BorderRadius.circular(8.0)),
  itemBuilder: (context) {
    final list = <PopupMenuEntry<int>>[];
    list.add(
      PopupMenuItem(
        child: Row(
          children: [
            Icon(Icons.add, color: Colors.white),
            Text(
              "InduceSmile.com",
              style: TextStyle(color: Colors.white),
            ).pl(16.0),
          ],
        ),
      ),
    );
    list.add(
      const PopupMenuDivider(
        height: 10,
      ),
    );
    return list;
  },
offset: Offset(0, 100),
)
```
Repository: pytorch
Issue: [Feature] Imbalanced batch scattering in th.nn.DataParallel
Labels: triaged,enhancement,module: data parallel

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

When, say 4 GPUs (e.g. Titan Xp with 12 gigs of video memory) are shared among a group of people, the balanced (default) data scattering (i.e. sizes of sub-batches scattered across these cards are nearly the same) may not be flexible enough to fully leverage the GPU resource in terms of the graphics memory. For example, when the other students / colleagues  have consumed `[1GB, 2GB, 8GB, 4GB]` of graphics memory, we may want to change the numbers of samples scattered to these cards as `[x*11/33, x*10/33, x*4/33, x*8/33]` where x denote the overall batchsize. Namely, I think the scattering function should be able to accept a weight vector for imbalanced scattering.

However, assuming the previously existing workloads on the 4 cards are the same dispite of distinct memory usage, an apparent downside of doing this is that the cards with smaller batches have to sleep and wait longer for synchronization / barrier. At this point I'm not quite sure whether this requested feature is meaningful.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

Better leverage the GPU resources especially when a shared GPU server is crowded.
Repository: pytorch
Issue: Code asserts when register new aten operations' implementation thru "c10::RegisterOperators::op" API. 
Labels: module: internals,triaged

## 🐛 Bug

Because the "c10::RegisterOperators::Options::impl_unboxedOnlyKernel" has been removed in #42841, the user cannot create the KernelFunction with unboxed kernel only.
The code asserts whenever uses c10::RegisterOperators::op to add the new kernel to the Dispatch table.

## To Reproduce

Use the old API "RegisterOperators" to register the aten operation for the new specific backend
```
static auto dispatch = torch::RegisterOperators()
  .op(torch::RegisterOperators::options().schema("aten::abs.out(Tensor self, *, Tensor(a!) out) -> Tensor(a!)")
      .kernel<Tensor & ( Tensor &, const Tensor & ), my_impl::abs_out>(c10::DispatchKey::MyBackend)
      .aliasAnalysis(c10::AliasAnalysisKind::FROM_SCHEMA))
```

The code asserts at 
`ImportError: boxed_kernel_func_ == nullptr INTERNAL ASSERT FAILED at "", please report a bug to PyTorch. Tried to set a manually boxed kernel for a kernel that already has a boxed kernel set.`

## Expected behavior

The user can register the aten operation without error.


cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh @ailzhang