sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vue
Issue: Component scope attribute is lost when conditionally rendering root node
Labels: has workaround

### Version
2.5.16

### Reproduction link
[https://codesandbox.io/s/5vj19q8yk](https://codesandbox.io/s/5vj19q8yk)

### Steps to reproduce
1. observe that text is green
2. click two times on checkbox to trigger slot's hide and show cycle


### What is expected?
3. text should still be green

In other words, the toggled `div` should have `GreenSlot`'s `data-v` attribute applied

### What is actually happening?
3. observe that text is red

In other words, the toggled `div` doesn't have correct `data-v` applied.

---
Also tested on beta, issue persists.

In my use-case, I cannot trivially replace it with external `v-if`, as the component that does the toggling contains important internal logic that decides if it should be shown or not. It's not just a simple prop.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: vscode
Issue: Provide an API to track a position in a document across edits
Labels: feature-request,api,editor-api

I've come across a few places where this'd be handy lately. Most recently, I run some tests for my user and I get back positions in the document of where each test is - this allows them to click on the test in the runner/results to jump directly to it.

Unfortunately, if the user modifies their test file then this location information becomes out of date and now jumps the user to the wrong location when they click it. This can be really common - you run your tests; 5 of them fail; you start working through them - working on the first test shifts the position of the tests below such that it's now difficult to jump to them from the test list.

VS Code is presumably already tracking things like this for things like decorations so it'd be nice if we could use it too. For example, imagine an API like this:

```ts
// Get some token that represents a live position in the document
const loc = document.trackLocation(position);

// User makes some edits

// Request the new position
console.log(document.positionOf(loc));
```
Repository: pytorch
Issue: [doc] many losses still mention size_average in formula
Labels: module: docs,module: nn,module: loss,triaged,module: deprecation

e.g., see equation of https://pytorch.org/docs/master/nn.html#torch.nn.KLDivLoss

@li-roy 

cc @jlin27 @mruberry @albanD @jbschlosser
Repository: godot
Issue: Animated mesh strange behaviour
Labels: bug,topic:animation,topic:3d

**Godot version:**
v3.1.dev.custom_build 0b7df80eb1b1f6415b397f0ac115da5014b7b8a8


**OS/device including version:**
Windows 10 x64
Intel HD 4000 & GT 820M


**Issue description:**
I'm currently developing a fps game with huge world, and when i am moving to far location, the mesh got strange result.

Mesh at position 0, 0, 0:
![test6](https://user-images.githubusercontent.com/10296472/42639389-16461bbc-861a-11e8-813a-4b7714fda17a.png)


And when it's transform translated into 2048, 0, 0:
![test4](https://user-images.githubusercontent.com/10296472/42639228-b492863a-8619-11e8-93b5-bf274026e51f.png)


It was not happening when the mesh doesn't belong to armature node or exported without animation.
![test5](https://user-images.githubusercontent.com/10296472/42639526-6556aad2-861a-11e8-999b-e1958a03d62f.png)


**Steps to reproduce:**
1. Import an animated mesh, then instance it into the scene.
2. Translate the mesh x origin to 2048 or more.
3. See the magic happens.

**Minimal reproduction project:**
[sample.zip](https://github.com/godotengine/godot/files/2188870/sample.zip)
Repository: react-native
Issue: VirtualizedList- inefficient function passing for CellRenderer
Labels: JavaScript,Help Wanted :octocat:,Resolution: PR Submitted,Component: VirtualizedList,Bug,Newer Patch Available

<!-- Requirements: please go through this checklist before opening a new issue -->
  - [x] Review the documentation
  - [x] Search for existing issues
  - [ ] Use the latest React Native release - *using version 0.55.2 did not see any changes to the FlatListComponent since that version.*

## Environment
Run `react-native info` in your terminal and paste its contents here.
```
Environment:
  OS: Windows 10
  Node: 8.11.1
  Yarn: 0.21.3
  npm: 5.8.0
  Watchman: Not Found
  Xcode: N/A
  Android Studio: Version  3.0.0.0 AI-171.4408382

Packages: (wanted => installed)
  react: 16.3.1 => 16.3.1
  react-native: ^0.55.2 => 0.55.4

```
## Description
I used the npm package why-did-you-update to help optimize my components and prevent re-renders. However there is a re-render that I cannot control. This happens for every item in the list.  My gues

```
CellRenderer.props: Changes are in functions only. Possibly avoidable re-render?
Functions before: {onLayout: ƒ}
Functions after: {onLayout: ƒ}
```

It seems this is caused by an anonymous function at https://github.com/facebook/react-native/blob/d756d94b3a7e2812f17f549c57767ac63734b49c/Libraries/Lists/VirtualizedList.js#L691

I propose that this function be defined on the class to prevent unnecessary re-renders.
Repository: TypeScript
Issue: Services for non-homomorphic mapped type
Labels: Suggestion,Help Wanted,Domain: Mapped Types,Experience Enhancement,Domain: Symbol Navigation

**TypeScript Version:**  3.0.0-dev.20180712

**Code**

```ts
interface I {
 a: number;
 b: number;
}
type J = { [K in "b"]: I[K] };
declare const j: J;
j.b; // Go-to-definition does not work
```

**Expected behavior:**

Since the type we're getting is `I[K]`, the mapped property symbol should have a reference back to the corresponding property in `I`.

**Actual behavior:**

The mapped type creates an unrelated property symbol and services don't work.
Repository: TypeScript
Issue: Allow regular flags to mix with --build
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  `3.0.0-rc`, `3.0.0-dev.20180712`

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** 

build mode, --build

**Code**

I have project with the following `tsconfig.json`:

```json
{
    "compilerOptions": {
        "module": "commonjs",
        "moduleResolution": "node",
        "target": "es2017",
        "lib": ["es2017"],
        "strict": true,
        "sourceMap": true,
        "noEmitOnError": true,
        "types": ["node"]
    },
    "include": [
        "src/**/*.ts"
    ]
}
```

and compile it with command:

```
node_modules/.bin/tsc --build tsconfig.json --outDir out --rootDir /home/kostya/proj/foo
```

Note, that `outDir` and `rootDir` options come from command line arguments, because I want to share output directory for another command (`clean`).

**Expected behavior:**

`outDir` and `rootDir` options will be took from command line.

**Actual behavior:**

Compiler ignores this options:

```
node_modules/.bin/tsc --build tsconfig.json --outDir out --rootDir /home/kostya/proj/foo
message TS6096: File '/home/kostya/proj/foo/--outDir' does not exist.

message TS6096: File '/home/kostya/proj/foo/out' does not exist.

message TS6096: File '/home/kostya/proj/foo/--rootDir' does not exist.
```

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> 

**Related Issues:** <!-- Did you find other bugs that looked similar? --> https://github.com/Microsoft/TypeScript/issues/25600
Repository: go
Issue: net/http: test WebAssembly Fetch implementation of Transport
Labels: Testing,help wanted,NeedsFix,arch-wasm

While taking a look at CL https://go-review.googlesource.com/c/go/+/123537 for https://github.com/golang/go/issues/26349, a recommendation was that we should add tests to avoid regressions such as in that issue raised. @bradfitz added a reminder in https://github.com/golang/go/issues/26051#issuecomment-404644951
Repository: TypeScript
Issue: In JS, `object` is treated as 'any'
Labels: Suggestion,Domain: lib.d.ts,Awaiting More Feedback,Domain: JSDoc,checkJs,Domain: JavaScript

**TypeScript Version:**  3.0.0-dev.20180711

**Code**

```ts
/** @typedef {object} T */
/** @type {T} */
const x = 0;
```

**Expected behavior:**

Error at `x`: `0` is not an object.

**Actual behavior:**

No error.
Repository: pytorch
Issue: [feature request] Make `torch.gather` broadcastable.
Labels: triaged,function request

Currently, `torch.gather` does not broadcast. For example:
```python
t = torch.tensor([[1,2],[1,2]])
torch.gather(t, 1, torch.tensor([[0,1,0],[0,1,0]]))
```
gives
```
tensor([[ 1,  2,  1],
        [ 1,  2,  1]])
```

But

```python
t = torch.tensor([[1,2],[1,2]])
torch.gather(t, 1, torch.tensor([[0,1,0]]))
```
and
```python
t = torch.tensor([[1,2]])
torch.gather(t, 1, torch.tensor([[0,1,0],[0,1,0]]))
```
gives runtime errors.

It would be more convenient to allow broadcasting on every dimension except the dim specified as the second argument in gather, so that the above two codes can give the same result as the first code.

Does this proposal sound good? If yes, I can work on it.
Repository: go
Issue: x/image/tiff: compressed tiffs are invalid (at least on Mac OS X)
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

go version go1.10.3 darwin/amd64

### Does this issue reproduce with the latest release?

I'm on go1.10.

### What operating system and processor architecture are you using (`go env`)?

```
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/xxx/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/xxx/projects/go"
GORACE=""
GOROOT="/usr/local/opt/go/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/kc/_mt5mw0j5ksfg846hgllc5lr0000gn/T/go-build015281372=/tmp/go-build -gno-record-gcc-switches -fno-common"
```

### What did you do?

[Here is a reproduction case.](https://github.com/cantino/tiff_bug)

### What did you expect to see?

A valid white tiff.

### What did you see instead?

A system error.
Repository: pytorch
Issue: [feature request] allow forward_pre_hook to "preprocess" input
Labels: todo,feature,triaged

basically allowing returning new input tensor(s)
Repository: opencv
Issue: opencv_createsamples consistently failing on Ubuntu 16.04.4
Labels: category: apps,incomplete

- OpenCV => 3.4.2
- Operating System / Platform => Ubuntu 16.04.4
- Compiler => GCC

The following command:
` opencv_createsamples -bgcolor 0 -bgthresh 0 -maxxangle 1.1 -maxyangle 1.1 -maxzangle 0.5 -maxidev 40 -w 25 -h 25 -num 100 -img filename.tif  -bg filelist.txt -vec filename.vec `

Consistently fails with `Segmentation fault` . Checked all files, and command line options. Can be reproduced with any typical setup.
Repository: vscode
Issue: [json] package.json: complete package versions from scopes or private registries
Labels: feature-request,json

While there are numerous issues explaining that package _names_ cannot be autocompleted for scopes on the official registry or for private registries, that doesn't mean you shouldn't be able to autocomplete package _versions_.

And I'd argue that atleast for private registries autocompleting the version is generally more important than autocompleting the name. The name is usually well known for internal dependencies. But the version range available; that not so much...

Anyway, for scoped packages and even for scopes that are redirected to other registries using `registry` entries in `.npmrc`, the versions can be gotten from a simple `npm view` command, which returns a JSON structure that also holds all of a package's versions. No reason the functionality for that command couldn't be tapped for autocompletion as well.
Repository: vscode
Issue: Allow diagnostics messages to have markdown (or formatted text) content
Labels: feature-request,api,languages-diagnostics

**Feature request**
Allow diagnostics to display formatted content. The specific request was to show part of a diagnostic message in bold.

A few potential options:

- Allow diagnostics to use markdown content
- Allow diagnostics to use formatted text 
- Add an "important span" to diagnostic messages that lets us control the styling of the diagnostic.

(This request came out of the FB meeting)
Repository: flutter
Issue: Add API for asynchronously loading a font
Labels: c: new feature,framework,engine,c: performance,P2,team-engine,triaged-engine

Please see the following timeline trace (produced by our client in https://github.com/flutter/flutter/issues/813#issuecomment-404830195):
[Archiv.zip](https://github.com/flutter/flutter/files/2193775/Archiv.zip)

There's a 100ms jank caused by font loading:
![image](https://user-images.githubusercontent.com/22987568/42707667-df19e300-868f-11e8-8887-5c1d760e3b9d.png)
Repository: pytorch
Issue: Build error: cannot find -lonnxifi_loader
Labels: module: build,triaged

On master.

It also seems `python3 setup.py install` still tries to build Caffe2:
```
[ 61%] Linking CXX shared library ../lib/libcaffe2.so
/usr/bin/ld: cannot find -lonnxifi_loader
collect2: error: ld returned 1 exit status
caffe2/CMakeFiles/caffe2.dir/build.make:2382: recipe for target 'lib/libcaffe2.so' failed
make[2]: *** [lib/libcaffe2.so] Error 1
CMakeFiles/Makefile2:1282: recipe for target 'caffe2/CMakeFiles/caffe2.dir/all' failed
make[1]: *** [caffe2/CMakeFiles/caffe2.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
Failed to run 'bash tools/build_pytorch_libs.sh --use-cuda --use-nnpack --use-mkldnn nccl caffe2 nanopb libshm gloo THD c10d'
```

cc @malfet @seemethere @walterddr
Repository: flutter
Issue: Unmount everything and dispose States when host activity dies 
Labels: c: new feature,framework,engine,P2,team-engine,triaged-engine

Looking at #19159, it seems reasonable looking at the API doc to expect the State.dispose to be called when the FlutterActivity is finishing/being destroyed. Yet it never gets called and there's an inbalance between things registered and/or created during initState() and things unregistered and/or released during dispose().

Should we:

1. Have FlutterView also handle onDestroy() (and equivalent on iOS)
2. Have a new AppLifecycleState for finishing
3. Have the widget framework unmount and dispose everything on onDestroy

or at least have the State.dispose() API doc reference AppLifecycleState if we don't want to do this automatically?

cc @Hixie @jason-simmons 
also cc @matthew-carroll since this scenario will surface more frequently with add-to-app
Repository: go
Issue: cmd/compile: consider using DWARF 5
Labels: NeedsDecision,Debugging

DWARF 5 has several advantages over previous versions of DWARF. Notably,

1. It supports position-independent representations, which significantly reduces the number of relocations in object files and hence the size of object files and the load on the linker. In the `go` binary, 49% of the 503,361 total relocations are in the DWARF.

2. It supports much more compact location and range list formats. The location and range list sections are 6% of the 12MiB of the `go` binary, even when zlib compressed.

3. It has an official language code for Go. :)

DWARF 5 is quite new, and I don't think the rest of the ecosystem is ready yet, but I wanted to get the idea floating. It is supported by the GNU and LLVM toolchains and some debuggers. Support was added in [GCC 7.1](https://gcc.gnu.org/gcc-7/changes.html) (May 2017) and [GDB 8.0](https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gdb/NEWS;hb=gdb-8.0-release) (June 2017). It appears to be in the latest LLVM, which covers most of the Xcode tools, though I can't find when it was added.

It is currently *not* supported by LLDB or the macOS linker. We could potentially get around the macOS linker by leaving out the Go DWARF from the objects we pass to the system linker and then merging it in to the final binary (we already do a merge step). This is more feasible with DWARF5 because it's mostly position-independent, so we wouldn't need dsymutil to relocate it for us.

/cc @cherrymui @heschik @dr2chase @randall77 @ianlancetaylor
Repository: rust
Issue: Dropping unused and unreferenced external crate should not trigger recompile
Labels: C-enhancement,I-compiletime,T-compiler,A-incr-comp,WG-incr-comp

After compiling a project that has a reference to an external crate in `Cargo.toml` but that is not imported (no `extern crate foo;`), a subsequent `cargo build` after dropping the unused dependency from `Cargo.toml` triggers a full rebuild.

Unless the removal triggers a change in the version of a different dependency in the lock file (which I don't think can currently happen in this scenario), a recompile should be skipped.

(I'd even go further and say that a remote crate imported with `extern crate foo` or even `#[macro_use] extern crate foo;` that is not actually used and does not introduce build scripts, etc. should also not trigger a rebuild, but that is at least understandable as it can affect type negotiations, etc. in which case it should be more of an "early abort" once the AST has been formed and [it becomes possible to determine that no types have changed](https://github.com/rust-lang/rust/issues/52122).)
Repository: rust
Issue: Warn about #[macro_export] mod m?
Labels: C-enhancement,A-attributes,A-lints,T-compiler,D-papercut

I haven't used macros that often, but had to make changes in a 3rd party project. 

During refactoring I tried to import macros from another module. I knew I had to add `macro_use`, `macro_export` somehow, but couldn't remember details.

While `rustc` was somewhat helpful in warning me on my first attempt:

```
error: cannot find macro `test!` in this scope
 --> src/x/u/u.rs:5:1
  |
5 | test! {
  | ^^^^^^^^^^
  |
  = help: have you added the `#[macro_use]` on the module/import?

```

It did not warn me about doing this:

```
#[macro_export] 
mod m;
```

where in reality I should have done that:

```
#[macro_use] 
mod m;
```

This was particularly confusing since the used macro was a few modules down in the hierarchy, and I should have done `#[macro_use]` on each level. Since I wasn't warned, I assumed `#[macro_export] mod m;` was correct. Instead, I tried a few permutations adding `#[macro_use]` to other places,  which all didn't work out. 

Two things that would have worked for me:

- Warn about `#[macro_export] mod m;`
- Make the help text above more explicit, e.g., by suggesting that `macro_use` needs to be added to all parent modules (maybe with a link to the [error index](https://doc.rust-lang.org/error-index.html))

Update: using `rustc 1.29.0-nightly (9fd3d7899 2018-07-07)`
Repository: opencv
Issue: float numbers are not supported by CV_CheckEQ
Labels: feature,category: core

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => latest


##### Detailed description
See the code
https://github.com/opencv/opencv/blob/fa66c6b797416292e2c6befb60b34b6ba0420499/modules/core/include/opencv2/core/check.hpp#L110-L111

The comment says `CV_CheckTypeEQ` supports `float` and `double`. However, the implementation
is https://github.com/opencv/opencv/blob/fa66c6b797416292e2c6befb60b34b6ba0420499/modules/core/include/opencv2/core/check.hpp#L85

which is not correct to compare two floats using `==`.

##### Steps to reproduce
The following code
```.cpp
CV_CheckEQ(1.2, 0.2*6, "your message");
```
should be valid according to the above comment, but it throws.

##### Possible solutions
Provide a macro like
```.cpp
CV_CheckDoubleEQ(value1, value2, eps, msg)
```

`glog` provides `CHECK_EQ`, `CHECK_DOUBLE_EQ` and `CHECK_NEAR`.

https://github.com/google/glog/blob/367518f65049da0e53123d98eb24e56674a5c57e/src/glog/logging.h.in#L836-L846

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: rust
Issue: rustc_target, rustc_codegen_llvm: use () for the metadata of pointers to extern { type }s.
Labels: C-enhancement,A-codegen,E-mentor,T-compiler,A-layout

Right now we check in a bunch of places (with, e.g. `type_has_metadata`) whether an unsized type has no metadata, i.e. its pointer is like a regular pointer to sized types, and this is only the case for the new `extern { type Foo; }` opaque FFI types.

What we could do instead, at the same time to simplify some the code handling these, and to make progress on custom DSTs, is to treat pointers to such types as having metadata of `()`, i.e. they'd be `(*data, ())` pairs, which are still represented as just a pointer, but backends can handle the second field uniformly across all the unsized types (`extern { type }`, slices, `dyn Trait`).

The main reason we can reuse a lot of the existing code is that `()` can be represented as an immediate value in LLVM already. This trick would not work for custom DSTs with non-immediate metadata types, e.g. `(usize, usize, usize)` for a 2D matrix "slice" would require some indirection.
But it is useful to start challenging the assumption that the metadata is pointer-sized.

cc @rust-lang/compiler @plietar @mikeyhew
Repository: pytorch
Issue: PredictorTest.SimpleBatchSizedMapInput intermittently hangs
Labels: caffe2

Example: https://ci.pytorch.org/jenkins/job/caffe2-builds/job/py2-cuda9.0-cudnn7-ubuntu16.04-test/8089/console

```
13:19:14 [ RUN      ] PredictorTest.SimpleBatchSizedMapInput
13:19:14 I0714 13:19:14.288452   208 net_dag_utils.cc:102] Operator graph pruning prior to chain compute took: 2.162e-06 secs
13:19:14 I0714 13:19:14.288487   208 net_async_base.cc:430] Using estimated CPU pool size: 32; NUMA node id: -1
13:19:14 I0714 13:19:14.288497   208 net_async_base.cc:440] Created new CPU pool, size: 32; NUMA node id: -1
14:03:46 Build timed out (after 45 minutes). Marking the build as failed.
```