sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [fuchsia] Upload the test archives files to CIPD to run the test in GI / G3 rather than flutter/engine
Labels: engine,platform-fuchsia,P2,team-engine,triaged-engine

These tests have sometimes been flaky due to various non-flutter related problems. They're still being run on CIPD but that doesn't exercise the device finder code-path.

See: fxb/63130

More context: https://github.com/flutter/flutter/issues/69140
Repository: rust
Issue: MIR InstrumentCoverage: Improve coverage of `#[should_panic]` tests and `catch_unwind()` handlers
Labels: T-compiler,A-MIR,A-code-coverage

At present, the MIR `InstrumentCoverage` pass omits unwind paths when computing coverage spans and injecting counters because (1) statements executed during an unwind are generally compiler-generated, so they don't have source code to "cover"; and (2) in normal runtime execution, unwind paths are generally called when an unexpected and/or unhandled error is encountered.

Unexpected errors can (and probably should) be corrected before addressing coverage errors.

Some exceptions to this are: (1) tests that include testing for known `panic` situations, for instance, unit tests annotated with the `#[should_panic]` attribute; and (2) code that leverages a `catch_unwind()` handler.

Since coverage analysis is commonly used to validate that test cases execute all source code, and `#[should_panic]` tests might be included among the test cases, `InstrumentCoverage` could be improved to provide a more accurate representation of coverage when a `Call` unwinds.

Specifically, non-branching `Statement`s and `Terminator`s that follow a `TerminatorKind::Call` (if not other `TerminatorKind`s) are counted as having been "executed" by the same counter that counts the execution of the `Call`, as well as the non-branching statements that preceded the `Call`.

But if the `Call` panics, non-branching statements leading up to the `Call` will have been executed, and statements following the `Call` will *not* be executed. With only one counter, both sets of statements (before and after, and the `Call` itself will have the same execution count (either 1 or 0, depending on the type of counter, and where the counter is incremented).

To accurately count these sequences with the potential for panics, an actual code counter needs to be incremented after each successful call.

Adding these counters will increase the physical size of the binaries and slow down execution, so this is a feature that should only be enabled as an option.

One question is, how can this option be enabled granularly? 

For `#[should_panic]` tests, it makes sense to enable the option for the test function, but this would not correct the counters for panicking calls in functions called by the test function. It may be possible to trace the calls to enable the option on the functions called by `#[should_panic]` test functions, and the functions executed by those functions, but this won't work for functions from external crates.

Similar logic could be used for functions called via `catch_unwind()`, with similar limitations. 

So a worst-case approach would be to enable this feature when compiling the tested crate and all of its dependencies, using a `rustc` compiler flag.
Repository: rust
Issue: MIR InstrumentCoverage - Can the source_info.span for `FakeRead` statements be more consistent?
Labels: T-compiler,A-MIR,A-code-coverage

Rust's LLVM InstrProf-based source code coverage implementation instruments Rust code via the MIR pass InstrumentCoverage. Most criteria for identifying coverage regions and counter locations are very general, based on Control Flow Graph (CFG) analysis of the MIR, and a fairly straightforward mapping of MIR Statements and Terminators to their source code regions (Spans).

StatementKind::FakeRead are an exception, requiring special handling for at lease one case: When its `cause` is `ForGuardBinding`, the `Statement`s `source_info.span` seems to be wrong.

Example:

```rust
    match somenum {
        x if x < 1 => { ... }
    }...
```

The BasicBlock within the match arm code included one of these statements, but the span
for it covered the literal number `1` in this source. The actual `FakeRead` statement, and its components, have nothing to do with that source span:

```mir
    FakeRead(ForGuardBinding, _4);
```

where `_4` is:

```mir
    _4 = &_1; (at the span for the first `x`)
```

and `_1` is the `Place` for `somenum`.

The current workaround is to ignore these `Statement`s, and rely on other `Statement`s for coverage (which appears to provide reasonable results):

```rust
fn filtered_statement_span(statement: &'a Statement<'tcx>, body_span: Span) -> Option<Span> {
    match statement.kind {
...
        StatementKind::FakeRead(cause, _) if cause == FakeReadCause::ForGuardBinding => None,
```

But workarounds like this one may be incomplete or error-prone, and could be hard to maintain in the future. Plus, if the given span is actually wrong, this bug would have been introduced in an earlier phase (perhaps lowering AST to HIR, or a later pass), the invalid span may trigger other compiler issues.

The arm code BasicBlock already has its own assignment for `x` itself, `_3 = 1`, and I've
decided it's reasonable for that span (even though outside the arm code) to be part of
the counted coverage of the arm code execution, but I can't justify including the literal
`1` in the arm code. I'm pretty sure that, if the `FakeRead(ForGuardBinding)` has a
purpose in codegen, it's probably in the right BasicBlock, but if so, the `Statement`s
`source_info.span` can't be right.

If the span can be corrected, the match pattern for this special case can be removed.
Repository: rust
Issue: Diagnostics: suggest adding lifetime to trait object stored in struct
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler,A-suggestion-diagnostics,D-newcomer-roadblock,A-trait-objects

This code doesn't compile:

```rust
pub struct Thing {
    chars: Box<dyn Iterator<Item = char>>,
}

impl Thing {
    pub fn new(string: &str) -> Self {
        Thing {
            chars: Box::new(string.chars()),
        }
    }

    fn next_char(&mut self) -> Option<char> {
        self.chars.next()
    }
}
```

([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=19d55b5bd62e97c17046daa71242c839))

Fixing it involves adding a lifetime bound with `dyn Iterator<Item = char> + 'a`, but this syntax is not something a beginner would know. It would be nice if rustc suggested it.
Repository: go
Issue: internal/cpu: align s390x code in internal/cpu with that in x/sys/cpu
Labels: NeedsFix,early-in-cycle,compiler/runtime

Have recently had z/OS support added to x/sys/cpu (fixed golang/go#41984). That CL made most of the code common between z/OS and Linux. This issue tracks updating internal/cpu to include all changes from x/sys/cpu, except for zos-specific files (i.e. only the code which will be common).
Repository: terminal
Issue: How do I remove the right-click menu "open in Windows terminal"?
Labels: Product-Terminal,Issue-Task,Area-ShellExtension

Is it possible to turn this feature on or off with an option?
Repository: rust
Issue: Note when trait bound may be satisfied for a different version of a crate
Labels: A-diagnostics,A-trait-system,T-compiler,D-confusing,D-crate-version-mismatch

On the playground, the following code:

```rust
use bytes::Bytes;
use http::Response;
use hyper::Body;

pub fn build(data: Bytes) -> Response<Body> {
    Response::new(data.into())
}

fn main() {
}
```

currently produces the following error:

```
error[E0277]: the trait bound `hyper::Body: std::convert::From<bytes::Bytes>` is not satisfied
 --> src/main.rs:6:19
  |
6 |     Response::new(data.into())
  |                   ^^^^^^^^^^^ the trait `std::convert::From<bytes::Bytes>` is not implemented for `hyper::Body`
  |
  = help: the following implementations were found:
            <hyper::Body as std::convert::From<&'static [u8]>>
            <hyper::Body as std::convert::From<&'static str>>
            <hyper::Body as std::convert::From<hyper::body::Bytes>>
            <hyper::Body as std::convert::From<std::borrow::Cow<'static, [u8]>>>
          and 4 others
  = note: required because of the requirements on the impl of `std::convert::Into<hyper::Body>` for `bytes::Bytes`
```

Note that `hyper::body::Bytes` is an alias for `bytes::Bytes`. We should detect when an unment trait bound's substs match the fully-qualified names of our desired trait bound, and note that multiple versions of the same crate may be in use.
Repository: react
Issue: react-devtools-inline: How to remount/reuse DevTools frontend after unmount
Labels: Type: Discussion,Component: Developer Tools

DevTools closes the bridge whenever it is unmounted [(Link to relevant code)](https://github.com/facebook/react/blob/master/packages/react-devtools-shared/src/devtools/views/DevTools.js#L172-L181). In the case of the chrome extension this is fine because the node is never unmounted, but in use cases with `react-devtools-inline` (eg: codesandbox), where you are only given one <DevTools/> instance this causes the bridge to be closed, and never recreated if for whatever reason <DevTools/> is unmounted (which happens when switching tabs).

I am willing to submit a PR, but wanted to discuss the fix before making it - the fix I see is adding a flag to <DevTools/> to not close the bridge on unmount, and making it an opt-in flag users of <DevTools/> (recommended in the case of react-devtools-inline). Adding an ability to manually access the bridge would then let the developer manually control the lifecycle - but I'm unsure the risk/issue of keeping a dangling bridge open, so I don't see this as strictly necessary.

React version: N/A
React-devtools-inline: 4.9.0

## Steps To Reproduce

1.  Create a code-sandbox React environment
2. Open React DevTools tab
3. Switch to Problems tab (or any other tab)
4. Switch back to React DevTools tab
5. Bridge has been closed, `index.js:55 Cannot send message "highlightNativeElement" through a Bridge that has been shutdown.` is printed in console. New react nodes can not be inspected.

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example: N/A
Code example isn't relevant, any CodeSandbox will reproduce this. (even with no additional code)

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

## The current behavior
Inspecting elements that haven't previously been inspected will fail because bridge communication fails if the <DevTools/> ever unmounts and remounts

## The expected behavior
The bridge doesn't close even on unmount when using `react-devtools-inline`, or an option is available when mounting <DevTools/> to not automatically close the bridge.
Repository: flutter
Issue: ListView (and other ScrollViews) should have a FocusTraversalGroup by default
Labels: framework,f: scrolling,c: proposal,f: focus,P3,team-framework,triaged-framework

Proposal: We should put a FocusTraversalGroup around ListView (and the other scroll views). Currently it's a bit weird that if you put a list view in a row, with a bunch of widgets in a box next to the row, the tab order is in and out of the list.

I'm not sure if this is a good idea; there may be reasons we should not do this.

cc @gspencergoog @goderbauer
Repository: PowerToys
Issue: [FZ Editor] Left and Right Priority Grid layouts
Labels: Idea-Enhancement,FancyZones-Editor,FancyZones-Layouts,Product-FancyZones,Planning-Consideration

For FancyZones, we should have a left and right focused priority grid.

Right priority grid:
Right 50% would 1 zone
Left 50% then would be subdivided horizontally.

Left priority grid:
Right 50% would be subdivided horizontally.
Left 50% would 1 zone

For large screens, this layout could be helpful for Consoles for instant
Repository: godot
Issue: test_motion doesn't return collision with other RigidBody2D
Labels: documentation,topic:physics

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.2.2
<!-- Specify commit hash if using non-official build. -->

**OS/device including version:**
iMac
Operating system: Darwin-19.3.0-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 580 OpenGL Engine ATI Technologies Inc. 4.1 ATI-3.5.5
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->

**Issue description:**
<!-- What happened, and what was expected. -->
My test scene has two RididBody2Ds. The first has a script that uses test_motion to check for collisions to the right of itself. A second RididBody2D is over the the right. Behind that is a StaticBody2D wall. All physics nodes have their collision layer and masks at the default settings.

The code on the left-hand RigidBody2D uses test_motion to check for collisions to its right. I have a collision_marker sprite, a red circle, to visualise where the collision from the test_motion call is reported.

I was expecting the test_motion call to return a collision with the other RigidBody2D, but it seems to be ignoring it (reporting a collision with the wall beyond it instead, a StaticBody2D)

This is the code on the left-hand RigidBody2D

```
extends RigidBody2D

func _process(delta):
	var result = Physics2DTestMotionResult.new()
	var hit = self.test_motion(Vector2(30000,0),true,0.08, result)
	if hit:
		$collision_marker.set_global_position(result.get_collision_point())
```
![screenshot](https://i.imgur.com/suunF6s.png)

But if i alter the right-hand rigid body to static mode, the collision circle appears where i expected it

![screenshot2](https://i.imgur.com/BgjQqhj.png)

**Steps to reproduce:**
Open reproduction project, run the scene. The marker circle stops at the right-hand static body 'wall' (not the Rigid Body in front of it)

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[test_motion_bug.zip](https://github.com/godotengine/godot/files/5463459/test_motion_bug.zip)
Repository: terminal
Issue: Terminal should always wrap drag-dropped paths in double quotes
Labels: Help Wanted,Area-TerminalControl,Product-Terminal,Issue-Task,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


Microsoft Windows [版本 10.0.18363.1139]
Windows Terminal [ powershell]
版本: 1.3.2651.0
python 3.7


# Steps to reproduce
1.write the followings code
xx.py
import sys
with open(sys.argv[1]) as f:
       pass
2.create a txt as "xxx(1).txt", the name must include"()"
3:open windows terminal powershell, cd to the xx.py directory
       input “python xx.py”
       drop the txt into terminal 
       run
4.if the filename contain "(xx)" can not resolve the path.





# Expected behavior
it worked in cmd
open the file success
<!-- A description of what you're expecting, possibly containing screenshots or reference material. -->

# Actual behavior
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\xx\\Desktop\\\\input'
<!-- What's actually happening? -->
Repository: pytorch
Issue: Pytorch 1.7/Cuda 11.1 binaries
Labels: module: binaries,module: cuda,triaged

Will Pytorch 1.7/Cuda 11.1 binaries be provided or only CUDA 11.0?

cc @ezyang @seemethere @malfet @walterddr @ngimel
Repository: create-react-app
Issue: npm ERR
Labels: stale,needs triage


npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Admin\AppData\Roaming\npm-cache\_logs\2020-10-30T08_53_53_213Z-debug.log

Aborting installation.
  npm install --save --save-exact --loglevel error react react-dom react-scripts cra-template has failed.
Repository: pytorch
Issue: THCudaShutdown should be called before THCState_free
Labels: module: cuda,module: memory usage,triaged

td::unique_ptr<THCState, void (*)(THCState*)> CUDAHooks::initCUDA() const {
  C10_LOG_API_USAGE_ONCE("aten.init.cuda");
  THCState* thc_state = THCState_alloc();

  THCudaInit(thc_state);
#ifdef USE_MAGMA
  THCMagma_init(thc_state);
#endif
  return std::unique_ptr<THCState, void (*)(THCState*)>(
      thc_state, [](THCState* p) {
        if (p)
		{
			THCudaShutdown(p);
			THCState_free(p);
		}
      });
}

THCudaShutdown shoud be called before freeing the context or memory leak would happen.

cc @ngimel
Repository: vscode
Issue: Suggest detail does not shrink to fit content when resized
Labels: ux,suggest,under-discussion

The gif is pretty illustrative. You can see that when resized, the detail view doesn't shrink. However, when suggest is retriggered, it has appropriately shrunk. I'm not sure if this is intended behavior.

![recording (26)](https://user-images.githubusercontent.com/38270282/97697363-31a9bc00-1aa7-11eb-87d1-96f3267d9153.gif)
Repository: rust
Issue: Incorrect error order for println!
Labels: C-enhancement,A-diagnostics,T-compiler,A-inference,D-confusing,D-incorrect

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
fn main() {
    let guess = "123";
    let guess = match guess.trim().parse() {
        Ok(num) => num + 1,
        Err(_) => todo!(),
    };
    println!("guess: {}", guess);
}
```

I expected to see this happen:
```
  |
4 |         Ok(num) => num + 1,
  |            ^^^ cannot infer type
  |
help: consider specifying the type argument in the method call
  |
3 |     let guess = match guess.trim().parse::<F>() {
  |                                         ^^^^^
```

Instead, this happened:
```
  |
7 |     println!("guess: {}", guess);
  |                           ^^^^^ `()` cannot be formatted with the default formatter
  |
  = help: the trait `std::fmt::Display` is not implemented for `()`
  = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
  = note: required by `std::fmt::Display::fmt`
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
```

But eventually I will be able to see that once I use `{:?}` but users need to do an extra step to see the other warning.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`: stable 1.47.0 to nightly 1.49.0-nightly (2020-10-29 6bdae9edd0cc099daa60)
```
stable 1.47.0 to nightly 1.49.0-nightly (2020-10-29 6bdae9edd0cc099daa60)
```
Repository: pytorch
Issue: trying to Installing pytorch on python3.9 via pip results in an non-descript error
Labels: high priority,module: binaries,oncall: releng,triaged

## 🐛 Bug

I update to python 3.9, and had to reinstall pytorch. pip tried to use version 0.12, which failed with a stacktrace regarding `tools.nn`. After looking through a few issues I found one saying that pytorch only supports 3.8 at the moment.

## To Reproduce

Steps to reproduce the behavior:

1. try to install pytorch via pip (`pip install torch`) on python 3.9.

## Expected behavior

either a working install - or a notification that 3.9 isn't supported yet.

## Environment

python 3.9 x64

cc @ezyang @gchanan @zou3519 @bdhirsh @heitorschueroff @seemethere @malfet @walterddr
Repository: flutter
Issue: Add 'enableFeedback' to TabBar (and maybe other standard widgets?)
Labels: framework,f: material design,c: proposal,team-design,triaged-design

## Use case

I want to add custom tap/press sounds to button presses. To avoid double sounds I have to set `enableFeedback` on button Widgets to `false`. ElevatedButton, TextButton and OutlinedButton now work with ButtonStyle and IconButton has the `enableFeedback` parameter, but TabBar seems to be one of the few that does not support this.

To achieve what I wanted to do I had to make a copy of pretty much the whole tabs.dart file, because it contains a lot of private code, and that's just bad for maintainability.

## Proposal

Add `enableFeedback` to the TabBar parameters, defaulting to `true`, and pass it to the InkWell in its build function.
See https://github.com/flutter/flutter/issues/69021 , which is pretty much the same feature request. Maybe it would be a good thing to go over the widgets in the [Widgets catalog](https://flutter.dev/docs/development/ui/widgets/material) to make sure the ones that use InkWell all have this parameter?