sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Controls and search in Rustdoc header are visually distracting
Labels: T-rustdoc,A-rustdoc-ui

This is being broken out of #59829 to provide smaller, actionable items that can be independently discussed and worked on.

A visual inspection of the Rustdoc design reveals that there are a lot of distracting design elements, which can be especially problematic for people with dyslexia or attention disorders.

One of the first encountered is the header containing the search bar and controls. It is visually larger than the main heading of the page, it contains several high contrast icons and controls which also have additional bounding boxes, the whole thing presents a non-rectangular shape making it stand out more, and the search box contains a fairly verbose set of instructions.

![Screenshot of Rustdoc search header with issues listed in previous paragraph highlighted](https://i.imgur.com/U0WHJZM.png)

I have a few suggestions to improve the situation; some seem like obvious improvements, some are more debatable and I'm open to other suggestions:

* [x] Drop the horizontal rule, or make it span the full width and low contrast like the mdBook style after scrolling down #92797
* [x] Drop the boxes around the icons
* [ ] ~~Make the icons and "All Crates" control lower contrast~~
* [x] Increase the size of the main heading of the page to be larger than the search and controls heading
* [x] Consider removing the "All Crates" dropdown; I am not sure it is pulling its weight. If it is useful, it could instead be an option that appears after doing a search, rather than appearing on every page. #92490
* [x] Consider moving theme and settings into a single menu #92629
* [ ] Consider simplifying text to simply say "Search" and providing help elsewhere, such as in the above single menu
* [ ] Consider making the header span the whole width of the page, rather than appearing to be nested within the content by being inside the area delimited by the sidebar. This would be a significant change to the overall Rust docs style, but seems more consistent with the way many other sites are laid out.
Repository: rust
Issue: E0623: Incorrect or ambiguous message
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler,D-confusing,D-newcomer-roadblock

I encountered the following error:
```
error[E0623]: lifetime mismatch
  --> src/algorithm/simplex/branch_and_bound/logic.rs:47:73
   |
34 |       tableau: Tableau<'data_provider, NonArtificial, AdaptedMatrixProvider<'original_data, MP>, PR>,
   |                ------------------------------------------------------------------------------------- these two types are declared with different lifetimes...
...
47 |           let lower_provider: AdaptedMatrixProvider<'original_data, MP> = tableau.provider().clone_with_extra_bound(branch_variable,
   |  _________________________________________________________________________^
48 | |                                                                                                                   new_lower_bound,
49 | |                                                                                                                   BoundType::Lower);
   | |___________________________________________________________________________________________________________________________________^ ...but data from `tableau` flows into `tableau` here
```
Looking at [line 47](https://github.com/vandenheuvel/rust-lp/blob/892bf3193c826cbcad479179e91d0e92f1aec8f0/src/algorithm/simplex/branch_and_bound/logic.rs#L47), this seems to be incorrect: data doesn't flow into `tableau`. Merely, another reference is created to a value which is also referenced by the existing `tableau`.

Moreover, it doesn't look like there are two types being pointed at by the compiler. The two types being referenced might be the outer and inner type though, but this is unclear and if this is the case, I think it requires change.

I tried to reproduce this issue on the playground, but was [not successful](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=eeb09142773da1cdbd5b7ac6ee3b381e). The full code can be found [here](https://github.com/vandenheuvel/rust-lp/blob/892bf3193c826cbcad479179e91d0e92f1aec8f0/src/algorithm/simplex/branch_and_bound/logic.rs#L47). A slightly different state of the codebase, with a similar error, can be found [here](https://github.com/vandenheuvel/rust-lp/blob/9b3ef9516123f4465a741f855b261fb729e148ba/src/algorithm/simplex/branch_and_bound/logic.rs#L47).

@estebank Looking at related issues, I thought that this might be relevant to you.
Repository: pytorch
Issue: [jit] Can't `torch.jit.script` a lambda
Labels: oncall: jit,low priority,triaged,jit-backlog

Something like `torch.jit.script(lambda x: x + 2)` fails since our source introspection requires a standalone function


cc @suo
Repository: pytorch
Issue: Embedding layer does not check input range
Labels: module: cuda,module: error checking,triaged

## 🐛 Bug

Embedding layer does not check input range when running on cuda

## To Reproduce

Code to reproduce the behavior:

```
import torch
import torch.nn as nn

emb = nn.Embedding(10, 20).cuda()
x = torch.zeros(5, 1).long() + 10
x = x.cuda()

y = emb(x)

z = torch.zeros(10).cuda()
```


```
RuntimeError                              Traceback (most recent call last)
<ipython-input-1-758fb390ae81> in <module>()
      8 y = emb(x)
      9 
---> 10 z = torch.zeros(10).cuda()

RuntimeError: CUDA error: device-side assert triggered
```

## Expected behavior

It should raise a correct error

## Environment

PyTorch version: 1.0.1.post2
Is debug build: No
CUDA used to build PyTorch: 9.0.176

OS: Ubuntu 18.04.1 LTS
GCC version: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
CMake version: Could not collect

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: 9.1.85
GPU models and configuration: 
GPU 0: GeForce GTX 1080 Ti
GPU 1: GeForce GTX 1080 Ti

Nvidia driver version: 390.116
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy==1.16.2
[pip3] torch==1.0.1.post2
[pip3] torchvision==0.2.2.post3
[conda] Could not collect
Repository: pytorch
Issue: Multi-gpu via torch::nn::parallel::data_parallel
Labels: oncall: distributed,module: cpp,feature,triaged

## 🐛 Bug
I tried to use multi-gpu capability in `C++`, but when I write `torch::nn::parallel::data_parallel`, I am getting `No member named 'parallel' in namespace 'torch::nn'` error. 

## To Reproduce

Steps to reproduce the behavior:

Just add `torch::nn::parallel::data_parallel` in code with torch.h included. 

## Expected behavior
It should at least know `parallel` namespace. 

## Environment
```
PyTorch version: 1.0.1.post2
Is debug build: No
CUDA used to build PyTorch: 9.0.176

OS: Red Hat Enterprise Linux Server 7.6 (Maipo)
GCC version: (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
CMake version: version 3.12.0

Python version: 2.7
Is CUDA available: Yes
CUDA runtime version: 7.5.17
GPU models and configuration:
GPU 0: Tesla P100-PCIE-16GB
GPU 1: Tesla P40

Nvidia driver version: 384.81
cuDNN version: /usr/lib64/libcudnn.so.7.5.0

Versions of relevant libraries:
[pip] numpy==1.16.2
[pip] tinynumpy==1.2.1
[pip] torch==1.0.1.post2
[pip] torchvision==0.2.1
[conda] Could not collect

```
## Additional context

<!-- Add any other context about the problem here. -->
Is `torch::nn::parallel::data_parallel` functional now? 

cc @yf225 @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar
Repository: go
Issue: net/http: http.Client Timeout incompatible with writable bodies
Labels: NeedsInvestigation

As part of #26937, Transport started returning writable bodies for 101 Switching Protocol responses. This is great, thank you!

However, if you have a non-zero Timeout on your http.Client, you can't use this, because of the following [lines from client.go](https://github.com/golang/go/blob/fda5e6d6fa7abfe974a58dfeeceb95a8165d1b63/src/net/http/client.go#L266):

```
	if !deadline.IsZero() {
		resp.Body = &cancelTimerBody{
			stop:          stopTimer,
			rc:            resp.Body,
			reqDidTimeout: didTimeout,
		}
	}
```

This wraps the writable body in a non-writable body.

Go version: 1.12
Observed behavior: res.Body.(io.ReadWriteCloser) fails when client.Timeout > 0.
Expected behavior: timeouts and writeable bodies are compatible.

Although we have some streaming requests, we would like to set a long (eg one hour) timeout on our requests to prevent resource exhaustion. #30876 suggests that we can't even do this manually with contexts.
Repository: pytorch
Issue: weight_norm doesn't support eta and returns nan for zero weights
Labels: module: nn,triaged,module: NaNs and Infs,module: norms and normalization

## 🐛 Bug

backprop on weights generated with torch._weight_norm that are zero filled yields nan gradients. I don't see a way to add an eta to the norm to prevent this.

## To Reproduce

Steps to reproduce the behavior:

```
w = torch.zeros(1, 3)
v = w / w.norm()
g = w.norm()
v.requires_grad = True
g.requires_grad = True
torch._weight_norm(v, g).matmul(torch.randn(3,1)).backward()
v.grad
> tensor([[nan, nan, nan]])
g.grad
> tensor(nan)
```

I'm encountering nan's during backprop during training of a network with weight normalization. From this seemingly related thread it sounds like the advice is to add an eta to the norm, but in this case the norm is generated in pytorch's c++ implementation and I don't see an obvious way to do this.

## Expected behavior

I expect there to be a way to generate non-nan gradients for weight-norm weights that are zero filled

## Environment

 - PyTorch Version (e.g., 1.0): 1.0.0
 - OS (e.g., Linux): Mac and Centos
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source):
 - Python version: 3.6
 - CUDA/cuDNN version: None
 - GPU models and configuration: None
 - Any other relevant information:

## Additional context



cc @albanD @mruberry
Repository: rust
Issue: thumbv7a-pc-windows-msvc cannot find cl.exe when trying to expand c file for openssl-sys
Labels: O-Arm,T-compiler,O-windows-msvc,C-bug

I'm working on Windows 10 building Azure iot-edge for arm32, I was able to compile rust for arm successfully, using below command
`c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc`

However, when I use the output to build iotedge, which has a dependency on openssl-sys (0.9.36 is the version we use), in https://github.com/sfackler/rust-openssl/blob/openssl-sys-v0.9.36/openssl-sys/build/main.rs#L420-L428, it tries to expand a c file, in try_expand implementation, https://github.com/alexcrichton/cc-rs/blob/1.0.15/src/lib.rs#L2119-L2135, spawn fails as it does not know where to find a x64-x64 cl.exe for the expansion

So it looks like cargo does set up environment correctly for the x64-arm compilation, however, crates are having a hard time to locate x64-x64 MSVC toolchain. I think this is something in rust itself needs to be fixed, I'd appreciate any pointers to potential locations inside rust that I can dig further.

p.s. I ended up with adding the folder of x64-x64 cl.exe into PATH, to be specific (%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64), and I was able to workaround this issue and built everything fine.

Thanks
Chandler
Repository: godot
Issue: Remember the value of the animation timeline scale slider for each animation
Labels: enhancement,topic:editor,usability

- Create an animation.
- Drag the timeline scale slider to some non-default value.
- Save the project.
- Close the project.
- Reopen the project. The value that was set with the slider has been forgotten. The expected behaviour is that the value is saved in e.g. the project file or some file specific to the project.
Repository: pytorch
Issue: pytorch.version.cuda is None when compiling with CUDA support
Labels: needs reproduction,module: build,module: cuda,triaged

Compiling PyTorch from sources (487388d8) ends up with torch.version.cuda = None leading to errors when trying to import apex: 

```
    from apex import amp
  File "/data/Workspace/miniconda3/envs/pytorch/lib/python3.7/site-packages/apex/__init__.py", line 2, in <module>
    from . import amp
  File "/data/Workspace/miniconda3/envs/pytorch/lib/python3.7/site-packages/apex/amp/__init__.py", line 1, in <module>
    from .amp import init, half_function, float_function, promote_function,\
  File "/data/Workspace/miniconda3/envs/pytorch/lib/python3.7/site-packages/apex/amp/amp.py", line 3, in <module>
    from .lists import functional_overrides, torch_overrides, tensor_overrides
  File "/data/Workspace/miniconda3/envs/pytorch/lib/python3.7/site-packages/apex/amp/lists/torch_overrides.py", line 67, in <module>
    if utils.get_cuda_version() >= (9, 1, 0):
  File "/data/Workspace/miniconda3/envs/pytorch/lib/python3.7/site-packages/apex/amp/utils.py", line 9, in get_cuda_version
    return tuple(int(x) for x in torch.version.cuda.split('.'))
AttributeError: 'NoneType' object has no attribute 'split'
```
Repository: go
Issue: regexp: improve test coverage
Labels: Testing,NeedsFix

There are some areas of the regexp module that are not covered by the tests, as extensive as they already are.

Mostly, they include some prefix stuff (that may have caused #30511 & #30425), some utf8 code paths, some case folding, some paths in onepass and the RuneReader input interface. 

Does the idea of trying to run all test regexps through all 3 matchers (onepass when possible, backtrack, nfa) and all 3 input types (string, bytes, reader) sound good? We should aim for each of them being individually correct, and this would help adding new ones in the future (dfa!).

I'm starting work on a CL. I want to throw in some of the fuzzing I did before in #21463, should I add it here or open a separate issue/CL?

Thanks!
Repository: rust
Issue: Suggestion for improved nested trait error messages when not implemented.
Labels: A-diagnostics,A-trait-system,T-compiler,D-terse,S-needs-repro

Hi,

I was recently experiencing a confusing error message communication due to an error while developing an actix-web application. The error was:

```
error[E0277]: the trait bound `fn((actix_web::Json<proto::LoginRequest>, actix_web::HttpRequest)) -> actix_web::HttpResponse {login}: actix_web::with::WithFactory<_, AppState<'_>, _>` is not satisfied
   --> src/main.rs:117:18
    |
117 |                 .with_config(login, |((cfg, _),)| {
    |                  ^^^^^^^^^^^ the trait `actix_web::with::WithFactory<_, AppState<'_>, _>` is not implemented for `fn((actix_web::Json<proto::LoginRequest>, actix_web::HttpRequest)) -> actix_web::HttpResponse {login}`



```

The relevant code parts are:

```
fn login((lgn, state): (Json<LoginRequest>, HttpRequest<AppState>)) -> HttpResponse {
    HttpResponse::Ok().json(())
}

#[derive(Debug, Serialize)]
struct Data {
    data: u64
}

```

This error was unhelpful in resolution of the problem on a number of levels. It was only when asking for help that I was told of the method to resolve the cause. The error is that WithFactory can't be implemented, as FromRequest isn't implemented on (A, B) where A: FromRequest, B: FromRequest. In my case, A did not implement FromRequest, and this was due to lack of DeserializedOwned on Data.

A more constructive error message in this situation would have been:

```
the trait `actix_web::with::WithFactory<_, AppState, _>` is not implemented for `fn((actix_web::Json<Data>, actix_web::State<AppState>)) -> actix_web::HttpResponse {register}`
the trait `FromRequest` is not implemented for `(actix_web::Json<Data>, actix_web::State<AppState>)`
the trait `FromRequest` is not implemented for `actix_web::Json<Data>`
the trait `DeserializedOwned` is not implemented for `Data`
```

This could be found easily by checking the traits on each argument, and then recursing into that type and checking why the outer trait is not implemented. For example, (A, B) can't be FromRequest, because A is not FromRequest (but B is) so you would descend into A to determine why it does not implement FromRequest. 

It was posed to me that this is not possible for rustc to solve, and that IDE's would abstract the problem. First, I think that given the other amazing advances in rustc, this error communication can be created and solved :). Second, not everyone uses an IDE, or that IDE may not have the features required to display an error like this. It would also be difficult for users requesting assistance or getting start to configure IDE's or be expected to use them, and automated systems like a CI should be able to report detailed errors when they occur. 

I would also guess that this style of recursive trait error reporting would be of great use to a library like Futures, and many other applications. It would certainly improve accessibility to traits which often are seen as a deeply complex part of the rust ecosystem.

I hope this helps, thanks,
Repository: rust
Issue: x.py's naming of stages is confusing
Labels: T-bootstrap,A-contributor-roadblock,C-discussion

Rust has the standard multi-stage structure that all bootstrapping compilers have.

A newcomer who knows about compiler stages will be confident with this, until they run a command like `./x.py build --stage 1` and get output like this:
```
Building stage0 std artifacts 
    ...
Copying stage0 std from stage0
Building stage0 test artifacts 
    ...
Copying stage0 test from stage0
Building stage0 compiler artifacts 
    ...
Copying stage0 rustc from stage0
Building stage0 codegen artifacts 
    ...
Assembling stage1 compiler 
Building stage1 std artifacts 
    ...
Copying stage1 std from stage1
Building stage1 test artifacts 
    ...
Copying stage1 test from stage1
Building stage1 compiler artifacts 
    ...
Copying stage1 rustc from stage1
Building stage1 codegen artifacts 
    ...
Building rustdoc for stage1 
    ...
```
For a newcomer, this is completely bizarre.
- Why is it building stage 0? Isn't stage 0 the compiler you download?
- How does it assemble the stage 1 compiler before building the stage 1 artifacts?
- Why is it building two stages? Shouldn't it only build one stage?

The key to understanding this is that `x.py` uses a surprising naming convention:
- A "stage N artifact" is an artifact that is *produced* by the stage N compiler.
- The "stage (N+1) compiler" is assembled from "stage N artifacts".
- A `--stage N` flag means build *with* stage N.

Somebody had to explain this to me when I started working on Rust. I have since had to explain it to multiple newcomers. Even though I understand it now, I still find it very confusing, and I have to think carefully about it all.

Here's a naming convention that makes more sense to me:
- A "stage N artifact" is an artifact that is produced by the stage (N-1) compiler.
- The "stage N compiler" is assembled from "stage N artifacts".
- A `--stage N` flag means build stage N, using stage (N-1).

That way, a command like `./x.py build --stage 1` would produce output like this:
```
Building stage1 std artifacts 
    ...
Copying stage1 std from stage1
Building stage1 test artifacts 
    ...
Copying stage1 test from stage1
Building stage1 compiler artifacts 
    ...
Copying stage1 rustc from stage1
Building stage1 codegen artifacts 
    ...
Assembling stage1 compiler 
```
Is there any appetite for this change? I realize it would be invasive and people would have to update their aliases, build scripts, etc. But it might be worthwhile to avoid the ongoing confusion to both newcomers and experienced contributors. Deprecating the word "stage" in favour of  "phase" could help with the transition.
Repository: rust
Issue: lifetime error mentions implemented trait instead of the associated type and the mismatched type.
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler

In [this reddit thread](https://www.reddit.com/r/rust/comments/bbswe6/confusing_error_message_cannot_infer_lifetime/) a user commented on their confusion with an error message.

The problem is that the lifetime error for this code mentions `Iterator` twice in the error message instead the types whose lifetimes don't match.

The code that triggers the bug:
```
use std::marker::PhantomData;

struct AnIterator<'a> {
    first: String,
    _marker:PhantomData<&'a str>
}

impl<'a> Iterator for AnIterator<'a> {
    type Item = &'a str;

    fn next<'b>(&'b mut self) -> Option<Self::Item> {
        Some(self.first.as_str())
    }
}

```

The error message:
```
   Compiling playground v0.0.1 (/playground)
error[E0495]: cannot infer an appropriate lifetime for autoref due to conflicting requirements
  --> src/lib.rs:12:25
   |
12 |         Some(self.first.as_str())
   |                         ^^^^^^
   |
note: first, the lifetime cannot outlive the lifetime 'b as defined on the method body at 11:13...
  --> src/lib.rs:11:13
   |
11 |     fn next<'b>(&'b mut self) -> Option<Self::Item> {
   |             ^^
note: ...so that reference does not outlive borrowed content
  --> src/lib.rs:12:14
   |
12 |         Some(self.first.as_str())
   |              ^^^^^^^^^^
note: but, the lifetime must be valid for the lifetime 'a as defined on the impl at 8:6...
  --> src/lib.rs:8:6
   |
8  | impl<'a> Iterator for AnIterator<'a> {
   |      ^^
   = note: ...so that the types are compatible:
           expected std::iter::Iterator
              found std::iter::Iterator

error: aborting due to previous error

For more information about this error, try `rustc --explain E0495`.
error: Could not compile `playground`.

```
Here in the last note,instead of saying `expected std::iter::Iterator` `found std::iter::Iterator`,
it should be `expected &'a str` `found &'b str`.

It prints the correct error message if I change ` ->Option<Self::Item>` to `->Option<&'a str>`.
Repository: rust
Issue: rustdoc: module flag to prevent code blocks without a lang item from counting as rust
Labels: T-rustdoc,C-feature-request

So, I've got some code being generated by `bindgen`. The C source has `doxygen` doc comments in it, which `bindgen` faithfully converts over into doc comments. However, some of the `doxygen` content is indented with spaces (numbered lists and the like), so when converted into rustdoc it becomes a code block. These code blocks are picked up as "doctests" by `cargo test`, which then of course fail to build because they're not Rust code at all.

I'm told that, internally, this is all just code block elements by the time rustdoc sees it, you can't tell which code block was made via a backtick fence and which was made via indentation. However, you _can_ tell if a lang was declared on the code block.

So what I need is an opt-in flag that you can declare module-wide (and children modules and such) so that any code block _without_ a declared language is not treated as rust code by default, so then it won't become a doctest.