sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/build/maintner: wrong type for DismissedReview.State
Labels: Builders,NeedsInvestigation

The [docs](https://developer.github.com/v3/issues/events/) say that it's a string with values `commented`, `approved`, `changes_requested`

https://github.com/golang/build/blob/438dce5f3d2fd35b54f4d5431e53e2029c40fffe/maintner/github.go#L466-L472

https://github.com/golang/build/blob/438dce5f3d2fd35b54f4d5431e53e2029c40fffe/maintner/maintpb/maintner.proto#L144-L151

I can send a change to fix it. I think it'd have no effect on existing code, since if people were using maintner with repos that had GitHub reviews, then they'd already have experienced panics. (I'd add it as a new field and remove the existing one + reserve the proto id)
Repository: TypeScript
Issue: Decouple jsx element type from jsx factory return type and sfc return type
Labels: Suggestion,Breaking Change,Effort: Moderate,Domain: JSX/TSX,Fix Available

We need to look up the type of a jsx expression by actually resolving the jsx factory call, so that we don't create a reference to the global `JSX.Element` type, which can change shape between react versions (as it needs to in the react 16 upgrade). We also need to resolve the sfc return type and class element type from the parameters of the factory function overloads for the same reasons, doubly so because the types allowable as `render` method and `SFC` return values are no longer the same as `JSX.Element` (namely, they can be strings, arrays, portals, etc). 

This _might_ be considered a breaking change, because some consumers may expect `JSX.Element` to always be a supertype of both jsx element expression return types and SFC return types (even though this isn't true in react 16) - we certainly made that assumption internally, hence the need for the change. 🐱
Repository: TypeScript
Issue: Suggestion: go-to-definition should go to a base definition if possible.
Labels: Suggestion,In Discussion,Domain: Symbol Navigation

**TypeScript Version:**  master

**Code**

```ts
class A {
    m() {}
}
class B extends A {
    m() {}
}
```

**Expected behavior:**

Go-to-definition on `m` in `class B` should go to `m` in `class A`. (Same if `A` were an interface.)

**Actual behavior:**

I get taken to the beginning of the current identifier.
Repository: pytorch
Issue: [feature request]Add an env variable to cover different pathes when testing code with openmp
Labels: module: tests,triaged,better-engineering

 I have discussed with @fmassa about the problem before.  Refer to #4824  and #4188.
In consideration of openmp overhead threshold, actually the code has 2 pathes need to be tested.  However, the size of tensor in test case are usually small in order to increase test speed. So the current code is potentially dangerous because the path with multi-thread maybe is never tested. It's necessary to add an env variable to control code paths.  I think we can start with TH and THNN modules which intensively use openmp. I hope that guys which are in charge of test case could also follow it once the env variable is ready.



cc @mruberry @VitalyFedyunin
Repository: rust
Issue: Tracking issue for `try_reserve`: RFC 2116 fallible collection allocation
Labels: A-allocators,A-collections,T-libs-api,B-unstable,B-RFC-implemented,C-tracking-issue,Libs-Tracked

This is a tracking issue for the `try_reserve` part of the RFC "fallible collection allocation" (rust-lang/rfcs#2116).

**Steps:**

- [x] Implement the RFC #48648
  - [x] Add `HashSet::try_reserve`: https://github.com/rust-lang/rust/pull/58623
- [x] Finalize the error type
- [ ] Adjust documentation ([see instructions on forge][doc-guide])
- [ ] Stabilization PR ([see instructions on forge][stabilization-guide])

[stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html
[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation


**API:**

```rust
impl /* each of String, Vec<T>, VecDeque<T> */ {
    pub fn try_reserve(&mut self, additional: usize) -> Result<(), TryReserveError> {…}
    pub fn try_reserve_exact(&mut self, additional: usize) -> Result<(), TryReserveError> {…}
}

impl /* each of HashMap<K, V> and HashSet<T> */ {
    pub fn try_reserve(&mut self, additional: usize) -> Result<(), TryReserveError> {…}
}

/// The error type for `try_reserve` methods.
#[derive(Clone, PartialEq, Eq, Debug)]
pub enum TryReserveError { // in std::collections
    /// Error due to the computed capacity exceeding the collection's maximum
    /// (usually `isize::MAX` bytes).
    CapacityOverflow,

    /// The memory allocator returned an error
    AllocError {
        /// The layout of allocation request that failed
        layout: Layout,

        #[doc(hidden)]
        #[unstable(feature = "container_error_extra", issue = "0", reason = "\
            Enable exposing the allocator’s custom error value \
            if an associated type is added in the future: \
            https://github.com/rust-lang/wg-allocators/issues/23")]
        non_exhaustive: (),
    },
}

impl From<LayoutErr> for TryReserveError {
    fn from(_: LayoutErr) -> Self {
        TryReserveError::CapacityOverflow
    }
}
```
Repository: pytorch
Issue: Saving model with runtime code changes
Labels: module: serialization,triaged

- OS: Ubuntu 16.04
- PyTorch version: 0.3.0.post4
- How you installed PyTorch (conda, pip, source): pip
- Python version: python 3.5.2

There is a bug in saving and loading the model with torch.save(...) and torch.load(...).
Workflow of bug:
1. Create neural network code and start learning loop. Model gets saved every 100 epoch with torch.save(...).
2. Change the neural network code and save code, while the learning loop from step 1 is still running.
3. Let training loop run until the next save of neural network.
4. Loading the last save with the neural network code from step 1 causes a warning (SourceChangeWarning). Also if you open the save file, there will be the changed code from step 2 instead of from step 1.

Short:
If you change the code of the neural network while runtime, a false code copy will be saved into the torch.save(...) file. Which causes a warning, if I want to load it with the original network code again.

Loading code:
`self.optimizeNet = torch.load(pacPretrained, map_location=lambda storage, loc: storage)`

Saving code:
`torch.save(self.optimizeNet, "saves2/"+str(ep)+'th-episode.pt')`

Neural network:
```
class DQN(nn.Module):
    def __init__(self):
        super(DQN, self).__init__()
        #smallGrid = kernel_size=3, stride=1
        self.conv1 = nn.Conv2d(3, 16, kernel_size=3, stride=1)
        self.bn1 = nn.BatchNorm2d(16)
        self.conv2 = nn.Conv2d(16, 32, kernel_size=3, stride=1)
        self.bn2 = nn.BatchNorm2d(32)
        self.conv3 = nn.Conv2d(32, 32, kernel_size=3, stride=1)
        self.bn3 = nn.BatchNorm2d(32)
        self.head = nn.Linear(1088, 512)
        self.head2 = nn.Linear(513, 256)
        self.head3 = nn.Linear(256, 5)

        self.lastLayer = 3

    def forward(self, x, numCarry):
        x = F.relu(self.bn1(self.conv1(x)))
        x = F.relu(self.bn2(self.conv2(x)))
        x = F.relu(self.bn3(self.conv3(x)))
        #print(x.shape)
        #print((x.view(x.size(0), -1)).shape)
        try:
            x = F.relu(self.head(x.view(x.size(0), -1)))
        except:
            raise ValueError("Dimension should be "+str((x.view(x.size(0), -1)).shape))
        y = torch.cat((x,numCarry.unsqueeze(0).t()), dim=1)
        y = F.relu(self.head2(y))
        y = self.head3(y)
        return y
```
Repository: vscode
Issue: [css] Lab colors and other CSS Color Module Level 4 features
Labels: help wanted,feature-request,css-less-scss

See the [CSS Color Module Level 4](https://drafts.csswg.org/css-color/#specifying-lab-lch) specification.

While the specification is still a draft and browsers don't support these features yet, there already exists a [PostCSS plugin](https://github.com/jonathantneal/postcss-color-lab) that (partially) implements them, so it's actually already possible to use at least a part of them.

```css
.example {
	background-color: lab(33 43 -47);
	box-shadow: 0 0 20px lch(54 107 41 / 10%);
}
```

Would be nice to get previews for those colors in VS Code like it's shown for rgb/rgba/hsl colors.
Repository: flutter
Issue: flutter shell wrapper can't resume transfer of SDK from completed download
Labels: tool,a: first hour,P2,team-tool,triaged-tool

At some point in the recent past, curl HTTP range commands to the URL for the Dart SDK likely worked even if the download was complete, or otherwise we wouldn't unconditionally do this:

https://github.com/flutter/flutter/blob/e1018fab34e49ad3941361aa06fbbe5173e110ac/bin/internal/update_dart_sdk.sh#L64

However, that doesn't seem to work right now:

```
~/dart/flutter/bin/cache
$ rm dart-sdk.zip 
~/dart/flutter/bin/cache
$ curl --continue-at - --location --output /usr/local/google/home/jcollins/dart/flutter/bin/cache/dart-sdk.zip https://storage.googleapis.com/dart-archive/channels/dev/raw/2.0.0-dev.19.0/sdk/dartsdk-linux-x64-release.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 78.1M  100 78.1M    0     0  19080      0  1:11:36  1:11:36 --:--:-- 43.2M
~/dart/flutter/bin/cache
$ curl --continue-at - --location --output /usr/local/google/home/jcollins/dart/flutter/bin/cache/dart-sdk.zip https://storage.googleapis.com/dart-archive/channels/dev/raw/2.0.0-dev.19.0/sdk/dartsdk-linux-x64-release.zip
** Resuming transfer from byte position 81971659
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   171    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (33) HTTP server doesn't seem to support byte ranges. Cannot resume.
~/dart/flutter/bin/cache
$
```

This can be worked around by deleting the cached dart-sdk.zip.  


## Steps to Reproduce

flutter upgrade-packages

## Logs

```
~/dart/flutter/bin
$ ./flutter upgrade-packages
Downloading Dart SDK 2.0.0-dev.19.0...
** Resuming transfer from byte position 81971659
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0   171    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (33) HTTP server doesn't seem to support byte ranges. Cannot resume.
~/dart/flutter/bin
$
```
Repository: rust
Issue: Tracking issue for RFC #1909: Unsized Rvalues  (unsized_locals, unsized_fn_params)
Labels: B-RFC-approved,T-lang,C-tracking-issue,F-unsized_locals,F-unsized_fn_params,S-tracking-design-concerns,S-tracking-needs-summary

This is a tracking issue for the RFC "Unsized Rvalues " (rust-lang/rfcs#1909).

**Steps:**

- [ ] Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
- [ ] Adjust documentation ([see instructions on forge][doc-guide])
- [ ] Stabilization PR ([see instructions on forge][stabilization-guide])

[stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html
[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation

**Blocking bugs for `unsized_fn_params`:**

- https://github.com/rust-lang/rust/issues/111175
- https://github.com/rust-lang/rust/issues/115709 (bad interaction with extern_type: we either need to be okay with post-mono checks or need a trait for "dynamically sized" types)
- Reject unsized arguments for functions with non-Rust ABI

**Related bugs:**

- [x] https://github.com/rust-lang/rust/issues/61335 -- ICE when combined with async-await
- [x] https://github.com/rust-lang/rust/issues/68304 -- 
`Box<dyn FnOnce>` doesn't respect self alignment

**Unresolved questions:**

- [ ] What are the MIR semantics for unsized locals? We currently do not have operational semantics for them, and the way they currently work, there are no good operational semantics. This needs a complete from-scratch re-design.
- [ ] Can we carve out a path of "guaranteed no alloca" optimization? (See #68304 for some related discussion)
- [ ] Given that LLVM doesn't seem to support alloca with alignment, how do we expect to respect alignment limitations? (See #68304 for one specific instance)
- [ ] How can we mitigate the risk of unintended unsized or large allocas? Note that the problem already exists today with large structs/arrays. A MIR lint against large/variable stack sizes would probably help users avoid these stack overflows. Do we want it in Clippy? rustc?
- [ ] How do we handle truely-unsized DSTs when we get them? They can theoretically be passed to functions, but they can never be put in temporaries.
- [ ] Decide on a concrete syntax for VLAs.
- [ ] What about the [interactions between async-await/generators and unsized locals](https://github.com/rust-lang/rust/issues/48055#issuecomment-583743014)?
- [ ] We currently allow `extern type` arguments with `unsized_fn_params`, but that does not make much sense and leads to ICEs: https://github.com/rust-lang/rust/issues/115709
Repository: TypeScript
Issue: Differing results for inference produced when identical overload count changes
Labels: Bug

I happened to notice this while looking at something else inference related a bit ago. We already have a test that is looking for checking this, `fixingTypeParametersRepeatedly3.ts`, added in #2356, but it was accepted in #16368 (strict generic checks) with a (tiny, unnoticeable in all the other changes) baseline showing the fault.

**Code**

```ts
interface Base {
    baseProp;
}
interface Derived extends Base {
    toBase?(): Base;
}

var derived: Derived;

declare function foo<T>(x: T, func: (p: T) => T): T;
var result = foo(derived, d => d.toBase());

// bar should type check just like foo.
// result2 should have the same type as result
declare function bar<T>(x: T, func: (p: T) => T): T;
declare function bar<T>(x: T, func: (p: T) => T): T;
var result2 = bar(derived, d => d.toBase());
```

**Expected behavior:**
`result` and `result2` are assigned the same type (there's a comment in the test asserting as much) - they are implemented identically except `bar` has an extra identical overload. (note: this can happen easily in the real world nowadays via intersection types! Intersecting multiple interfaces with similar base interfaces can cause exactly this situation.)

**Actual behavior:**
`result` typechecks as `Derived`
`result2` typechecks as `Base` (seems wrong, since `Base` definitely doesn't have the `toBase` method used in the callback!)

`Derived` and `Base` are assignable to one another here, since `toBase` is optional, which is why the inference can succeed at all; however, `Base`, as reported in the second case can't actually have been the type used to typecheck the lambda body, as the `toBase` call doesn't cause an error in the test - I think the likely reason for the change in behavior is [this removal](https://github.com/Microsoft/TypeScript/pull/16368/files#diff-c3ed224e4daa84352f7f1abcd23e8ccaL16428), based on the content of the removed comment.
Repository: godot
Issue: Exported (non-static) Arrays are not duplicated when instancing.
Labels: bug,discussion,topic:gdscript,confirmed

**Godot version:** Godot 3.0

**OS/device including version:** Solus Linux / X11

**Issue description:** When exporting an array variable in GDScript, the array is not duplicated upon instancing of the node. This behavior conflicts with all other properties, and is contrary to the OOP model Godot uses. The array is not static (or class-wide), but belongs to the instance, and so every instance's copy should be unique. Currently, unless manually duplicated, modifications to the array affect all instances of the class.

This issue may be present with Dictionaries as well, I have not tested them.

**Steps to reproduce:** Write this script:

```gdscript
extends Node

export var test = []

# This way too, it's not bound to explicit array constructor
# export(Array) var test

func _ready():
    test.append("test %s" % self)
    print(test) 
```

Save a node with the script a as scene, instance two copies at runtime, and add them to the tree.

Expected result:
```
["test Node:XXXX"]
["test Node:YYYY"]
```

Result:
```
["test Node:XXXX"]
["test Node:XXXX", "test Node:YYYY"]
```
**Minimal reproduction project:** See above.
Repository: TypeScript
Issue: Suggestion: case-sensitive imports
Labels: Suggestion,Help Wanted,Effort: Moderate

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.7.0-dev.201xxxxx

My mac does not have case sensitive imports. That is you can import the file `x.js` as `./X.js` and everything will work. However, our servers run on linux (like most) and I got a runtime exception that took down the whole server because linux imports are case sensitive.

I think this would be an awesome addition to Typescript to prevent fatal mistakes that are hard to catch like this one.

**Related Issues:**

https://github.com/Microsoft/TypeScript/issues/14460
Repository: go
Issue: spec: order of evaluation vs panicking
Labels: Documentation,NeedsFix

It's possible to write expressions that, depending on order of evaluation, may panic for different reasons. I think this is fine, but it might be worth mentioning or providing examples to make clearer / less surprising to users.

For example, consider:

    var p *[0]int
    var i int

    (*p)[i] = 0

Under cmd/compile, this snippet produces an "invalid memory address or nil pointer dereference" panic; whereas under gccgo, it produces an "index out of range" panic.

--

Another example is:

    var p *int
    var x int

    _ = *p / x

Both cmd/compile and gccgo produce a nil pointer dereference panic, but the Go spec appears to also permit division by zero.

--

The latter example is relevant to #23661, because of:

    var m = map[interface{}]int{0: 0}  // non-empty map to workaround #23734
    var k []int
    var x int

    m[k] /= x

Today, the last statement is compiled into roughly:

    tmp := *mapaccess1(m, k)
    if x == 0 {
        panicdivide()
    }
    *mapassign(m, k) = tmp / x

It would be nice to optimize that to

    if x == 0 {
        panicdivide()
    }
    *mapassign(m, k) /= x

But that would change the panic from "hash of unhashable type []int" to "division by zero". This change appears valid under the Go spec, but it seems worth clarifying whether that's the case.
Repository: TypeScript
Issue: Request for translation on Filipino
Labels: Suggestion,Awaiting More Feedback,i18n

I want to contribute in translation
Repository: flutter
Issue: iOS a11y text entry is incomplete
Labels: a: text input,platform-ios,framework,a: accessibility,a: fidelity,f: cupertino,has reproducible steps,P2,customer: flex,team-ios,triaged-ios,found in release: 3.19,fyi-text-input,found in release: 3.22

This is a follow-up for issue https://github.com/flutter/flutter/issues/12786.

As of https://github.com/flutter/engine/pull/4575 we have partial support for a11y text entry on iOS.

What works:
 - When "tabbed" or "dragged" into
   - Text fields are announced as "Text field"
   - The hint "double tap to edit"
   - Content of text field is announced 
   - It is announced weather a text field is in edit mode
   - The insert mode (e.g. character mode) is not announced.
 - Entered characters are echoed back
 - After inserting space the last word is echoed back
 - Swiping up or down moves the courser
 - Selecting text with reverse-pinch

What remains to be done:
 - [ ] **No announcement** when a **currently edited** text field gains focus via the "tap" gesture
 - [ ] The position of the cursor is **not** announced 
 - [ ] Copy&paste does **not** work when rotor is in edit mode
 - [ ] TextFields for passwords (`secureTextEntry = YES`) are **not** announced as "secure text fields"
 - [ ] TextFields for passwords (`secureTextEntry = YES`) announce their content (e.g. "5 bullets") instead of the number of characters

/cc @goderbauer
Repository: vscode
Issue: Titlebar-less view for Linux
Labels: feature-request,linux,titlebar

Just as Mozilla did in Firefox 59 (you can check it out in Firefox Nightly atm), and someone was doing for the Mac version in #12377, it would be really good to have an option to **integrate the title bar in the same row where the tabs reside**, in order to save some vertical space (which is even more important if like me you usually work on a non-FHD laptop such as an old Thinkpad or a Dell Latitude). 

I said in Gnome cause it's what I use, but maybe it could be made into a more portable solution that has options for all DEs with top bars (be it Mac, Gnome, Xfce...). Like Mozilla did, it could even start to roll out when just some DEs are supported, with the warning that it may not work on all systems.
Repository: rust
Issue: Macros: limitation in the expression parser for <$:path>::<ident>
Labels: C-enhancement,A-parser,A-macros,T-compiler

Background: https://users.rust-lang.org/t/macros-using-path-tokens-with-format-args/15480

When passing in a `path` token to a macro, then trying to suffix the metavariable with `::<ident>` (or more), the parser cannot recognize the whole thing as an `:expr`, which causes failures on calls to macros like `format_args!`.

Repro:

```rust
macro_rules! something {
    ( $path:path ) => (
        //println!("Say: {}", $path::say);
        format_args!("Say: {}", $path::say);
    );
}

mod foo {
    const say: &str = "Hello";
}

mod bar {
    const say: &str = "World";

    mod baz {
        const say: &str = "Universe";
    }
}

fn main() {
    something!(foo);
    something!(bar);
    something!(bar::baz);
}
```

It fails with three instances of this error (with `RUSTFLAGS='-Z external-macro-backtrace'`):

```rust
error: expected token: `,`
  --> src/main.rs:4:9
   |
1  | / macro_rules! talk {
2  | |     ( $mod:path ) => (
3  | |         // print!("Say: {}", $mod::say);
4  | |         format_args!("Say: {}", $mod::say);
   | |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5  | |     );
6  | | }
   | |_- in this expansion of `talk!`
...
21 |       talk!(foo);
   |       ----------- in this macro invocation
```

A workaround is to use:
```rust
{ use $path as base; base::say }
```
but would be great if we could just use:
```
$path::say
```

I couldn't find an existing report. I'm guessing it falls under RFE.