sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Resource path isn't case sensitive in Godot editor when loaded using preload(), but after exporting it becomes case sensitive.
Labels: bug,platform:windows,platform:macos,topic:porting,confirmed,topic:export

**Godot version:**
3.0.6

**Issue description:**
When running the game in Godot editor, the resource path loaded using `preload()` **isn't** case sensitive. However, after exporting the game, the resource path loaded using `preload()` becomes case sensitive.

This could cause confusion to developers when they made an upper/lower-case typo in scripts, since even if the play-test in Godot editor is error-free, the exported game crashes.

**Steps to reproduce:**
1. Create a new scene, say **test.tscn**.
2. Create a new script, attach it to a random node in the default scene. Add the following line to the script:
`
var test_node = preload("res://Test.tscn")
`
3. Run the default scene. No error occurs. (Meaning `preload()` isn't case sensitive.)

4. Now export the project using the official templates. Run the standalone builds, and an error occurs saying "Test.tscn" can't be loaded. (`SCRIPT ERROR: GDScript::load_byte_code: Parse Error: Can't preload resource at path: res://Test.tscn`). It becomes case sensitive.

**Minimal reproduction project:**
[test.zip](https://github.com/godotengine/godot/files/2636068/test.zip)
Repository: rust
Issue: Feature request: String::replace_in_place
Labels: T-libs-api,C-feature-request

Essentially, this can avoid allocating extra memory under the condition that the replacement is smaller than the searched expression. If the replacement is larger, a `VecDeque<u8>` can be kept to minimise the amount of extra bytes allocated. We could also pre-allocate an array on the stack and do some sort of `SmallVecDeque`.

Having a `String::replace_in_place` could also allow a `Cow::replace_in_place` which only allocates a new string if there's a change.

I don't have the time for this but I figured I'd post this here anyway, as a tracking issue will be needed anyway.
Repository: go
Issue: cmd/link: linking a c-shared archive into a Go program fails on Darwin
Labels: help wanted,OS-Darwin,NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!

#### What did you do?

I tried to rebuild the latest tip version with all.bash on my Mac.

#### What did you expect to see?

No error.

#### What did you see instead?

```
$ git rev-parse HEAD
b397248168fcb26400ac6afb88bf6080497a819e
```

```
##### ../misc/cgo/testcshared
--- FAIL: TestGo2C2Go (4.85s)
    cshared_test.go:616: run: [go build -buildmode=c-shared -o /var/folders/pb/c7_4_d355ng5zfm4r_jg2gg00000gn/T/cshared-TestGo2C2Go380654146/libtestgo2c2go.dylib go2c2go/go]
    cshared_test.go:641: run: [go build -o /var/folders/pb/c7_4_d355ng5zfm4r_jg2gg00000gn/T/cshared-TestGo2C2Go380654146/m1 go2c2go/m1]
    cshared_test.go:642: command failed: [/var/folders/pb/c7_4_d355ng5zfm4r_jg2gg00000gn/T/cshared-TestGo2C2Go380654146/m1]
        signal: abort trap
        dyld: Library not loaded: libtestgo2c2go.dylib
          Referenced from: /var/folders/pb/c7_4_d355ng5zfm4r_jg2gg00000gn/T/cshared-TestGo2C2Go380654146/m1
          Reason: image not found
        
FAIL
2018/12/02 08:32:51 Failed: exit status 1
```

#### Does this issue reproduce with the latest release (go1.11.2)?

N/A

#### System details

```
go version devel +b397248168 Sat Dec 1 17:31:02 2018 +0000 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/yoshiki/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/yoshiki/gocode:/Users/yoshiki/exercises/gpl:/Users/yoshiki/oak"
GOPROXY=""
GORACE=""
GOROOT="/Users/yoshiki/tools/go"
GOTMPDIR=""
GOTOOLDIR="/Users/yoshiki/tools/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version devel +b397248168 Sat Dec 1 17:31:02 2018 +0000 darwin/amd64
GOROOT/bin/go tool compile -V: compile version devel +b397248168 Sat Dec 1 17:31:02 2018 +0000
uname -v: Darwin Kernel Version 18.2.0: Fri Oct  5 19:41:49 PDT 2018; root:xnu-4903.221.2~2/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.14.1
BuildVersion:	18B75
lldb --version: lldb-1000.0.38.2
  Swift-4.2
```
Repository: rust
Issue: Unhelpful error message when multiple lifetimes have the same name
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler,D-confusing,D-newcomer-roadblock

I was just looking for some lifetime errors for a project, and I came across the following example:

https://stackoverflow.com/questions/24847331/rust-lifetime-error-expected-concrete-lifetime-but-found-bound-lifetime

The solution in that thread is correct, but the error message is somewhat unhelpful with today's stable and nightly compilers:

```
error[E0308]: method not compatible with trait
  --> src/l3.rs:19:5
   |
19 |     fn to_c(&self, r: &'a Ref) -> Container<'a> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime mismatch
   |
   = note: expected type `fn(&l3::ContainerB<'a>, &'a l3::Ref) -> l3::Container<'a>`
              found type `fn(&l3::ContainerB<'a>, &'a l3::Ref) -> l3::Container<'a>`
note: the lifetime 'a as defined on the method body at 19:5...
  --> src/l3.rs:19:5
   |
19 |     fn to_c(&self, r: &'a Ref) -> Container<'a> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...does not necessarily outlive the lifetime 'a as defined on the impl at 17:6
  --> src/l3.rs:17:6
   |
17 | impl<'a> ToC for ContainerB<'a> {
   |      ^^

error[E0308]: method not compatible with trait
  --> src/l3.rs:19:5
   |
19 |     fn to_c(&self, r: &'a Ref) -> Container<'a> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime mismatch
   |
   = note: expected type `fn(&l3::ContainerB<'a>, &'a l3::Ref) -> l3::Container<'a>`
              found type `fn(&l3::ContainerB<'a>, &'a l3::Ref) -> l3::Container<'a>`
note: the lifetime 'a as defined on the impl at 17:6...
  --> src/l3.rs:17:6
   |
17 | impl<'a> ToC for ContainerB<'a> {
   |      ^^
note: ...does not necessarily outlive the lifetime 'a as defined on the method body at 19:5
  --> src/l3.rs:19:5
   |
19 |     fn to_c(&self, r: &'a Ref) -> Container<'a> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors
```

Basically the problem is that there are two lifetimes called `'a` and the "expected" and "found" types use different `'a`s.
Repository: opencv
Issue: Weird result by using connectedComponentsWithStats 
Labels: category: java bindings,incomplete,needs investigation

##### System information (version)
<!-- Example
- OpenCV => 3.4
- Operating System / Platform => Windows 10 64 Bit
- Compiler => Visual Studio 2012
-->

Here is my testing code:

cv::Mat binTest = cv::Mat(1000, 2000, CV_8UC1,Scalar(255));
//find out connected component
cv::Mat _dstImg, __stat, _centroid;
int cc = cv::connectedComponentsWithStats(binTest, _dstImg, __stat, _centroid, 8, CV_32S,            cv::ConnectedComponentsAlgorithmsTypes::CCL_GRANA);

Results is for __stat:
[2147483647, 2147483647, 2, 2, 0;
 0, 0, 2000, 1000, 2000000]

There are two results by calling that function, but there is only one object in binTest.
Repository: TypeScript
Issue: Generic Type constraint from base classes, interfaces (Pass through)
Labels: Suggestion,Awaiting More Feedback

The ability to allow extends type constraint to be an abstract specification of base class, interface.
This also prevent duplication, by having to define the type constraint twice, reduces the need for unnecessary intermediate interfaces.

```.ts
type ID = string

interface IShape<TID extends ID, Neasted>{
    __ID: TID;
    __Neasted : Neasted
}

interface ITSShape<T, ID>
{
    __tsType: T;
    __ID: ID;
}

interface IShapeType extends IShape<'T', boolean | number | null>
{
}
```
## Not possible
```.ts
interface IShapeTSType<T extends ['__Neasted']> extends IShapeType
{
    __tsType : T;
}


interface IShapeTSType<T extends ['__Neasted']> extends IShape<'T', boolean | number | string>
{
    __tsType : T;
}


interface IShapeTSType<T extends this['__Neasted']> extends IShapeType
{
    __tsType : T;
}

interface IShapeTSType<T extends TShape['__Neasted'], TShape extends IShapeType> extends TShape
{
    __tsType : T;
}
```

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: TypeScript
Issue: cyclic dependency and main/module package.json breaks structural typing
Labels: Bug

**TypeScript Version:**  3.2.1

**Code**

See this repository reproducing the issue: https://github.com/AlexGalays/repro-ts-bug-module-duck

Just call `yarn` and check `index.ts`.

**Expected behavior:**

It should compile

**Actual behavior:**
With the introduction of a cycle in the lib modules (Option.toResult, and Result.toOption) 
an Option from the /es folder is no longer compatible with an Option from the /commonjs folder (which is the reference for typings in package.json) even though they are structurally identical.

![image](https://user-images.githubusercontent.com/1375586/49342806-eb9c1180-f65f-11e8-95cd-22d9848f94f6.png)
Repository: godot
Issue: JSON Parser modifies long numbers
Labels: discussion,topic:core,documentation

**Godot version:**
Version 3.0.6 stable official

**OS/device including version:**
Windows 10 Home 64
NVidia 1060 gtx


**Issue description:**
When a Json string containing a long number of 17 characters or more, it modifies the last numbers after the 16th position and replace them with 0, except for the 17th character which seems to be rounded in a strange way. For instance, the text `{"sessionid":"2178736780526359416"}` will return for sessionid the value `2178736780526359300`
When the number is a string, with quotes, the problem doesn't occur.

**Steps to reproduce:**
run the following code:
`print(JSON.parse('{"sessionid":2178736780526359412}').result.sessionid)`
It will return 2178736780526359300
Repository: rust
Issue: Enable rlib-only libstd build (no dylib)
Labels: A-driver,T-compiler,C-feature-request

For cross-building libstd (for use e.g. with [miri](https://github.com/solson/miri/)), it would be great if one could make an rlib-only libstd build. This is because building a dylib invokes the native linker, and that fails when the target architectures is too foreign and/or not supported by the installed C toolchain. (Currently, we build libstd both as rlib and dylib.)

So my goal was to equip libstd with a feature flag to control whether it is built as a dylib (next to the rlib) or not.  To this end, I patched [`collect_crate_types`](https://github.com/rust-lang/rust/blob/8660eba2b9bec5b0fe971b7281f79e79c2df2fae/src/librustc_driver/driver.rs#L1500) such that the crate types passed on the command-line and the one given as attributes are merged (instead of command-line taking precedence). That means I can use `#![cfg_attr(dylib, crate-type = "dylib")]` to make a `dylib` feature enable a dylib build. That seems to work, however, there is a problem: During bootstrap, rustbuild uses cargo's stamp file to determine which files to copy into the sysroot, and that stamp file now no longer includes the `libstd.so`, breaking the build.

I wonder if there is maybe a better way to achieve an rlib-only libstd build?

Cc @eddyb @alexcrichton any advice?
Repository: kubernetes
Issue: Identify e2e tests that rely on events and thus flaky, rewrite to avoid
Labels: area/test,priority/important-soon,kind/cleanup,kind/flake,sig/testing,lifecycle/frozen,area/deflake

This came up during a recent 1.13 release team meeting.  Event delivery is not actually guaranteed, so any e2e tests that rely on events are susceptible to flakes.  These will become more evident as a cluster is under load.

We should identify which e2e tests are using this anti-pattern, and determine if there is a recipe we can use to rewrite them to be less flaky.  For example, we could likely use polling instead of waiting for an event.

/cc @jberkus 
For any examples of tests that were already identified / fixed 

/area test
/kind cleanup
/priority important-soon
/sig testing
Repository: pytorch
Issue: Advanced indexing slower than numpy
Labels: module: performance,triaged,module: numpy,module: advanced indexing

## 🐛 Bug

Advanced indexing is slower than numpy.

## To Reproduce

Steps to reproduce the behavior:

```python
Python 3.7.0 (default, Oct  9 2018, 10:31:47) 
Type 'copyright', 'credits' or 'license' for more information
IPython 7.0.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import torch                                                                                                                                            

In [2]: torch.__version__                                                                                                                                       
Out[2]: '1.0.0.dev20181202'

In [3]: x = torch.randn(1024)                                                                                                                                   

In [4]: idx = torch.rand(1024) > 0.5                                                                                                                            

In [5]: %%timeit 
   ...: x[idx] 
   ...:                                                                                                                                                   
35 µs ± 63.3 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [6]: x_np, idx_np = x.numpy(), idx.numpy()                                                                                                                   

In [7]: %%timeit 
   ...: x_np[idx_np] 
   ...:                                                                                                                                                 
2.36 µs ± 8.62 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
```

## Expected behavior

PyTorch should be as fast as numpy when doing advanced indexing of tensors that do not require grad.

## Environment

 - PyTorch Version (e.g., 1.0): 1.0.0.dev20181202
 - OS (e.g., Linux): Ubuntu 18.04.1 LTS
 - How you installed PyTorch (`conda`, `pip`, source): conda install pytorch-nightly -c pytorch
 - Python version: 3.7.0


cc @mruberry @rgommers @heitorschueroff @VitalyFedyunin @ngimel
Repository: go
Issue: cmd/compile: minimize morestack calls text footprint
Labels: NeedsInvestigation,compiler/runtime

This is more of a small papercut idea than a real issue, but every time I go through the disassembled output of objdump it comes back to mind, so I'm going to drop it here.

Currently the morestack check is laid out as follows:

```
function entry point:
  check if enough stack
  if not enough stack, jump to morestack block # JMP1
  ...function body...
morestack block:
  call morestack
  jump to function entry point # JMP2
```

if it was instead laid out like this:

```
morestack block:
  call morestack
function entry point:
  check if enough stack
  if not enough stack, jump to morestack block
  ...function body...
```

we have one less jump (JMP2) and, more importantly, JMP1 can always use the more compact rel8 variant. The morestack block, in this case, would be placed in the padding between this and the previous function (because the morestack block of the previous function would have been moved as well, this should not significantly impact the overall amount of padding used)

For small functions (i.e. functions where rel8 is already used in both jumps) this would save 2 bytes per function, for functions where rel32 is used it would save 10 bytes per function. From a quick check there are ~1800 small functions and ~5000 big functions using morestack in the 1.11.2 windows compiler. This means that text size could decrease by ~86KB. This would help for #6853 and, hopefully, also improve icache hit rates.

Looking forward to when per-function metadata will make it possible to mostly eliminate morestack calls (https://github.com/golang/go/issues/25999#issuecomment-400841088), this could be further extended to have multiple entry points (so that we don't need to store multiple variants of functions for which we need both morestack and no morestack variants):

```
morestack block:
  call morestack
function entry point:
  check if enough stack
  if not enough stack, jump to morestack block
function entry point no-morestack:
  ...function body...
```

I'm not knowledgeable about the linker, so I don't really know how workable these two ideas are.
Repository: go
Issue: cmd/compile: statictmps can prevent heap objects from being collected
Labels: GarbageCollector,compiler/runtime

```
package main

import (
	"fmt"
	"runtime"
)

var x = [][]int{[]int{1}}

func main() {
	s := make([]int, 1e8)
	runtime.SetFinalizer(&s[0], func(p *int) { fmt.Println("finalized") })
	x[0] = s
	x = nil
	runtime.GC()
	runtime.GC()
	runtime.GC()
}
```

When I run this program, the finalizer never executes. The big slice will live in the heap forever.

The original state of the program has `x` pointing to a compiler-allocated global variable `statictmp1`. That variable has one `[]int` slot in it, which in turn points to a second `statictmp2` variable holding a single `1`.

When we do `x[0]=s`, we set `statictmp1` to point to the heap instead.  Then when we do `x = nil`, `statictmp1` is now unreachable. But `statictmp1` now points to an object in the heap, and we still scan `statictmp1` at every garbage collection, because it is a global.

If instead we allocated `statictmp1` on the heap, this problem would go away. There's a tradeoff here which I'm not sure how to resolve. The current situation prioritizes fast startup and preferring global data over heap data, but it can result in imprecise retention of objects.

A better fix would be to include a global "object" in the GC marking phase for each global variable. (This is similar to how stack objects work.) Named globals would be in the root set, but unnamed ones like the `statictmp`s would only be live if a heap object or other live global pointed to it.

I'm not sure it is worth fixing this problem. I sort of stumbled on it while working on #29013 but I haven't seen any instances in the wild. Thought it would be worth documenting it here in case someone had a better idea or someone found an actual real-world instance.

Note that a similar situation also applies to `statictmp2`.  After`x[0]=s`, `statictmp2` is dead. We can't collect `statictmp2` because it is allocated in the globals area. We could collect it if it was allocated on the heap. But because it doesn't hold a pointer to heap objects, it isn't a big deal either way. (This also has a parallel to stack objects, which we can't collect directly - we can only ignore their contents.)

@aclements @rlh
Repository: go
Issue: proposal: encoding/asn1: timeParsing functions impose static formats
Labels: Proposal,Proposal-Crypto

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.2 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
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/chris/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/chris/Optus/Git/gorims"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build723180761=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
Attempt to unmarshal generalized time received from a 3rd party system that used a format other than the one hard coded in the parseGeneralizedTime([]byte) (time.Time, error) function.

### What did you expect to see?
A way to nominate the time format to be used


### What did you see instead?
That the time format is hardcoded as a const within the time parsing funcs.
Repository: go
Issue: cmd/go: confusing "build constraints exclude all Go files" error when trying to cross-compile a package that uses CGO
Labels: NeedsInvestigation,GoCommand

`go version`
go version go1.10.4 linux/amd64

`go env`
GOARCH="amd64"
GOBIN="/home/mayurw/go/bin"
GOCACHE="/home/mayurw/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mayurw/go"
GORACE=""
GOROOT="/usr/lib/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.10/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build555451646=/tmp/go-build -gno-record-gcc-switches"

I executed the command
env GOOS=linux GOARCH=arm64 go build
it produced output as bolow
go build github.com/DataDog/zstd: build constraints exclude all Go files in ~/go/src/github.com/DataDog/zstd

I'm really not getting what error it is. Please provide solution to go cross compilation from linux to ARM architecture binaries..
Repository: flutter
Issue: [video_player] Support DRM content
Labels: c: new feature,a: video,customer: crowd,p: video_player,package,team-ecosystem,P2,triaged-ecosystem

Hello Everyone, 

First of Thanks for such a beautiflu Framework. I really loved working in flutter and found it fast and to be much reactive as comared to native Andriod and iOs based application. 

I am creating a VOD platform/ like testing to port out the existing application to Flutter. 
The main issue which I am facing is Playing of DRM (.mpd format with a License URL) content in Flutter using video_player widget. 

Has anybody ttried playing Protected DRM content in Flutter?
Repository: rust
Issue: Allowing different opt-level for different crates of the workspace
Labels: T-cargo,C-feature-request

I have two crates in a workspace: backend server and wasm frontend (and a shared crate for the API types).
I want to use the following profile only for the `frontend` crate:
```toml
[profile.release]
lto = true
opt-level = "z"
```

I only want to optimize my frontend for size, but the backend server for speed.

But:
> warning: profiles for the non root package will be ignored, specify profiles at the workspace root

Why can't this be allowed?

I'd really like to avoid having to split the frontend off into a separate workspace, is there a solution?