sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: While in fullscreen mode, terminal does not resize properly when changing screen resolution
Labels: Issue-Bug,Area-UserInterface,Product-Terminal,Priority-3

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment

```none
Windows build number: Microsoft Windows [Version 10.0.18363.752]
Windows Terminal version: v0.10.781.0
```

# Steps to reproduce

1. Enter full-screen mode with the `toggleFullscreen` comand
2. Change the screen resolution

# Expected behavior

The terminal resizes fill the entire screen with the new screen resolution dimensions (this may require adjusting the size in both dimensions).

# Actual behavior

The terminal is resized such that it fills the screen in one dimension and the black bars are introduced around the terminal in the other dimension to fill up the remaining space.
Repository: flutter
Issue: _RenderButtonBarRow issues
Labels: framework,f: material design,P2,team-design,triaged-design

_RenderButtonBarRow has a bunch of problems in its design:

1. It lays out its children multiple times, which is highly dubious. It violates our "single-pass" layout concept, and is thus potentially O(N^2). It's also dangerous in the case of descendants that do non-idempotent layout (e.g. that trigger behaviour when they are laid out).

2. It doesn't implement the intrinsic dimension logic (computeMinIntrinsicWidth et al) so it interacts poorly with widgets like IntrinsicWidth, which are commonly seen where ButtonBars are seen (e.g. in dialogs).

3. It overrides `constraints`, which is probably turning a monomorphic getter into a polymorphic getter and costing us performance across the board.
Repository: flutter
Issue: Support UIAutomator tests of Flutter module in existing android app
Labels: a: tests,tool,d: examples,a: existing-apps,P3,team-tool,triaged-tool

Hello.

I've been on investigation on flutter and made a decision that flutter is wonderful to cover legacy applications. 
However, when it comes to integration testing (or acceptance testing) with legacy applications, I've been failing to figure out how.

Here is my situation.

![image](https://user-images.githubusercontent.com/2580013/77709326-042afa80-700e-11ea-91c1-d14bcffab989.png)

I'd like to test "a new feature by flutter". But like I mentioned before, I failed to find a way.

Is it possible to run "flutter drive" on an existing android app that contains flutter module in it?
Repository: pytorch
Issue: TorchScript can't use lists in conditionals
Labels: oncall: jit,triaged,enhancement

## 🐛 Bug

This is a reasonably common pattern in Python for testing if a list is empty.  Seems like TorchScript could support it by just teaching the frontend to translate it to `if len(ls) != 0:`

## To Reproduce

Steps to reproduce the behavior:

```python
import torch.utils.collect_env
torch.utils.collect_env.main()

class VerySimpleModel(torch.nn.Module):
    def forward(self):
        if [1]:
            return 1
        return 0
em = VerySimpleModel()
print(em())
sm = torch.jit.script(em)
print(sm())
```

```
~/work/venv-pt3-nightly/lib/python3.7/site-packages/torch/jit/_recursive.py in create_methods_from_stubs(concrete_type, stubs)
    277     rcbs = [m.resolution_callback for m in stubs]
    278     defaults = [get_default_args(m.original_method) for m in stubs]
--> 279     concrete_type._create_methods(defs, rcbs, defaults)
    280 
    281 def create_script_module(nn_module, stubs_fn, share_types=True):

RuntimeError: 
Could not cast value of type List[int] to bool:
```

(Note: it also doesn't show where in the TorchScript code this is happening.)

## Expected behavior

Prints
```
1
1
```

## Environment

Collecting environment information...
PyTorch version: 1.5.0+cpu
Is debug build: No
CUDA used to build PyTorch: None

OS: Fedora release 30 (Thirty)
GCC version: (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
CMake version: version 3.14.4

Python version: 3.7
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

Versions of relevant libraries:
[pip3] numpy==1.17.0
[pip3] pytorch-pretrained-bert==0.6.2
[pip3] torch==1.2.0
[pip3] torchtext==0.4.0
[conda] Could not collect

## Additional context

The JIT team are the coolest people I know.


cc @suo
Repository: TypeScript
Issue: Add Command-Line Syntax-Only Validation
Labels: Suggestion,Awaiting More Feedback

## Search Terms
Keywords I searched:

- Syntax
- Validation

## Suggestion

I would like to see a command line option that makes `tsc` only validate the syntax of TypeScript (and possibly JavaScript) files within the project, but does not perform type checking. It would not emit any files.

## Use Cases

- (My current use case) TypeScript generated by code generation programs that skips generation of certain symbols, or needs to import symbols from other modules where those modules may not be available yet, so their types cannot be known. The generated files would almost always have  type-related errors that cannot reliably be automatically fixed, so just validation of the syntax alone would be helpful.
- Certain CI/CD workflows could benefit from the lower overhead of just checking syntax only in large projects for every commit, and only performing type checking for commits that are expected to result in a build.

## Examples

The command

```bash
tsc --noTypeCheck index.ts
```

could return the normal errors and exit code that it would if the syntax were incorrect, but never check typing.

## 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: deno
Issue: Consume source maps from JavaScript files
Labels: feat,cli

Current Deno will remap stack traces on files that have been compiled by Deno, as Deno caches both the original file and the emitted map, and loads those from the cache.  When consuming JavaScript with source maps from other sources (like already compiled code) Deno does not handle the source map and ignore source map pragma included in files.

Deno should support both external source maps and inline source maps when fetching modules and store any source maps in the cache to be used when remapping stack traces.

This will have the side-effect of supporting the generation of source maps for bundles generated by `deno bundle`.

One consideration is that source maps optionally can include the original sources.  If they do, then when emitting an error, the original source line is available, but if they don't, we would not be able to log-out/resolve that original source line.
Repository: TypeScript
Issue: Syntax error in a union type which contains a callback type
Labels: Suggestion,Experience Enhancement

<!-- 🚨 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.
-->

**TypeScript Version:**  3.8.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- algebraic data types

**Expected behavior:**
Both `b` and `c` definitions are correct
**Actual behavior:**
Syntax errors:
![](http://i.imgur.com/hVxqmg9.png)

Texts of errors (from left to right)
```
Exported variable 'c' has or is using private name ''.(4025)
Type expected.(1110)
```
```
';' expected.(1005)
```
```
'(' expected.(1005)
```

<!-- Did you find other bugs that looked similar? -->
**Related Issues:**

**Code**
```ts
type ArrFunc = () => Array<number>;
let b: Array<number> | number | ArrFunc;
let c: Array<number> | number | () => Array<number>;
```



<details><summary><b>Output</b></summary>

```ts
"use strict";
let b;
let c;
Array();

```


</details>


<details><summary><b>Compiler Options</b></summary>

```json
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/play/#)
Repository: rust
Issue: Implement conversion traits for usize/isize together with a portability lint
Labels: T-lang,T-libs-api

[This PR](https://github.com/rust-lang/rust/pull/37423) was closed 3.5 years ago just prior to the development of the [portability lint RFC](https://github.com/rust-lang/rfcs/blob/master/text/1868-portability-lint.md). In light of the portability lint RFC having been accepted, we should be able to resurrect that PR.

This issue tracks that work. I've submitted it to TWiR's CFP.
Repository: flutter
Issue: Add support for Ascender, Descender, XHeight alignment widgets.
Labels: c: new feature,framework,a: typography,c: proposal,P3,team-framework,triaged-framework

Reopening #25018 since it was closed without resolution.

When laying out Text widgets, it is sometimes necessary to align them by the top of the capital letter or the bottom of lowercase letters like 'y'. There is a Baseline widget, but no way to align text by its ascender, descender, or x-height.

For a helpful diagram, see:
https://en.wikipedia.org/wiki/Ascender_(typography)

It is insufficient to simply have a getter for font metrics. For example, you can't have negative padding in a widget, so you couldn't align a Text object to the top of its container by simply knowing the ascent. You could wrap it in another widget, but that would be a lot of boilerplate, pollute the tree, and make it unnecessarily difficult to read the code for what should be a simple property as follows:

`Text(
  'Sample Text',
  upperConstraint: TextConstraint.CapHeight, // Ascent, XHeight, etc
  lowerConstraint: TextConstraint.Baseline, // Descent, Bottom, etc
)`
Repository: flutter
Issue: build apk --release crash. Execution failed for task ':app:minifyReleaseWithProguard'
Labels: c: crash,platform-android,tool,t: gradle,a: release,P2,team-android,triaged-android

cant build/run app and flutter doctor shows everything is ok: 
-----------------------------
flutter doctor -v
[✓] Flutter (Channel stable, v1.12.13+hotfix.8, on Linux, locale en_US.UTF-8)
    • Flutter version 1.12.13+hotfix.8 at /home/USER/Android/flutter
    • Framework revision 0b8abb4724 (6 weeks ago), 2020-02-11 11:44:36 -0800
    • Engine revision e1e6ced81d
    • Dart version 2.7.0

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /home/USER/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling
      support)
    • Platform android-29, build-tools 29.0.3
    • Java binary at: /opt/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Android Studio (version 3.6)
    • Android Studio at /opt/android-studio
    • Flutter plugin version 44.0.2
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build
      1.8.0_212-release-1586-b4-5784211)
Repository: react
Issue: Batching makes it difficult to perform imperative actions like focus
Labels: Type: Discussion

React version: 16.9.5

## Steps To Reproduce

1. Overwrite batched updates with the following code: `ReactDOM.unstable_batchedUpdates = callback => callback()`
2. Batched updates aren't actually overwritten.

## Reasoning

I recognize that this may not be classified as bug because it isn't a documented feature but I have tried to search for a different solution but to no avail. Fixing this behavior can open a new way of using React. I tried writing on [Stack Overflow](https://stackoverflow.com/questions/60852219/disable-unstable-batchedupdates-on-event-handlers-in-react) and writing to [@gaearon](https://twitter.com/antoniostoilkov/status/1242789762307588097).

I have a number of arguments which support the disabling of batched updates in event handlers and in effects initialization. If anybody is willing to read a document and consider this scenario I am willing to write an RFC.
Repository: pytorch
Issue: `torch.bernoulli` and `torch.rand` to support `dtype=torch.bool` kwarg (and sypport operation of `tensor.uniform_` on bool tensors)
Labels: module: distributions,triaged

```
----> 1 torch.bernoulli(torch.rand(10), dtype = torch.bool)

TypeError: bernoulli() received an invalid combination of arguments - got (Tensor, dtype=torch.dtype), but expected one of:
 * (Tensor input, torch.Generator generator, Tensor out)
 * (Tensor input, float p, torch.Generator generator)
```

Related: https://github.com/pytorch/pytorch/issues/31779

cc @vincentqb @fritzo @neerajprad @alicanb @vishwakftw
Repository: TypeScript
Issue: [Feature] Utility type for T[keyof T] or new keyword valueof
Labels: Suggestion,Awaiting More Feedback

## Search Terms

typeof keyof utlity type

## Suggestion
**Alternative 1:**
Create a new Utility type expressing `T[keyof T]`
Example `Value<T> = T[keyof T]`.

**Alternative 2:**
Create a new keyword equivalent to `T[keyof T]`
Example `valueof T = T[keyof T]`

## Use Cases

While `T[keyof T]` is short and concise, from my experience a lot of developers new to TypeScript usually have no idea what this means or why it's written like that when they first see it.
I also feel that it's not as easy to Google a the answer to that, in comparison to established utility and advanced types like Pick, Omit, Record, etc. which all have their own entries in the TS documentation.

Additionally Object.keys and Object.values are similar concepts.
The presence of a `keyof` keyword would suggest a `valueof` should also exist, yet it's missing and one must employ a "special" approach to replicate.

A simple solution is to write my own custom type for the project, but that just introduces additional abstraction and the knowledge/practice isn't transferable to other projects, without implementing the same custom type somewhere in the code first.

And lastly, and this is _not_ a big issue, but I feel it's redundant having to write the type for T twice in on the same line just a few symbols apart.
With short names such as T it's okay, but with longer type names the code becomes more cumbersome to read.

## Examples

```
type T = {
    a: string;
    b: number
    c: number[]
    ...etc
}

// Value<T> = string | number | number[]...
// valueof T = string | number | number[]...
```
## 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).
Perhaps some conflict on point 8...
Repository: pytorch
Issue: Support bool input tensors for argmax / argmin / sort / topk and other functions
Labels: triaged,enhancement,module: reductions

argmax and other functions make sense for finding position of True element. Functions working with uint8 should likely be able to handle torch.bool as well.

```
In [16]: torch.__version__
Out[16]: '1.5.0.dev20200310'
```

```
In [11]: torch.ones(3, dtype = torch.bool).argmax()
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
~/convasr/ot/vis.py in <module>
----> 1 torch.ones(3, dtype = torch.bool).argmax()

RuntimeError: "argmax_cpu" not implemented for 'Bool'

In [12]: torch.ones(3, dtype = torch.bool).argmin()
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
~/convasr/ot/vis.py in <module>
----> 1 torch.ones(3, dtype = torch.bool).argmin()

RuntimeError: "argmin_cpu" not implemented for 'Bool'

In [13]: torch.ones(3, dtype = torch.bool).argsort()
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
~/convasr/ot/vis.py in <module>
----> 1 torch.ones(3, dtype = torch.bool).argsort()

RuntimeError: _th_sort not supported on CPUType for Bool

In [14]: torch.ones(3, dtype = torch.bool).topk(1)
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
~/convasr/ot/vis.py in <module>
----> 1 torch.ones(3, dtype = torch.bool).topk(1)

RuntimeError: "topk_cpu" not implemented for 'Bool'

In [15]: torch.ones(3, dtype = torch.bool).sort()
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
~/convasr/ot/vis.py in <module>
----> 1 torch.ones(3, dtype = torch.bool).sort()

RuntimeError: _th_sort not supported on CPUType for Bool
```
Repository: rust
Issue: `ninja` is only used in Windows builds on CI.
Labels: A-LLVM,C-enhancement,T-infra

AFAICT this is the only thing that adds `--enable-ninja`, and it's Windows-only:
https://github.com/rust-lang/rust/blob/b9ac29169ac541a64471b83d8019cd0b442f8065/src/ci/scripts/install-ninja.sh#L9-L16

We also autodetect `ninja` and use it, but only for MSVC specifically (#43767 / #44084).

On top of being (supposedly) faster than relying on `make`, IME `ninja` also has less log spew when building LLVM (but it's unclear if it would help on CI, see #70468).

cc @rust-lang/infra
Repository: pytorch
Issue: Apple Review Rejected. ITMS-90338: Non-public API usage In Pytorch For iOS
Labels: triaged,module: ios

I use LibTorch(1.4) in pod. But When I upload the ipa binary file, Apple Review Rejected. The Email content is as below:
ITMS-90338: Non-public API usage - The app references non-public symbols in Easy Math: _daxpy_, _dcopy_, _ddot_, _dgemm_, _dgemv_, _dger_, _dscal_, _saxpy_, _scopy_, _sdot_, _sgemm_, _sgemv_, _sger_, _sscal_. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. For further information, visit the Technical Support Information at http://developer.apple.com/support/technical/

And I found these api in THBlas.cpp. How can I solve this problem. Hope receive your reply.
Repository: rust
Issue: CI logs should be split by build steps, or stages at the very least.
Labels: C-enhancement,T-infra

Right now most of the build is under a single "run the build" CI step, which results in massive logs (e.g. #70468), even if for common tasks like looking at a failure, only a small part is relevant.

At the very least we could do something like this to split it up:
* `./x.py build --stage 0`
* `./x.py build --stage 1`
* `./x.py build`
* `./x.py test`

This would be trickier with `distcheck`, I suppose, not sure how relevant that is.

It might also be slightly slower, so we should measure it.

cc @rust-lang/infra
Repository: rust
Issue: #[repr(transparent)] for str and String
Labels: T-libs-api,A-repr

Similarly to https://github.com/rust-lang/rust/issues/52976, I'd suggest that `str` and `String` should have a guaranteed transparent representation of `[u8]` and `Vec<u8>` correspondingly.

They are a newtype wrappers of these types under the hood anyway, and I don't see any reasons why they would need to behave differently in the future, and making them different probably would become a breaking change anyway as it would break things like `String::from_raw_parts` constructed from raw parts of the `Vec`.

While `String::from_raw_parts` already covers most common cases, there are still other cases where it would be desired to have guaranteed representation.

One such example is constructing `Rc<String>` from a `Rc<Vec<u8>>` where a library might want to check UTF-8 validity before construction and then `Rc::from_raw` + `Rc::into_raw` one type into another without actually copying the data.

Currently this is not possible to do safely because it's not guaranteed that the `*const Vec<u8>` returned from the first `into_raw` is compatible with `*const String` accepted by the second.

While this particular case could be alleviated by adding a special method, there are lots of other containers where such compatibility between these types might be desirable, and I don't see any reasons why it couldn't be guaranteed at a lower level.