sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react-native
Issue: TypeError: global.nativeTraceBeginSection is not a function (Systrace)
Labels: Bug

### Is this a bug report?

Yes

### Have you read the Bugs section of the Contributing to React Native Guide?

Yes

### Environment

1. `react-native -v`: react-native-cli: 2.0.1, react-native: 0.46.1
2. `node -v`: v7.10.0
3. `npm -v`: 4.6.1
4. `yarn --version` (if you use Yarn): Not used in this bug

Then, specify:

- Target Platform: iOS

- Development Operating System: macOS Sierra v 10.12

- Build tools: Xcode Version 8.3.3 (8E3004b)

I'm running `react-native run-ios` deploying to iOS emulator Version 10.0 (SimulatorApp-745.10), running iOS 10.3 in an iphone 6.

### Steps to Reproduce

(Write your steps here:)

1. Run `react-native run-ios` with Systrace enabled

<img width="375" alt="dev_menu" src="https://user-images.githubusercontent.com/11222413/28170878-0d1b6aaa-67bd-11e7-9fd5-5ac653e9e00e.png">

2. Reload your app (manually or with live/hot reload)

3. Check the logs

### Expected Behavior

The app should reload normally.

### Actual Behavior

The error `TypeError:global.nativeTraceBeginSection` gets launched into the console:

![console_error](https://user-images.githubusercontent.com/11222413/28171212-13ba754e-67be-11e7-8543-f86e2a118081.png)

And in the UI: 

<img width="375" alt="ui_error" src="https://user-images.githubusercontent.com/11222413/28171066-ad90d18c-67bd-11e7-92e3-61c394823f27.png">

After that, the whole emulator crashes and the only way to restore it is running `react-native run-ios` again. 
One temporary **workaround** to get rid of this error is disabling `Systrace` in the DevMenu, but this is less than ideal.

### Reproducible Demo

https://snack.expo.io/ryCtYZHrZ

**Observation:** Even though I included a snack, I'm afraid you can't fully reproduce this problem without a Mac and an iOS emulator, the reason being that the `Systrace` is not an Expo function.
Repository: flutter
Issue: Consider not pushing intermediate routes when pushing an initial route with hierarchical structure.
Labels: framework,f: routes,c: proposal,P2,team-framework,triaged-framework

Currently pushing an initial route with hierarchical structure implies a push for each part of the route name. E.g. having an initial route named `'/a/b'` implies pushes of `'/'`, `'/a'`, `'/a/b`. This is the behavior when navigating in directory structures but maybe not the intuitiv behavior for app navigation? Usually navigating up on a phone, means navigating in reverse chronological order, through the history of screens that the user has recently seen, as is the case when pressing back in a browser. Hence, I think we should reconsider these implicit pushes.

Any thoughts @Hixie, @collinjackson, @jakobr-google ?
Repository: go
Issue: cmd/asm, runtime: textflag for CABI
Labels: help wanted,NeedsFix

The runtime assembly code includes many functions that are called from outside the runtime and are called with the C ABI. This means the functions first have to save callee-saved registers manually.

For example, see runtime·sigtramp in sys_linux_*.s.

Once after diagnosing a callee-save error, I failed to save all the callee-save registers. This meant months later, @aclements had to go through the same long debugging session. We could make this more robust (and potentially make our assembly a bit easier to read) by adding a CABI text flag, and have the assembler insert code for saving and restoring registers.

cc @ianlancetaylor
Repository: kubernetes
Issue: emptyDir with medium: Memory mounts a tmpfs volume without nosuid,nodev,noexec
Labels: kind/bug,area/security,sig/storage,kind/feature,lifecycle/frozen

<!-- This form is for bug reports and feature requests ONLY! 

If you're looking for help check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) and the [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/).
-->

**Is this a BUG REPORT or FEATURE REQUEST?**:

> Uncomment only one, leave it on its own line: 
>
/kind bug
> /kind feature


**What happened**:
```bash
$ kubectl exec -ti demo-1986931840-cxt6m -- sh
/ # mount | grep tmpfs
tmpfs on /dev type tmpfs (rw,nosuid,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /tmp type tmpfs (rw,relatime)  # mounted using emptyDir
tmpfs on /var/run type tmpfs (rw,relatime)  # mounted using emptyDir
tmpfs on /var/run/secrets/kubernetes.io/serviceaccount type tmpfs (ro,relatime)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
tmpfs on /proc/kcore type tmpfs (rw,nosuid,mode=755)
tmpfs on /proc/timer_stats type tmpfs (rw,nosuid,mode=755)
```
**What you expected to happen**:
```bash
$ docker run --rm --read-only --tmpfs /tmp debian:9 mount | grep "nosuid,nodev,noexec" | grep tmpfs
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,relatime,mode=755)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,relatime)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
```
**How to reproduce it (as minimally and precisely as possible)**:


**Anything else we need to know?**:
It is recommended to mount tmpfs with `nosuid,noexec,nodev` options.


**Environment**:
- Kubernetes version (use `kubectl version`): Client Version: v1.7.0 Server Version: v1.6.4
- Cloud provider or hardware configuration**: minikube
- OS (e.g. from /etc/os-release):
- Kernel (e.g. `uname -a`):
- Install tools:
- Others:
Repository: rust
Issue: Extend stack probe support to non-tier-1 platforms, and clarify policy for mitigating LLVM-dependent unsafety
Labels: A-LLVM,C-enhancement,A-codegen,P-medium,T-compiler,I-unsound,E-needs-mcve,A-stack-probe

As of https://github.com/rust-lang/rust/pull/42816 , all (current) tier-1 platforms are protected against the potential memory unsafety demonstrated in https://github.com/rust-lang/rust/issues/16012 . However, this protection is dependent upon platform-dependent LLVM support, so AFAIK most of our supported tier-2 and tier-3 platforms ( https://forge.rust-lang.org/platform-support.html ) are still theoretically unprotected.

Proper resolution of this issue will depend on extending LLVM's stack probe support for various platforms, (which should be done regardless of the discussion in the next paragraph). See https://reviews.llvm.org/D34387 for pcwalton's original x86 implementation, https://reviews.llvm.org/D34386 for the implementation of the attribute itself, and https://github.com/rust-lang/rust/pull/42816 for the work needed on rustc's side.

But here's the more important concern: the list of potential platforms is unbounded, and we need to decide where to draw the line. As minor as the safety hole may be, is it an abrogation of Rust's claim to guarantee memory safety if that safety is only enforced on "popular" platforms? If so, is it worth considering some sort of blanket check that can be implemented in the frontend for use only on platforms where stack probes are unimplemented? For instance, given that we statically know the stack size of all types, could we perhaps enforce an upper bound on the size of a type (perhaps only in debug mode)? I think this discussion may be relevant to https://github.com/rust-lang/rust/issues/10184 as well.
Repository: rust
Issue: Tracking issue for Vec::extract_if and LinkedList::extract_if
Labels: A-collections,T-libs-api,B-unstable,C-tracking-issue,disposition-merge,finished-final-comment-period,Libs-Tracked

Feature gate: `#![feature(extract_if)]` (previously `drain_filter`)

This is a tracking issue for `Vec::extract_if` and `LinkedList::extract_if`, which can be used for random deletes using iterators.

### Public API

```rust
pub mod alloc {
    pub mod vec {
        impl<T, A: Allocator> Vec<T, A> {
            pub fn extract_if<F>(&mut self, filter: F) -> ExtractIf<'_, T, F, A>
            where
                F: FnMut(&mut T) -> bool,
            {
            }
        }

        #[derive(Debug)]
        pub struct ExtractIf<'a, T, F, #[unstable(feature = "allocator_api", issue = "32838")] A: Allocator = Global>
        where
            F: FnMut(&mut T) -> bool, {}

        impl<T, F, A: Allocator> Iterator for ExtractIf<'_, T, F, A>
        where
            F: FnMut(&mut T) -> bool,
        {
            type Item = T;
            fn next(&mut self) -> Option<T> {}
            fn size_hint(&self) -> (usize, Option<usize>) {}
        }

        impl<T, F, A: Allocator> Drop for ExtractIf<'_, T, F, A>
        where
            F: FnMut(&mut T) -> bool,
        {
            fn drop(&mut self) {}
        }
    }

    pub mod collections {
        pub mod linked_list {
            impl<T> LinkedList<T> {
                pub fn extract_if<F>(&mut self, filter: F) -> ExtractIf<'_, T, F>
                where
                    F: FnMut(&mut T) -> bool,
                {
                }
            }

            pub struct ExtractIf<'a, T: 'a, F: 'a>
            where
                F: FnMut(&mut T) -> bool, {}

            impl<T, F> Iterator for ExtractIf<'_, T, F>
            where
                F: FnMut(&mut T) -> bool,
            {
                type Item = T;
                fn next(&mut self) -> Option<T> {}
                fn size_hint(&self) -> (usize, Option<usize>) {}
            }

            impl<T, F> Drop for ExtractIf<'_, T, F>
            where
                F: FnMut(&mut T) -> bool,
            {
                fn drop(&mut self) {}
            }

            impl<T: fmt::Debug, F> fmt::Debug for ExtractIf<'_, T, F>
            where
                F: FnMut(&mut T) -> bool,
            {
                fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {}
            }
        }
    }
}
```

### Steps / History

- [x] Implementation: #43245
- [x] removed drain-on-drop behavior, renamed to extract_if
   - #104455
   - https://github.com/rust-lang/libs-team/issues/136
- [ ] Stabilization PR

### Unresolved Questions

- What should the method be named?
- Should `extract_if` accept a `Range` argument?
- Missing `Send`+`Sync` impls on linked list's ExtractIf, [see comment](https://github.com/rust-lang/rust/issues/43244#issuecomment-1268857915)

See https://github.com/rust-lang/rust/issues/43244#issuecomment-641638196 for a more detailed summary of open issues.
Repository: TypeScript
Issue: Type-check jsdoc-annotated property assignments
Labels: Bug,Domain: JSDoc,Domain: JavaScript

**TypeScript Version:**  nightly (2.5.0-dev.20170712)

**Code**

```ts
// @ts-check

/** @type {string} */
exports.x = 1;
```

**Expected behavior:**

Error.

**Actual behavior:**

No error.
And if I import `x` in another module, it is typed as `string`.
Repository: rust
Issue: Coroutine tracing of borrows is quite conservative
Labels: C-enhancement,T-compiler,A-coroutines,F-coroutines

This example really should work, but does not:

```rust
fn yield_during_range_iter() {
    // Should be OK.
    let mut b = || {
        let v = vec![1,2,3];
        for i in 0..v.len() {
            yield v[i];
        }
    };
    b.resume();
}

fn main() { }
```

I get:

```
error[E0624]: borrow may still be in use when generator yields
  --> /home/nmatsakis/versioned/rust-1/src/test/ui/generator/yield-while-iterating.rs:75:21
   |
75 |         for i in 0..v.len() {
   |                     ^
76 |             yield v[i];
   |             ---------- possible yield occurs here

error[E0624]: borrow may still be in use when generator yields
  --> /home/nmatsakis/versioned/rust-1/src/test/ui/generator/yield-while-iterating.rs:76:19
   |
76 |             yield v[i];
   |             ------^--- possible yield occurs here
```

I think the problem is that the current code for deciding which temporaries are in scope is quite overly conservative. (On a related note, we also have to unconditionally throw booleans into the mix because of drop flags.)

cc @Zoxc @alexcrichton
Repository: youtube-dl
Issue: Add support for videos saved with Internet Archive Wayback Machine 
Labels: site-support-request

## Please follow the guide below

- You will be asked some questions and requested to provide some information, please read them **carefully** and answer honestly
- Put an `x` into all the boxes [ ] relevant to your *issue* (like that [x])
- Use *Preview* tab to see how your issue will actually look like

---

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2017.07.15*. If it's not read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.07.15**

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [x] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---

Heres some examples of URL's saved with wayback:
https://web.archive.org/web/20150517183426/https://www.youtube.com/watch?v=V46KYxFav24
https://web.archive.org/web/20071015051038/http://youtube.com:80/watch?v=JdLCEwEFCMU
https://web.archive.org/web/20110531000748/http://www.youtube.com/watch?v=bVUnpkvgHaw&gl=US&hl=en&amp;has_verified=1
Repository: TypeScript
Issue: Support `@abstract` JSDoc tag
Labels: Suggestion,Domain: JavaScript,Experience Enhancement

**TypeScript Version:**  nightly (2.5.0-dev.20170712)

**Code**

```ts
/** @abstract */
class C {}
new C();
```

**Expected behavior:**

Error.

**Actual behavior:**

No error.
Repository: go
Issue: sync: reduce pointer overhead in Map
Labels: Performance,compiler/runtime

The Go 1.9 implementation of `sync.Map` is very pointer-heavy. That wastes a bit of CPU (following and caching those pointers and their address translations) and also consumes more steady-state memory than it potentially needs to (by at least one pointer per entry).

Now that `sync.Map` is in the standard library (instead of just `x/sync`), we can potentially make use of knowledge about the runtime implementations of `map`, `interface{}` and/or `atomic.Value` to flatten out some of those pointers.

In particular we can probably change the `readOnly.m` field to contain a `runtime.hmap` directly instead of a `map` variable that points to it.

We may also be able to change the elements of that map from `*entry` to `entry`, since their addresses will be stable (unless we address https://github.com/golang/go/issues/19094). It's not obvious to me whether that would add too much complexity to the process of promoting the read-write map to read-only (which is currently just an atomic store): in particular, we would need some way to ensure that no thread is trying to update the entries of the previous read-only map, which might require that we only promote read-write to read-only during a GC safe-point.

Finally, we may be able to store `interface{}` values directly in the `entry` struct rather than unsafe-pointers-to-interfaces, although (as `atomic.Value` demonstrates) the synchronization for updates may be very subtle.

Further pointer optimizations may be possible; those are just the ones I can think of.

----

I don't intend to do this optimization work myself any time soon, but I wanted to document this idea in case someone else in the community has a use-case that motivates them to address it.
Repository: go
Issue: sync: reduce (*Map).Load penalty for Stores with new keys
Labels: Performance,compiler/runtime

In the Go 1.9 implementation of `sync.Map`, storing _any_ new key in the map causes `Load` calls on _all_ new keys to acquire a mutex until enough misses have occurred to promote the read-write map again.

That's probably fine for append-only maps (such as the `sync.Map` uses in the standard library), because it goes away in the steady state. However, it's problematic for use in caches, where there may be frequent `Load` and `Store` calls for keys that miss the cache.

I suspect we could substantially reduce the `Load` penalty by using a Bloom or HyperLogLog filter instead of a simple boolean to store the set of new keys: a `Load` that misses in the read-only map would still have more cache misses due to writes to the filter, but it would no longer block `Store` calls or contend with other `Load`s.
Repository: go
Issue: all: add a few READMEs to help new people navigate the source tree
Labels: Documentation,NeedsFix

The api directory has a friendly README file in it explaining what's in it. We should add short READMEs to some of the other top-level directories, particularly doc, lib, misc, and test.
Repository: go
Issue: sync: reduce contention between Map operations with new-but-disjoint keys
Labels: Performance,compiler/runtime

The Go 1.9 implementation of `sync.Map` uses a single `Mutex` to guard the read-write map containing new keys. That makes `Store` calls with different new keys always contend with each other, and also contend with `Load` calls with different new keys, even if the `Load`s and `Store`s for each key are confined to a single thread.

That doesn't really matter for the `sync.Map` use-cases in the standard library because they do not operate on new keys in the steady state, but it limits the utility of `sync.Map` for use-cases involving a high rate of churn. Such use-cases may include:
* caches with high eviction rates, such as caches fronting key-value storage services
* maps of RPC or HTTP stream ID to handler state
* maps of opaque handles to Go pointers in order to write C-exported APIs that comply with [cgo pointer-passing](https://golang.org/cmd/cgo/#hdr-Passing_pointers) rules

We should explore ways to address new-key contention, such as sharding the read-write maps and associated locks (as suggested in https://github.com/golang/go/issues/20360), journaling writes (and using a Bloom or HyperLogLog filter to avoid reading the journal, along the lines of https://github.com/golang/go/issues/21032), or storing the read-write map in an atomic tree data structure instead of a built-in `map`.
Repository: vscode
Issue: Can the VSCode gutter be made smaller, i.e., decreased size/width?
Labels: feature-request,editor-core

<!-- Do you have a question? Please ask it on http://stackoverflow.com/questions/tagged/vscode. -->

<!-- Use Help > Report Issues to prefill these. -->
- VSCode Version: 1.14.1
- OS Version: Windows 10 build 15063

Comparing Sublime Text gutter with VSCode gutter, we conclude the VSCode gutter is too big.

**Sublime Text**
![image](https://user-images.githubusercontent.com/5332158/28245748-85e48dd6-69e3-11e7-86af-66bd172b158a.png)

**Notepad++**
![image](https://user-images.githubusercontent.com/5332158/28245825-685afdd4-69e5-11e7-8213-ce25215f9856.png)

**VSCode**
![image](https://user-images.githubusercontent.com/5332158/28245692-17eb3bcc-69e3-11e7-9341-c05cb50aaf06.png)


Can the VSCode gutter be made smaller, i.e., decreased size/width?


___

This question can be found on StackOverflow:

1. [How do I change the Gutter Width in VS Code?](https://stackoverflow.com/questions/43957564/how-do-i-change-the-gutter-width-in-vs-code)
Repository: go
Issue: cmd/go: do not ignore explicit _foo.go argument
Labels: NeedsFix

```
go version go1.8.3 linux/amd64
GOPATH="/home/lion/aosc/ciel"
PWD="/home/lion/aosc/ciel"
```

### What did you do?
```
go fmt src/ciel/_main.go
go vet src/ciel/_main.go
go generate src/ciel/_main.go
...
```

### What did you expect to see?
Take `go fmt` as the example.
It should do something like `go fmt src/ciel/anotherfile.go`.

### What did you see instead?
`can't load package: package main: no buildable Go source files in /home/lion/aosc/ciel/src/ciel`

I understand `_file` will be ignored by go tools when I specified a package:
https://godoc.org/cmd/go/#hdr-Description_of_package_lists
> Directory and file names that begin with "." or "_" are ignored by the go tool, as are directories named "testdata".

But, according to the context, this rule is for package, when I pass a file name to argument explicitly, it should not ignore them. 

I think this maybe relevant to `go/build.Context.UseAllFiles`.

https://godoc.org/pkg/go/build/#Context
```
type Context struct {
    GOARCH      string // target architecture
    GOOS        string // target operating system
    GOROOT      string // Go root
    GOPATH      string // Go path
    CgoEnabled  bool   // whether cgo can be used
    UseAllFiles bool   // use files regardless of +build lines, file names
    Compiler    string // compiler to assume when computing target paths
```
Repository: pytorch
Issue: [Feature request] truncated normal initializer(sampler)
Labels: triaged,enhancement,module: initialization

There has been a recent discussion on the discuss about truncated normal initializer [link](https://discuss.pytorch.org/t/implementing-truncated-normal-initializer/4778/15).
I have implemented one on my own, but the code is basically paraphrasing the tensorflow code, which I feel like may cause problem. If you feel good to add this, I can submit a PR once you tell me if it's ok to paraphrase or what's the alternative.
Repository: kubernetes
Issue: Orphaned objects can remain after their namespace is removed
Labels: sig/api-machinery,area/admission-control,lifecycle/frozen

If namespaced resources exist, but their associated namespace does not, the namespace lifecycle controller does not recognize/remedy this.
Repository: rust
Issue: rustbuild: rpath=false does not work, maybe because `build-script-build` bypasses `rustc.rs` wrapper
Labels: T-bootstrap,T-infra,C-bug

When experimenting with `rpath = false` in `config.toml` for rustbuild:

~~~~
     Running `/rust.git/build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build`
error: failed to run custom build command for `pulldown-cmark v0.0.14`
process didn't exit successfully: `/rust.git/build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build` (exit code: 127)
--- stderr
/rust.git/build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build: error while loading shared libraries: libstd-61d72c8bf510b9ba.so: cannot open shared object file: No such file or directory

Build failed, waiting for other jobs to finish...
error: build failed
~~~~

Setting `LD_LIBRARY_PATH` seems to fix things:

~~~~
$ ./build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build
./build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build: error while loading shared libraries: libstd-61d72c8bf510b9ba.so: cannot open shared object file: No such file or directory
exit code 127
$ LD_LIBRARY_PATH=$PWD/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/ ./build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build
exit code 0
~~~~

I had a poke around the code and it seems that rustbuild does make some attempt to set `LD_LIBRARY_PATH` [here](https://github.com/rust-lang/rust/blob/master/src/bootstrap/bin/rustc.rs#L93) however this is not affecting the `build-script-build` stuff apparently.

This is also causing `--no-fail env` to be ineffective for this case, presumably because `build-script-build` also bypasses rustbuild's `rustc.rs` wrapper (which is the only place that actually does anything in reaction to `--no-fail`.