sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: encoding/asn1: expose parseTagAndLength
Labels: Proposal,Proposal-Crypto

When working with ldap over the network, the reader does not know in advance the size of the request (the size of the buffer to read).
To know that the full request was read you need to parse the tag and length. This is just about what the function parseTagAndLength does. You only need to add the offset to the length.
To expose this function I suggest adding a public ParseTagAndLength that exposes this functionality and calculates the total expected buffer length.

usage example:
```
func readRequest(conn net.Conn, readBuf []byte) ([]byte, error) {
   const minReadBuf = 1024
   var err error
   readBuf = readBuf[0:cap(readBuf)]

   var nRead = 0
   var tagSize = 1

   for nRead < tagSize {
      nBufStart := nRead
      if (len(readBuf) - nBufStart) < minReadBuf {
         readBuf = append(readBuf, make([]byte, minReadBuf)...)
      }

      nRead, err = conn.Read(readBuf[nBufStart:])
      // no request: return
      if err != nil || nRead == 0 {
         return readBuf[0:nBufStart], err
      }

      nRead += nBufStart
      var rawVal asn1.RawValue
      rawVal, tagSize, err = asn1.ParseTagAndLength(readBuf[0:nRead])
   }

   return readBuf[0:nRead], err
}
```
Repository: flutter
Issue: Flutter exposes gnarly message from GitHub about RSA keys
Labels: tool,a: quality,P2,team-tool,triaged-tool

## Steps to Reproduce
Just ran `flutter upgrade` and got this warning message:

```
$ flutter upgrade
Upgrading Flutter from /Users/timsneath/flutter...
Warning: Permanently added the RSA host key for IP address '140.82.118.3' to the list of known hosts.
From github.com:flutter/flutter
   5385132c6..921117f4d  master     -> origin/master
   72bf075e8..7a005e1dc  beta       -> origin/beta
   d44aa57c1..7a005e1dc  dev        -> origin/dev
 * [new tag]             v0.11.7    -> v0.11.7
```

Per `whois`, the IP address `140.82.118.3` is associated with GitHub. However:

- this is being presented by a Flutter tool, rather than GitHub; 
- it's not clear that we're simply passing on a GitHub message; 
- the message itself is a little unusual (why are you telling me this? why now?); 
- it's not super-obvious how to verify this unless you know about (or remember) the `whois` command.

One proposal is that since we already do a bunch of filtering of stdout, we could filter such messages and only emit them in `--verbose` mode. Or emit them but when we spot them, add a bit of help text.
Repository: react
Issue: Warn when calling dispatch() from useEffect() cleanup function on unmounting
Labels: Type: Discussion,Component: Hooks

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**

bug

**What is the current behavior?**

action dispatched in return callback of `useEffect` seem to not work

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

https://codesandbox.io/s/5yqmo128v4

only foo -> baz is logged

```javascript
import React, { useState, useEffect, useReducer } from "react";
import ReactDOM from "react-dom";

import "./styles.css";

function reducer(state, action) {
  console.log("bar", action); // not logged
  // debugger
  return state;
}

function Foo({ value }) {
  const [state, dispatch] = useReducer(reducer, {});

  useEffect(
    () => {
      return () => {
        console.log("foo");
        // debugger
        dispatch({ type: "foo" });
        // debugger
        console.log("baz");
      };
    },
    [state, value]
  );

  return <p>{value}</p>;
}

function App() {
  const [value, set] = useState(0);

  return (
    <div className="App">
      <button onClick={() => set(value + 1)}>INC</button>
      {value % 2 ? <Foo value={value} /> : null}
    </div>
  );
}

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);
```

**What is the expected behavior?**
bar is logged in console
(foo -> baz -> bar`action`)

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

react: "16.7.0-alpha.2",
react-dom: "16.7.0-alpha.2"
Repository: TypeScript
Issue: Props requiring casting on complex type (and defaultProps not settable)
Labels: Bug

**Search Terms:**
defaultProps React.RefForwardingComponent ExoticComponent

**Code**
```typescript
// import { cx } from "emotion";
import * as React from "react";

// import modifiers, { ModifierProps } from "../../modifiers";

interface RenderAsExoticComponent<
  TOwnProps,
  TDefaultComponent extends
    | keyof JSX.IntrinsicElements
    | React.ComponentType<any>
>
  extends Pick<
    React.ForwardRefExoticComponent<any>,
    keyof React.ForwardRefExoticComponent<any>
  > {
  (
    props: React.ComponentPropsWithRef<TDefaultComponent> &
      TOwnProps & { renderAs?: never },
  ): JSX.Element | null;
  <TAsComponent extends keyof JSX.IntrinsicElements | React.ComponentType<any>>(
    props: React.ComponentPropsWithRef<TAsComponent> &
      TOwnProps & { renderAs: TAsComponent },
  ): JSX.Element | null;
}

function renderAsComponent<
  TOwnProps,
  TDefaultElement extends React.ComponentType<any> | keyof JSX.IntrinsicElements
>(
  factory: React.RefForwardingComponent<
    any,
    TOwnProps & {
      renderAs?: React.ComponentType<any> | keyof JSX.IntrinsicElements;
      className?: string;
    }
  >,
  defaultElement: TDefaultElement,
) {
  const forward = React.forwardRef(factory);
  forward.defaultProps = { renderAs: defaultElement };
  // todo: apparently a bug, use workaround
  // forward.defaultProps = {};
  // forward.defaultProps.renderAs = defaultElement;
  return forward as RenderAsExoticComponent<TOwnProps, TDefaultElement>;
}

interface ModifierProps {
  textColor?: "white" | "black";
  pull?: "left" | "right";
}

const Element = renderAsComponent<ModifierProps, "div">(
  ({ className, renderAs, ...allProps }, ref) => {
    const props = {
      // className: cx(className, modifiers.classNames(allProps)) || undefined,
      ref,
      // ...modifiers.clean(allProps),
    };
    return React.createElement(renderAs!, props);
  },
  "div",
);

export default Element;
```

```ts
export const Example: React.SFC<{}> = () => (
  <Element textColor="white" pull={"left" as "left"}>
    Child
  </Element>
);
```

**Expected behavior:**
1) `defaultProps` can be set directly
2) `props` work without casting

**Actual behavior:**
1) `defaultProps` cannot be set directly (see workaround in code)
2) `props` do not work without being cast.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
No.
Repository: pytorch
Issue: Caffe2->ONNX conversion issue due to spatial-bn
Labels: caffe2

I have used this reference https://github.com/caffe2/caffe2/issues/703 to implement resnet model in caffe2 because of mobile export api issues in caffe2. But after applying this changes I am not been able to convert the resnet caffe2 model into onnx model due to unordered sequence of batch-normalization params(running-mean, scale, offset, running-variance).

**Following is error which is caused:**

```
WARNING:caffe2.python.workspace:Original python traceback for operator `1` in network `deploy_net` in exception above (most recent call last):
Traceback (most recent call last):
  File "temp_model_sqeezenet.py", line 33, in 〈module〉
    value_info,
  File "/home/parthr/anaconda2/lib/python2.7/site-packages/caffe2/python/onnx/frontend.py", line 331, in caffe2_net_to_onnx_model
    model = make_model(cls.caffe2_net_to_onnx_graph(*args, **kwargs),
  File "/home/parthr/anaconda2/lib/python2.7/site-packages/caffe2/python/onnx/frontend.py", line 221, in caffe2_net_to_onnx_graph
    inputs)
  File "/home/parthr/anaconda2/lib/python2.7/site-packages/caffe2/python/onnx/helper.py", line 62, in c2_native_run_net
    ws.RunNetOnce(predict_net)
  File "/home/parthr/anaconda2/lib/python2.7/site-packages/caffe2/python/onnx/workspace.py", line 63, in f
    return getattr(workspace, attr)(*args, **kwargs)
  File "/home/parthr/anaconda2/lib/python2.7/site-packages/caffe2/python/workspace.py", line 201, in RunNetOnce
    StringifyProto(net),
  File "/home/parthr/anaconda2/lib/python2.7/site-packages/caffe2/python/workspace.py", line 180, in CallWithExceptionIntercept
    return func(*args, **kwargs)
RuntimeError: [enforce fail at operator.cc:138] schema-〉Verify(operator_def). Operator def did not pass schema checking: input: "conv1_1" input: "bn1_s_0" input: "bn1_b_0" input: "bn1_rm_0" input: "bn1_riv_0" output: "bn1_1" output: "bn1_rm_1" output: "bn1_riv_1" output: "bn1_sm_1" output: "bn1_siv_1" name: "" type: "SpatialBN" arg { name: "is_test" i: 0 } arg { name: "use_cudnn" i: 1 } arg { name: "cudnn_exhaustive_search" i: 0 } arg { name: "order" s: "NCHW" }
frame #0: c10::ThrowEnforceNotMet(char const*, int, char const*, std::__cxx11::basic_string〈char, std::char_traits〈char〉, std::allocator〈char〉 〉 const&, void const*) + 0x68 (0x7fdac2551778 in /home/parthr/anaconda2/lib/python2.7/site-packages/caffe2/python/../../../../libc10.so)
frame #1: 〈unknown function〉 + 0x1273197 (0x7fdac3
```9c9
Repository: godot
Issue: Delete file - Case sensitive -
Labels: bug,platform:windows,topic:editor,confirmed

**Godot version:**
![image](https://user-images.githubusercontent.com/13235119/48766316-16738680-ecac-11e8-9d66-c85abe852dda.png)

**OS/device including version:**
Win7-64


**Issue description:**
I save a "Ground.tscn" scene as "ground.tscn". 
Godot alert the old file will be overwritten.
Then in FileSstem dock I see 2 files : Ground.rscn and ground.tscn.
I delete Ground.tscn and I cannot access anymore to ground.tsnc.

**Steps to reproduce:**
See before.


**Minimal reproduction project:**
NA
Repository: go
Issue: net: FreeBSD build failed with net.inet.tcp.blackhole=2
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.2 freebsd/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>
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/sternix/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOOS="freebsd"
GOPATH="/home/sternix/go"
GOPROXY=""
GORACE=""
GOROOT="/opt/go/1_11_2/go"
GOTMPDIR=""
GOTOOLDIR="/opt/go/1_11_2/go/pkg/tool/freebsd_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build323464270=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?
i want to build golang (master) from source 
i follow the instructions from https://golang.org/doc/install/source

% git rev-parse --short HEAD 
90777a34cf

### What did you expect to see?
ALL TESTS PASSED

### What did you see instead?
Failed: exit status 1

With default net.inet.tcp.blackhole=0 setting its compiled successfully
but with
sudo sysctl net.inet.tcp.blackhole=2
failed with errors as attached

net.inet.tcp.blackhole: Do not send RST on segments to closed ports

i test build with FreeBSD 11.2 amd64 and FreeBSD 12.0-RC1 amd64 with same results

Thanks.

[go_build.txt](https://github.com/golang/go/files/2599596/go_build.txt)
Repository: pytorch
Issue: [bug] inconsistent behavior of indexing 
Labels: triaged,module: advanced indexing

## 🐛 Bug

Trying to get incorrect index of a tensor may lead to `IndexError` or `RuntimeError` which looks inconsistent to me. For example, it doesn't matches `numpy` experience.

## To Reproduce

Steps to reproduce the behavior:

```

In [197]: tensor = torch.rand(100)

In [198]: tensor[100]
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
<ipython-input-198-7933b057773b> in <module>()
----> 1 tensor[100]

IndexError: index 100 is out of bounds for dimension 0 with size 100

In [199]: tensor[np.array([0, 100])]
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-199-aa44e153a40d> in <module>()
----> 1 tensor[np.array([0, 100])]

RuntimeError: index 100 is out of bounds for dimension 0 with size 100
```

## Expected behavior

I'd expect `IndexError` to be raised in both cases, as `numpy` does.

## Environment

PyTorch version: 0.4.1
Is debug build: No
CUDA used to build PyTorch: None

OS: Mac OSX 10.14
GCC version: Could not collect
CMake version: version 3.8.2

Python version: 3.6
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
Repository: svelte
Issue: Await expressions
Labels: feature request

Just want to capture a thought I had the other day: it might be neat to have inline `await` expressions in templates. We already have `{#await ...}` blocks but they're overkill in some situations — you have to declare a name for the resolved value, which you might only be using once, and you might not need to worry about error states depending on what you're doing.

Imagine something like this (v3 syntax):

```html
<script>
  async function fibonacci(n) {
    return await fibonacciWorker.calculate(n);
  }
</script>

<input type=number bind:value={n}>
<p>The {n}th Fibonacci number is {await fibonacci(n)}</p>
```

It would integrate with [Suspense](https://github.com/sveltejs/svelte/issues/1736), so it'd be convenient for doing this sort of thing (where `loadImage` resolves to its input, but only after ensuring that the image is loaded):

```html
<script>
  import loadImage from './utils.js';
</script>

{#each thumbnails as thumbnail}
  <img alt={thumbnail.description} src="{await loadImage(thumbnail.src)}">
{/each}
```

Of course, you'd need some way to have placeholder content, for situations where you're not using Suspense. Maybe this?

```html
<p>The {n}th Fibonacci number is {await fibonacci(n) or '...'}</p>
```
Repository: TypeScript
Issue: Compiler hangs with large JS file with --allowJs
Labels: Bug,Domain: Control Flow

<!-- 🚨 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:**  typescript@3.2.0-dev.20181117

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
Compiler hangs large file

**Code**
wget --no-check-certificate https://raw.githubusercontent.com/hyperledger/composer-concerto/4e0a9aa990fb065d9eedb54e7086473054b0015a/lib/introspect/parser.js
tsc --allowJs --outDir out-tsc parser.js

**Expected behavior:**
It completes and writes some output, or some errors

**Actual behavior:**
It hangs indefinitely

**Related Issues:**
https://github.com/Microsoft/TypeScript/issues/17033
Repository: TypeScript
Issue: Suggest import nearest current file.
Labels: Suggestion,Domain: Completion Lists,Experience Enhancement

## Search Terms
vs code, language service, suggestions, auto complete, import, symbol, nearest current file.

## Suggestion
In VS Code the auto complete dropdown for auto importing seems to have a random order. I think the user experience could be improved by ordering the exported symbols in the dropdown in order of how close the file path is to your current file path.

## Use Cases/Examples
See the example directory structure below.

- moduleA/
  - constants.ts
  - index.ts
- moduleB/
  - constants.ts
  - index.ts

Say that both moduleA/constants.ts and moduleB/constants.ts export a variable like `foobar`. When I type `foobar` in moduleA/index.ts it's likely that I'm trying to auto import `foobar` from moduleA/constants.ts`.

In the current approach the dropdown suggests `foobar` from both moduleA/constants.ts and moduleB/constants.ts, however, the order doesn't seem to be guaranteed so sometimes it will suggest moduleB's `foobar` first and other times moduleA's `foobar`.

I think this could be improved by ordering suggestions in terms of how close their source file path is to the current file path, such that moduleA's `foobar` always appears before moduleB's `foobar` when I'm in moduleA/index.ts. For the sake of completeness, I think it should show moduleB's `foobar` first when I'm in moduleB/index.ts.

I hope I've explained that clearly enough.

## Checklist

My suggestion meets these guidelines:

* [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: rust
Issue: Tracking issue for future-incompatibility lint `coherence_leak_check`
Labels: A-lints,A-lifetimes,T-compiler,C-future-incompatibility,C-tracking-issue,S-tracking-impl-incomplete,T-types

This is the **tracking issue** for the "universe transition". The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around bug fixes that affect existing code, see our [breaking change policy guidelines][guidelines].

[guidelines]: https://forge.rust-lang.org/rustc-bug-fix-procedure.html

#### What was the change and what code is affected?

This change (introduced in https://github.com/rust-lang/rust/pull/55517) fixed a number of bugs (e.g., https://github.com/rust-lang/rust/issues/32330) in how the Rust compiler handled higher-ranked types (e.g., `fn(&u8)` or -- more explicitly -- `for<'a> fn(&'a u8)`) and trait bounds (e.g., `for<'a> T: Trait<'a>`). One of these changes could however affect existing code. In particular, the compiler in the past would accept trait implementations for identical functions that differed only in where the lifetime binder appeared:

```rust
trait SomeTrait { }
impl SomeTrait for for<'a> fn(&'a u8) { }
impl<'a> SomeTrait for fn(&'a u8) { }
```

We no longer accept both of these impls. Code relying on this pattern would now have to introduce "newtypes", like `struct Foo(for<'a> fn(&'a u8))`. 

#### History of this change

This change was first made in #55517 without a "warning period". This was done because (a) it would be challenging to issue precise warnings for affected code and (b) a crater run found zero regressions.

However, the change was subsequently backed out in https://github.com/rust-lang/rust/pull/58592, [owing to concerns about unintended side-effects](https://github.com/rust-lang/rust/issues/56105#issuecomment-465634661).

The change was re-added in https://github.com/rust-lang/rust/pull/65232, but this time with a warning period. We are currently completing the implementation and trying to figure out how to draw the line in terms of what should become a hard error.

#### Affected crates and patterns

This section is for collecting patterns and examples to look into or other related issues.

* wasm-bindgen was reported to get warnings in #65232
* @quark-zju commented that their crate was affected [here](https://github.com/rust-lang/rust/issues/56105#issuecomment-606379619)
* https://github.com/rust-lang/rust/issues/73154 -- order dependent coercion
Repository: rust
Issue: Refactorings for rustc_codegen_ssa
Labels: C-cleanup,A-codegen,T-compiler,A-cranelift,A-gcc

This is a list of things I noticed in `rustc_codegen_{utils,ssa}` which I did like to be changed.

* [x] Move https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_utils/symbol_names/index.html to `rustc_codegen_ssa`.
* [x] Remove https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_utils/lib.rs.html#64 (now unused)
* [ ] https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/debuginfo/enum.FunctionDebugContext.html
    * [x] Inline `debuginfo_disabled_message` and `should_be_ignored_message` into `as_ref`.
* [ ] https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/debuginfo/struct.FunctionDebugContextData.html
    * [x] Remove the `Cell` from the field `source_locations_enabled` and adapt several functions to take a mutable reference to `FunctionDebugContext{,Data}` instead.

---
Edit:

* [x] https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/backend/trait.BackendTypes.html `Context` is not used inside `rustc_codegen_ssa`
* [ ] <strike>https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/type_/trait.BaseTypeMethods.html</strike> https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_llvm/context/struct.CodegenCx.html#method.set_struct_body Why is `set_struct_body` even a thing?
* [ ] https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/consts/trait.ConstMethods.html All methods take &self, but a codegen backend may need to mutate stuff to create values.
* [ ] https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/statics/trait.StaticMethods.html All methods take &self, but a codegen backend may need to mutate stuff to create values.

Edit: update for current status