primordic/IssueDupesLite huggingface dataset:
Repository: rust-lang/crates.io

Issue #67: Feature request: way to set up a mirror
Created: 2014-11-23T02:51:15Z
I'm so excited crates.io has arrived!! 🎉 Great work, Alex and everyone!!!
This is a longer-term feature request... one thing that has been an occasional yet painful experience with rubygems.org or npmjs.org is when they're down. At various points in time, my coworkers and I have tried to set up mirrors under our control of both of these and it never went very smoothly, neither on the setup or usage side of things.
I would love love love to have mirroring be something officially supported and encouraged for the health of the community, but I realize this is a difficult problem too :)
Thank you for your work!! ❤️

Duplicate issue #1403: Please make are mirror crates.io
Created: 2018-05-24T14:58:19Z
Hello! In my country government make are block list of IP. And my internet provider block crates.io =(
Please help me!

Closing comment (2019-10-09T14:14:27Z): I'm going to close this as a duplicate of #67.
Repository: rust-lang/crates.io

Issue #844: When a crate does not exist: e is undefined
Created: 2017-07-01T20:10:13Z
The stacktrace is:
  afterModel@https://crates.io/assets/cargo-eb31bb8e83fbda8fca03d28016814e31.js:146:240
v@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:3783:83
runSharedModelHook@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:3857:7
runAfterModelHook@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:3856:37
u/<@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:3766:18
R@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:3934:82
S@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:3935:12
k@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:3933:144
invokeWithOnError@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:1441:240
flush@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:1446:74
flush@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:1452:26
end@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:1454:5
run@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:1467:61
join@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:1467:181
u.join@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:2672:26
ajax/</c.error@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:4723:1
l@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:579:113
fireWith@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:580:716
n@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:767:453
r/<@https://crates.io/assets/vendor-15e547a9fd1a06a21cabb7392b824587.js:795:194

Duplicate issue #873: https://crates.io/crates/getopt shows javascript error
Created: 2017-07-10T09:54:31Z
This may be related to issue #717 even though the console reports an 404 error.
When i browse to https://crates.io/crates/getopt i get the expected Crate 'getopt' does not exist error on the top of the page. Additionally i see an JavaScript error.
It appears on 3 different browser's (on the same machine) and on my mobile phone.
Home Laptop
Microsoft Windows 10 Version 1703
Vivaldi (Chromium Fork)
Browser version: 1.10.867.38 (Stable channel) (32-bit)
Image: https://i.imgur.com/bWJUMCY.png
Error Code: https://ghostbin.com/paste/yeub3
Firefox
Browser version: 54.0.1 (64-Bit)
Image: https://i.imgur.com/Uq8pcOy.png
Error Code: https://ghostbin.com/paste/bd3ae
Edge
Browser Version: Microsoft Edge 40.15063.0.0 & Microsoft EdgeHTML 15.15063
Image: https://i.imgur.com/kj0Qs0h.png
Error Code: https://ghostbin.com/paste/f2yah
Mobile Phone
Samsung Galaxy S5
LineageOS 14.1-20170705-NIGHTLY-klte
Chrome
Browser Version: 59.0.3071.125
Image: https://i.imgur.com/4VCThAi.jpg
Error Code: https://ghostbin.com/paste/qrh8y
The correct page (https://crates.io/crates/getopts) loads without errors.

Closing comment (2017-07-10T14:27:13Z): Thanks for this report! This is a duplicate of #844 actually, I'm closing as such :)
Repository: rust-lang/crates.io

Issue #849: Allow restricting API token to publish a subset of crates
Created: 2017-07-02T14:27:44Z
Now that #688 is available, it would be great to be able to generate a token that is only able to publish a single/limited subset of crates. (A subset to account for things like proc-macro crates commonly being published as a pair of relatively tightly coupled crates).
I'm not sure exactly where the UI for creating these tokens should go, one idea I have had so far:

In the "New Token" row on the "Account Settings" page add a little expander with text like "Limit Token Access", expanding that can show a list of all crates with checkboxes for selecting which to be able to publish to.

I feel that would not be great for a user that has access to many many crates though.
Alternative idea I had was to somehow do it via the crate page instead. I don't see any nice to allow adding additional crates to the token that doesn't basically end up with a massive list like above.

Probably worth doing a survey of if any other package repositories support something similar. Closest parallel I can think of is GitHub repository scoped API tokens, but as far as I'm aware they don't allow for accessing a selection of repositories; you either have a token that can access all repositories you have access to, or a token that can access a single repository. I'll try and take a look soon and update here.

Duplicate issue #1239: Support crate-specific auth tokens
Created: 2018-01-18T21:00:38Z
I'd like to publish crates via tag builds on CI, but would prefer to restrict the privileges I'm granting though the Cargo auth token. It'd be nice if you could make auth tokens that were only allowed to publish releases for a specific set of crates.

Closing comment (2019-05-01T21:54:02Z): @sgrif this is a dup of #849
Repository: rust-lang/crates.io

Issue #788: Crates.io returns 404 when not specifying `Accept: text/html`
Created: 2017-06-20T07:02:02Z
awesome-rust uses awesome_bot to check links. Unfortunately links to crates.io return 404.
curl https://crates.io/keywords/cassandra receives a 404, too.

Current summary

This is confirmed as a bug that still exists as long as this issue is open. We do not need any further confirmations of the issue at this time.
What we do need is a PR fixing the problem, those are quite welcome
The workaround for this issue is to pass an Accept header of text/html.

Duplicate issue #163: 404 response for HEAD request with no Accept: 
Created: 2015-06-26T10:25:01Z
Steps to reproduce:

$ curl -I https://crates.io/
HTTP/1.1 404 Not Found
<...>
Content-Type: application/json; charset=utf-8

With Accept: text/html everything is okay:

$ curl -H "Accept: text/html" -I https://crates.io/
HTTP/1.1 200 OK
<...>
Content-Type: text/html

Closing comment (2019-10-09T14:33:32Z): Closing as a duplicate of #788.
Repository: rust-lang/crates.io

Issue #510: Redirecting to the latest crate should only use non-yanked versions
Created: 2017-01-20T17:49:37Z
Right now, if I visit https://crates.io/crates/quickcheck, I am redirected to the "This crate has been yanked" page (for version 0.4.2). However, we could just instead redirect to 0.4.1, the previous non-yanked version.

Duplicate issue #1444: Display latest non-yanked version of crates
Created: 2018-06-26T21:10:15Z
When selecting a crate whose latest version has been yanked, crates.io shows the message "This crate has been yanked, but it is still available for download for other crates that may be depending on it."
This page should provide a link to the last non-yanked version of the crate so that users don't have to manually search through the previous versions to find the newest non-yanked version of the crate.

Closing comment (2018-06-27T01:22:36Z): Closing as a duplicate of #510. Thanks!
Repository: rust-lang/crates.io

Issue #306: Going to dependent crates then back makes the crate look like it depends on itself
Created: 2016-04-08T14:09:21Z
Go to the page of a crate that has some dependencies.
Click on the link of one of the dependencies
On the page of the dependecy, click on "dependent crates".
Click on the link to the original crate again
Look at the dependency links:

The dependency that we were following is now gone
The crate now seems to depend on itself

Duplicate issue #444: Dependency link replaced by crate name on browser-back
Created: 2016-09-17T19:56:52Z
For some crates, when following a dependency link and then performing a browser-back to return to the original crate page, the previous link text is replaced by the name of the crate itself (e.g., ahrs dependency nalgebra becomes ahrs; also occurs in multi-dependency lists such as abc).
However, that doesn't appear to be the case for all crates (e.g., nalgebra), so maybe there's an issue with the metadata?
This has been tested on Chrome and Firefox, so I don't think it's a browser-specific issue.

Closing comment (2017-02-21T23:00:08Z): I think this is a dupe of #306, please reopen if I'm missing something :)
Repository: rust-lang/miri

Issue #1567: Miri can't find crate after toolchain update
Created: 2020-09-30T09:34:26Z
So our project was using toolchain version nightly-2020-06-10 with miri like:
rustup component add miri rustfmt
cargo miri setup
cargo clean
cargo miri test

after updating toolchain to nightly-2020-09-28 same build continuously fails with:
error[E0463]: can't find crate for `array_tool`
   --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/jsonpath_lib-0.2.5/src/lib.rs:125:1
    |
125 | extern crate array_tool;
    | ^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

Though, in the previous toolchain version that Miri has been shipped, this wasn't an issue. Any idea what might be going wrong?
P.S. We've changed the flag passing to MIRIFLAGS with MIRIFLAGS="-Zmiri-disable-isolation".

Duplicate issue #1691: Cannot compile a crate with a `crate-type = ["rlib"]` dependency
Created: 2021-01-26T12:35:08Z
See danielhenrymantilla/rust-uninit#4
Steps to reproduce the problem
Have a crate with a crate-type = ["rlib"] dependency (that gets used):
cd $(mktemp -d)

cargo init --lib --name foo

cargo new --lib bar && echo 'bar = { path = "bar" }' >> Cargo.toml

cat >>bar/Cargo.toml<<\#\ END
[lib]
crate-type = ["rlib"]
# END

echo 'use ::bar;' >> src/lib.rs

cargo miri test
The last command fails with:
error: extern location for bar does not exist: /private/var/folders/m_/347zzk7j6nz08tt6z3tnd3z00000gn/T/tmp.c7NSx84d/target/x86_64-apple-darwin/debug/deps/libbar-03d28c0dc71f4bad.rmeta
 --> src/lib.rs:8:7
  |
8 | use ::bar;
  |       ^^^


When I tried to debug this with a -vv flag, the copy-pasted compilation invocation of crate bar yielded no compilation artifacts (mainly, no .rmeta file).

Host context


As you can see from the error message, this, at least, happens on the x86_64-apple-darwin platform; will try to test this on Linux now Same for x86_64-unknown-linux-gnu.


cargo -V
cargo 1.51.0-nightly (783bc43c6 2021-01-20)

Closing comment (2021-01-26T12:40:42Z): This sounds similar to #1567 (which got fixed) and #1627 (for which we failed to get a reproducible example).
Repository: rust-lang/miri

Issue #700: "cargo miri test" ignores "test = false"
Created: 2019-04-19T08:03:33Z
cargo miri test will run the tests for all binary and library targets, even if they have test = false set.

Duplicate issue #1512: "cargo miri test" ignores "required-features"
Created: 2020-08-16T13:55:30Z
cargo test compiles and runs only tests that aren't disabled via required-features = ["foo"] (or test = false) in Cargo.toml.
cargo miri test tries to compile and run all tests, resulting in either target `test_foo` in package `xyz` requires the features: `foo` or arbitrary errors from explicitly disabled tests.
A fix for this would probably check for the args --no-default-features --features="..." and --all-features, pass them to cargo_metadata::MetadataCommand, read Node::features, and then filter the targets returned by list_targets().

Closing comment (2020-08-16T13:59:21Z): Thanks for the report!
The part about test = false is a duplicate of #700, which is blocked on oli-obk/cargo_metadata#114. So let's use this issue for the required-features problem, which I was not aware of.
Really the best thing would be if we didn't have to re-implement the entire binary selection of cargo, which is tracked separately in #739.
Repository: rust-lang/miri

Issue #3302: convert intrinsic shims to intrinsics with fallback bodies
Created: 2024-02-16T18:29:17Z
Now that rustc supports rust-lang/rust#93145 we can add support for it to miri and start removing some shims, writing them in pure rust in libcore instead

Duplicate issue #3397: teach miri to use intrinsics' fallback bodies
Created: 2024-03-23T10:37:36Z
And then replace lots of our SIMD and numeric  shims with fallback bodies by adding said fallback bodies to libcore.
Note that we need to take lots of care to preserve UB.
This may regress diagnostics quality, so maybe we need some sort of unreachable_unchecked intrinsic equivalent which can be passed a string that explains the UB?

Closing comment (2024-05-03T17:45:15Z): Isn't this a duplicate of #3302?
Repository: rust-lang/miri

Issue #739: Reuse cargo's binary selection in `cargo miri`
Created: 2019-05-21T14:37:46Z
Currently, cargo miri run will run all the binaries in the project (ouch) and cargo miri test will test all binaries and libraries.  This leads to issues like #700 (we run tests even when they are disabled), and it means one cannot run examples with Miri.
We should find a way to re-use cargo's selection of binaries, tests and so on.

Duplicate issue #1173: Unable to run individual binaries with cargo-miri when multiple binaries exist
Created: 2020-02-12T21:26:03Z
Consider a cargo project with multiple binaries inside src/bin/:
$ tree src
src
└── bin
    ├── a.rs
    └── b.rs

1 directory, 2 files

Invoking cargo miri run runs each binary through miri, one after the other. I'm not sure whether this is behaviour is intentional, since cargo run would complain about the ambiguity of which target to run.
Unfortunately, however, should a cause miri to error, miri will exit. This means b is never run.
What's more, specifying a single target to run via the --bin argument, causes miri to error:
$ cargo miri run --bin a
error: extra arguments to `rustc` can only be passed to one target, consider filtering
the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target

I'm assuming this is because miri run is really just a wrapper around a custom rustc driver which starts the miri interpreter. If this is true, how can I tell miri to only run a specified binary? And how can I ensure that b runs regardless of the result of a?
Thanks for the help!
Miri Version
$ cargo miri --version           
miri 0.1.0 (75417e5 2020-01-31)

Closing comment (2020-02-13T17:12:17Z): Hi @RalfJung

I think this is a duplicate of #739 -- could you check?

You're right. Sorry I missed this one.

A work-around is to use the miri binary directly, which is the underlying "driver" for cargo miri. It behaves like rustc, except instead of generating code it interprets the program.

I'll give this one a go, thanks. I'll close this as a duplicate.
Repository: rust-lang/miri

Issue #1367: Stacked borrows analysis is super-linear (in time and space)
Created: 2020-04-25T12:51:16Z
While trying to prepare the codebase I am working on for frequent miri usage I found a few related test cases that seem to be messing with the runtime of cargo miri test.
After a quick chat with @oli-obk it was found that when disabling stacked borrows analysis via -Zmiri-disabled-stacked-borrows the required time to analyse the tests via miri dropped significantly back to what would be expected from a miri run that is normally approximately slower compared to native execution by a magnitude of 5.
The approximated "benchmarks" are the following:
With stacked borrows analysis enabled:



Iterations
required time




1
0.0s


10
0.5s


100
5s


1000
7m50s


10_000
N/A



Note that for exhausting the data structure under test a minimum of 8193 iterations are needed to explain the 10k iterations in this test.
With stacked borrows analysis disabled:



Iterations
required time




1
0.0s


10
0.3s


100
2.5s


1000
37s


10_000
4m55s



The tested algorithm is approximately linear to the iterations with the test but with a very low factor. The actual type of operation mainly performed in this test is bit-fiddling since we are mainly working on a bitvector data structure and on a bit level of detail.
It seems to me that the stacked borrows analysis somehow explodes given this type of code.
The original code of the test in question can be found here:
https://github.com/paritytech/ink/blob/redo-init-and-flush/core/src/storage2/alloc/tests.rs#L63
Test the code via:
cargo miri test -- -- many_alloc_and_free_works

Or test the code with disabled stacked borrows using:
cargo miri test -- -Zmiri-disable-stacked-borrows -- many_alloc_and_free_works

The used miri version yielded by cargo miri --version is the following:
miri 0.1.0 (5c823a1 2020-04-15)

I will try to minimize the test case and make another post if I succeed.

Duplicate issue #1780: Miri hangs when a test fails
Created: 2021-04-19T19:55:54Z
Given the simple library:
#[cfg(test)]
mod tests {

    #[test]
    fn failed() {
        assert_eq!(1, 2);
    }
}
and then running
RUST_BACKTRACE=full MIRIFLAGS="-Zmiri-disable-isolation" cargo +nightly miri test
the output results in:
    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests (target/x86_64-unknown-linux-gnu/debug/deps/test_miri-72fa64ca114eaddd)

running 1 test
test tests::failed ... FAILED

failures:

and then just infinitely hangs.

Closing comment (2021-12-16T14:27:52Z): Okay, closing as a duplicate of #1367 then.
Repository: rust-lang/miri

Issue #2749: can't call foreign function: sched_setaffinity
Created: 2023-01-06T06:41:41Z
Running a basic test program against glommio:
$ MIRIFLAGS="-Zmiri-disable-isolation" cargo +nightly miri run --all-features --verbose
error: unsupported operation: can't call foreign function: sched_setaffinity
   --> /home/vlovich/.cargo/registry/src/github.com-1ecc6299db9ec823/nix-0.23.2/src/sched.rs:175:13
    |
175 | /             libc::sched_setaffinity(
176 | |                 pid.into(),
177 | |                 mem::size_of::<CpuSet>() as libc::size_t,
178 | |                 &cpuset.cpu_set,
179 | |             )
    | |_____________^ can't call foreign function: sched_setaffinity
    |
    = help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support
    = note: BACKTRACE:
    = note: inside `nix::sched::sched_linux_like::sched_setaffinity` at /home/vlovich/.cargo/registry/src/github.com-1ecc6299db9ec823/nix-0.23.2/src/sched.rs:175:13: 179:14
    = note: inside `glommio::executor::bind_to_cpu_set::<std::iter::Map<glommio::executor::placement::CpuIter, [closure@glommio::executor::placement::CpuIter::cpu_binding::{closure#0}]>>` at /home/vlovich/.cargo/registry/src/github.com-1ecc6299db9ec823/glommio-0.7.0/src/executor/mod.rs:220:5: 220:48

Not sure if it's expected to not work but figured I'd report it. I'm sure there may be others.

Duplicate issue #2834: Cannot run a miri test on a glommio application
Created: 2023-04-06T21:08:18Z
Basically glommio runs some OS functions, like:
175 | /             libc::sched_setaffinity(
176 | |                 pid.into(),
177 | |                 mem::size_of::<CpuSet>() as libc::size_t,
178 | |                 &cpuset.cpu_set,
179 | |             )
    | |_____________^ can't call foreign function `sched_setaffinity` on OS `linux`

Is adding that a possibility? if it is, and you do have time, I'll gladly look into implementing this myself.

Closing comment (2023-05-13T16:29:31Z): Duplicate of #2749
Repository: rust-lang/miri

Issue #2205: Print out both accesses involved in a data race
Created: 2022-06-06T22:27:04Z
Currently Miri throws a UB on the access that ultimately causes a data race, which is always the later one. It is not clear where the other access involved in the data race is in the source file.
error: Undefined Behavior: Data race detected between Write on Thread(id = 0, name = "main") and Write on Thread(id = 1) at alloc1 (current vector clock = VClock([5]), conflicting timestamp = VClock([0, 8]))
  --> src/lib.rs:21:18
   |
21 |         unsafe { V = 2 }
   |                  ^^^^^ Data race detected between Write on Thread(id = 0, name = "main") and Write on Thread(id = 1) at alloc1 (current vector clock = VClock([5]), conflicting timestamp = VClock([0, 8]))
   |
   = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
   = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
           
   = note: inside `tests::data_race` at src/lib.rs:21:18

Both TSan and Go's race detector print out the line numbers of both accesses involved in the data race, we'd like to do the same.
It shouldn't be too hard to implement, we just need to augment VTimestamp with the current Span from MiriEvalContext::cur_span()

  
    
      miri/src/vector_clock.rs
    
    
         Line 45
      in
      aca3b3a
    
  
  
    

        
          
           pub type VTimestamp = u32;

Duplicate issue #2637: Stack traces on data races
Created: 2022-10-29T17:05:39Z
I am having a hard time debugging a problem that miri is reporting. It says Data race detected between Atomic RMW on thread 'thread-2' and Write on thread 'thread-3' at alloc3257278 and proceeds to give me a stack trace at an atomic increment location (thread-2 presumably). The problem is that this this variable is never written to outside of the atomic operations. Is there a way to get any information about the write operation on thread-2?

Closing comment (2022-10-30T09:30:34Z): Yeah I'd say this is a duplicate of #2205.
Repository: rust-lang/miri

Issue #1481: Improve memory leak identification
Created: 2020-07-17T00:22:08Z
Miri is able to determine if memory leaks occur. The output is similar to:
running 10 tests
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_1 ... ok
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_2 ... ok
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_3 ... ok
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_4 ... ok
test collections::bptree::iter::tests::test_bptree2_iter_leafiter_5 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_1 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_2 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_3 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_4 ... ok
test collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_5 ... ok

test result: ok. 10 passed; 0 failed; 0 ignored; 0 measured; 175 filtered out

The following memory was leaked:
alloc876074 (Rust heap, size: 120, align: 8) {
    0x00 │ 07 00 00 00 00 00 00 20 0a 00 00 00 00 00 00 00 │ ....... ........
    0x10 │ 0b 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 │ ................
    0x20 │ 0d 00 00 00 00 00 00 00 0e 00 00 00 00 00 00 00 │ ................
    0x30 │ 0f 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 │ ................
    0x40 │ 0a 00 00 00 00 00 00 00 0b 00 00 00 00 00 00 00 │ ................
    0x50 │ 0c 00 00 00 00 00 00 00 0d 00 00 00 00 00 00 00 │ ................
    0x60 │ 0e 00 00 00 00 00 00 00 0f 00 00 00 00 00 00 00 │ ................
    0x70 │ 10 00 00 00 00 00 00 00                         │ ........
}
... <many more leaks below>

The leaks are not associated to a specific test however. To aid leak isolation, it would be good if there was a way to see which test caused what leak.
Some ideas are potentially to have a test function associated with the leak line like:
alloc876074 (collections::bptree_legacy::iter::tests::test_bptree_iter_leafiter_4) (Rust heap, size: 120, align: 8) {

Another option is to have bisection, so that when warnings or errors are omitted that the warnings can be traced to a minimum set of tests that create those errors.
Thanks!

Duplicate issue #2813: Memory leaks do not show where the original allocation occurs
Created: 2023-03-12T06:41:54Z
Take the following code:
Box::into_raw(Box::new(5));
which produces the following output with cargo miri run:
The following memory was leaked: alloc1672 (Rust heap, size: 4, align: 4) {
    05 00 00 00                                     │ ....
}

The error message does not mention where the allocation of the memory that has been leaked occurs. A mention of what line the allocates the leaked memory or a backtrace of calls leading up to the allocation would make it significantly easier to figure out what needs to be done to fix the memory leak especially in more complex situations.

Closing comment (2023-03-12T16:44:22Z): Thanks for the report! However, I think this is a duplicate of #1481.
Repository: rust-lang/rfcs

Issue #628: Allow a minimum complete implementation to be specified for mutually recursive default methods
Created: 2015-01-21T01:37:09Z
Issue by huonw
Saturday Jul 13, 2013 at 08:41 GMT
For earlier discussion, see rust-lang/rust#7771
This issue was labelled with: A-attributes, A-diagnostics, A-lint, A-traits, B-RFC, I-wishlist in the Rust repository

It should be possible to tell the compiler that at least one of a given set of default methods is required to be implemented, e.g.
#[requires(one_of(foo, bar), one_of(baz, qux))]
trait A {
   fn foo(&self) { self.bar() }
   fn bar(&self) { self.foo() }

   fn baz(&self) { self.qux() }
   fn qux(&self) { self.baz() }
}

impl A for int { // ok
   fn foo(&self) {}
   fn bar(&self) {}

   fn baz(&self) {} 
}

impl A for uint { // "requires at least one of foo or bar"
   fn baz(&self) {}
}

impl A for float { // "requires at least one of baz or qux"
   fn foo(&self) {}
}
This allows e.g. Eq to write eq and ne in terms of each other, without allowing the infinitely recursive impl Eq for Foo {}.
It could even allow saying "either foo or both bar and baz", e.g. #[requires(one_of(foo, all_of(bar, baz)))], and would hopefully warn if a non-default method was listed.

Duplicate issue #1139: Allow traits to require implementors to implement at least one of a set of methods
Created: 2015-05-30T18:07:54Z
This could be used in std::cmp::PartialEq, for example, allowing implementors to implement either eq() or ne() and be provided with the other.

Closing comment (2015-05-30T18:12:31Z): Whoops, this is a duplicate of #628.
Repository: rust-lang/rfcs

Issue #959: Ability to refer to a path relative to the current scope in use declarations
Created: 2015-03-10T14:23:01Z
(Note that this is not about the ability to refer to the current module, which is already possible with use self::foo.)
Rust allows declaring modules, enums, and extern crates in most places where items can be declared, including block scopes inside functions.
One use of this is bringing an extern crate into scope inside a conditional branch:
fn show_message(message: &str) {
    if (inside_a_gui_context) {
        extern crate messagebox;
        // Import trait Messagebox
        use messagebox::Messagebox; // Doesn't work
        ...
    } else {
        println!("{}", message);
    }
}
The problem is that there is no way to refer to items declared this way in use declarations, as paths in use declarations are absolute.
It feels inconsistent being able to declare items like this, but not being able to refer to them in use declarations, and might surprise some users. It did surprise me.
While referring to the items inside can be done by using their full relative path (e.g. do_something_with(messagebox::foo)), there is no way to import traits, so the user has to move the module/crate up to a scope where it can be referred from in use declarations.
One way this could be resolved is to give users a way to refer to a relative path in use declarations.
Options include:

Using a keyword , e.g. use relative::messagebox::Messagebox, although I'm not sure reserving a new keyword this late in the alpha is desirable.
Using _, as in use _::messagebox::Messagebox, but I'm not sure if _ could otherwise refer to a valid path. It's also not as descriptive as a keyword, but still better than nothing.

The general ability to use relative paths in use declarations might also bring ergonomic benefits in other cases too.
Any thoughts on this issue?

Duplicate issue #1326: Allow importing from the current scope
Created: 2015-10-16T20:23:45Z
One of the big arguments in favor of RFC #390 (enum namespacing) was that it was easy to get the old behavior back using an import.  There is one case, however, where this is not possible: an enum defined in an unnameable scope.  I think the only place in current Rust where one can do this is inside a function.
mod a {
    fn b() {
        enum Foo { Bar }
        use Foo::Bar; // Tries to find to Foo in the crate scope (or as an external crate).
        use self::Foo::Bar; // Tries to find a::Foo.
    }
}
I haven't come up with a good syntax to propose for this operation, though.

Closing comment (2015-10-29T18:45:50Z): Duplicate of #959.
Repository: rust-lang/rfcs

Issue #1038: Parameterize types over numerics / type level integers
Created: 2015-04-06T17:52:56Z
This is a postponement issue tracking postponed RFCs in the general area of "functions generic over a constant" or "generic constants" and so forth.
Example use cases for items parameterized by a constant:

implement a trait for [T; N] for any N
small vector types (SmallVec<32>)

Example use cases for generic constants:

initializers like const FOO<T> = SomeType { value: None::<T> }; (const fn can also address this)

Here is a list of relevant RFCs:

#1062
#1520 -- generic const and static
#884

Duplicate issue #1179: Polymorphic array and byte string literls [T; N]/[T]
Created: 2015-06-27T01:46:09Z
Array literals ([1, 2, 3]) and byte string literals (b"abcd") have their length as a part of their type, because sometimes it's crucial to know the length at compile time.
This approach have a couple of downsides:

First, every time these literals interact with generics it is an invitation to code bloat, because literals with different lengths generate different instantiations of generics. (On the other hand, this code bloat has a chance to be counterbalanced by better const propagation in specialized code and further optimizations.)
Second, it leads to inconveniences like rust-lang/rust#21725, i.e. some extra traits have to be implemented for fixed arrays of different sizes in order for array literals to be usable in some contexts.

In practice, most of the time the length is needed only at runtime and can be erased from the type of an array or byte string literal.
So, my suggestion is to make array and byte string literals polymorphic, similarly to integer literals. They will have dynamically sized type by default and statically sized type when necessary (this part requires better specification and implementation experience).
(String literals could be made polymorphic too, when something like FixedString<N> is implementable.)
Currently array and byte string patterns behave somewhat similarly - they adapt to the type of the match discriminant and denote either sized or unsized arrays.

Closing comment (2015-07-07T20:50:21Z): I think this is effectively a dup of #1038
Repository: rust-lang/rfcs

Issue #831: cfg meta variables
Created: 2015-02-11T16:45:23Z
It's quite often that a cfg directive in an attribute becomes fairy complicated when support for more platforms are added. Even worse, a cfg block is then often duplicated among many locations to configure off different items.
The thread_local/mod.rs file is a good example of the amount of duplication.
It would be nice to have something like the following
#![cfg_shortcut(foo, any(super, long, clause))]

#[cfg(foo)] ...
#[cfg(not(foo))] ...
Here the clause any(super, long, clause) would be shortened to the identifier foo which could then be used elsewhere. In general it would just be nice to make these long cfg directives much shorter and less error prone to copy-paste.

Duplicate issue #1114: Allow defining new `cfg` values inside Rust
Created: 2015-05-11T18:30:06Z
Example:
#[cfg(feature = "nightly")] define_cfg!(nightly);
I've found that having #[cfg(feature = "nightly")] in multiple places has lead to easily including a typo that then leaves a certain item conditionally compiled when features="nightly", which happens to be never.

Closing comment (2015-05-12T21:00:08Z): I believe that this is a dupe of #831, so I'm going to close this in favor of that.
Repository: rust-lang/rfcs

Issue #493: Crates should allow private impl of external traits for external structs 
Created: 2014-11-30T01:59:11Z
Issue by alanfalloon
Thursday Apr 24, 2014 at 02:31 GMT
For earlier discussion, see rust-lang/rust#13721
This issue was labelled with:  in the Rust repository

As you know, you can't provide an impl for a trait if neither the type nor the trait are defined in the current crate, you get:
error: cannot provide an extension implementation where both trait and type are not defined in this crate

For public implementations, this makes perfect sense, there are issues with collisions between implementations and sheer surprise. However, for a private implementation of the trait, this is a real hindrance.
Consider the case of std::path::Path not implementing std::fmt::Show. The rationale for closing #13009 is perfectly valid: we don't want people treating paths as strings. However, by refusing to add an implementation of Show, you have made that decision for all programs everywhere. In my case, I had a large struct with numerous Path elements that I wanted to print for debugging, but #[deriving(Show)] won't work because Path has no Show impl, and now I'm stuck either implementing it tediously from scratch, or switching to str for my path names.
The perfect compromise would have been to allow my crate to define a private Show impl for Path. There is precedent for this in other languages, go allows interfaces to implemented anywhere, for example.

Duplicate issue #2251: Named impls
Created: 2017-12-19T15:14:38Z
As of right now all impls are anonymous and public. I propose named impls and named public impls:
impl X as Y for Z for a private impl
pub impl X as Y for Z for a public impl
This is similar to how traits currently work: you need to import them to use them.
With a non-pub impl, you can use it within your module. With a pub impl, you can use it outside your module. In any case, you need to explicitly import it with use. You can also import them from an external crate, but it follows the same rules - only available where you use them.
Later we could also add !pub impl Y for Z if we want crate-wide, anonymous impls. (Sadly, since they're already public by default, we can't have impl Y for Z and pub impl Y for Z, except maybe in Rust 2.0.)

Closing comment (2021-07-16T02:59:19Z): Dupe of #493 I think.
Repository: rust-lang/rfcs

Issue #2035: Trait objects for multiple traits
Created: 2017-06-17T20:40:16Z
Given arbitrary traits Foo and Bar, it'd be great to have Box<Foo + Bar> compile, but there are unresolved questions that need to be laid out explicitly. (Moved from rust-lang/rust#32220)

Duplicate issue #2748: dyn bounds
Created: 2019-08-22T11:22:06Z
*Note: Syntax feedback is welcomed.
Let's first look at the problem this feature attempts to solve.
For example, I got a type named Cat and a type named Lion both Lion and Cat implement the traits HasName and HasMeow.
I need to create a Vec of references to types that implement both HasName and HasMeow.
As far as I know (and I may be very wrong) this is how you would do that.
//lion is of type Lion , cat is of type Cat.
trait HasBothMeowAndName : HasMeow + HasName {};
impl HasBothMeowAndName for Cat{}
impl HasBothMeowAndName for Lion{}
let vector : Vec<&dyn HasBothMeowAndName> = vec![&lion,&cat];

dyn bounds is a syntax sugar feature attempting to make this ugly code more readable and easier to write.
Simply do
let vector : Vec<&dyn (HasName + HasMeow)> = vec![&lion,&cat];
The code will compile since both Lion and Cat implement the traits HasName and HasMeow.
Of course, you'll be able to use the functions of the traits on every element of the vector.
for entity in vector {
        entity.meow();
        entity.get_name();
}

*The dyn bounds feature isn't limited to the Vec struct.
*You can add more than two traits using the Add operator.
example:
dyn (Trait1 + Trait2 + Trait3 + Trait4)
Readable intuitive and useful.

Closing comment (2019-08-22T11:30:29Z): Is this the same as #2035?
Repository: rust-lang/rfcs

Issue #35: Clarify what needs an RFC
Created: 2014-04-05T09:03:41Z
In #33 (comment), @cmr said:

Also, I don't think this deserves an RFC. RFCs should be for language changes and changes to items marked #[stable], I think.

It wasn’t clear to me based on https://mail.mozilla.org/pipermail/rust-dev/2014-March/008973.html (see also #31) if #33 required an RFC or not. It generated more discussion that I would have expected, but that discussion could just as well have happened in the main issue tracker.

When you need to follow this process
You need to follow this process if you intend to make "substantial"
changes to the Rust distribution. What constitutes a "substantial"
change is evolving based on community norms, but may include the following.

Any semantic or syntactic change to the language that is not a bugfix.


This changes libraries, but not the language.


Changes to the interface between the compiler and libraries,
including lang items and intrinsics.


Nope.


Additions to std


Change, not addition.

Some changes do not require an RFC:

Rephrasing, reorganizing, refactoring, or otherwise "changing shape
does not change meaning".


Unsure about that one. Does MaybeOwned have the same "meaning" as ~str?


Additions that strictly improve objective, numerical quality
criteria (warning removal, speedup, better platform coverage, more
parallelism, trap more errors, etc.)


I could make up a micro-benchmark with a numerical result, but there are also drawbacks.


Additions only likely to be noticed by other developers-of-rust,
invisible to users-of-rust.


This will definitely be noticed by users.

Duplicate issue #1041: Decide what needs an RfC
Created: 2015-04-07T09:03:51Z
We should decide on a set of changes that should always need an RfC. I haven't come up with an exhaustive list which I'm happy with (so I'm filing an issue to discuss stuff as opposed to writing an RfC).

Closing comment (2015-04-08T00:00:36Z): +1 to everything that Niko said
On Apr 7, 2015 11:24 PM, "Niko Matsakis" notifications@github.com wrote:

So some thoughts:

This does seem like a dup of #35
#35 to me :)
I've definitely been wanting to clarify the rules here too. In
particular, I think we've been leaning towards too many RFCs lately.
It seems too heavyweight for every API addition to go through the RFC
process; RFCs ought to be reserved for deprecations and "major" or
cross-cutting additions. For other changes, a lighterweight process should
suffice (more thoughts on that to come).
Bug fixes which make silent changes to semantics ought to be
advertised but do not necessarily require an RFC.

To be clear, I'm referring here only to backwards compat changes -- after
all, there shouldn't be any other kind. (The whole "order of arguments"
thing seems to me to be a kind of one-time event, and doesn't fit into the
above criteria.)
—
Reply to this email directly or view it on GitHub
#1041 (comment).
Repository: rust-lang/rfcs

Issue #1362: Rust Needs The Ternary Conditional Operator (-?-:-)
Created: 2015-11-10T20:03:11Z
Hello,
It looks like Rust forgot to implement the ternary conditional operator
It's operator that looks like this: condition ? trueExpression : falseExpression
This important feature lets you do things like return value == 5 ? success : failure;
Without this Ternary Conditional Operator you must use if statements which make ugly duplicated code (leads to bugs)
I think it easy to add support for this in Rust

Duplicate issue #3053: The ternary conditional operator has been unintentionally omitted from the Rust programming language.
Created: 2021-01-07T11:24:52Z
Hello Rustics,
I am writing because an important feature (the ternary conditional operator) has been unintentionally omitted from the Rust programming Language.
The ternary conditional operator is elegant means of writing an expression, whose result depends on a subexpression within her. It is found in e.g. C, C++, Apple Swift, Digital Mars D and many other languages, so why not also Mozilla Rust?
It looks like this:
condition ? trueValue : falseValue
Here, if condition evaluates to be true, then trueValue is evaluated and become the result of this expression. Otherwise, falseValue is evaluated and become the result of this expression.
Thank you for your consideration

Closing comment (2021-01-07T12:19:51Z): duplicate of #1362
Repository: rust-lang/rust-playground

Issue #22: Consider offering a way to specify standard input
Created: 2016-07-15T02:56:09Z

Duplicate issue #610: Rust Playground doesn't wait for user input
Created: 2020-06-22T11:01:44Z
Hello Rust team,
I'm very new to Rust, and hope to learn more about the language in the coming weeks and months.
I was trying out some very basic code on the Rust Playground which unfortunately didn't work as expected. Could you please help?
This is a variation on "Programming a Guessing Game" from the Rust Book.
use std::io;

fn main() {
    println!("Hello, Rajesh!");
    
    println!("Please input a number:");
    
    let mut number = String::new();
    
    io::stdin()
        .read_line(&mut number)
        .expect("Failed to read line");
    
    println!("Number is {}", number);
    
}

Closing comment (2020-06-22T12:47:35Z): Duplicate of #22
Repository: rust-lang/rust-playground

Issue #169: Implied "main" function
Created: 2017-07-12T17:59:57Z
I think it would be great that if the code does not contain a top-level "main" function, implicitly the string "fn main() {" were added before the code, and the string "}" were added after the code, before passing the code to the compiler.
For example, if the file contained the lines:
let a = 12;
print("{}", a);
it would be compiled as it were:
fn main() {
let a = 12;
print("{}", a);
}
That would avoid some typing.

Duplicate issue #377: Automatically change from "Run" to "Build" when `fn main` is removed.
Created: 2018-08-08T15:27:28Z
Often I just want to build code, not run it. Sometimes having the main function there is a little annoying. I know I can add #![crate_type="lib"], but try typing that fast (on a German keyboard, for extra challenge)... it's quite a mouthful.
Do you think it would make sense to switch to lib mode when I just remove the main function? The check could be something simple, like testing for the regex fn +main.

Closing comment (2018-08-08T16:44:18Z): Duplicate of #169 or #201
Repository: rust-lang/rust-playground

Issue #131: Feature request: `cargo check`
Created: 2017-04-03T15:47:44Z
Now that cargo check is stable, i think it'd be useful to offer!

Duplicate issue #522: Feature request: Add a `Check` option
Created: 2019-07-30T21:56:06Z
It would be nice if there was a "Check" button to complement "Run", "Build", and "Test".
This would have been useful when minimizing the bug rust-lang/rust#63150.

Closing comment (2019-08-05T15:23:26Z): Duplicate of #131
Repository: rust-lang/rust-playground

Issue #955: "Run" doesn't run the program, no build result or output appears
Created: 2023-07-30T20:27:47Z
Just opening the playground in a blank profile and hitting "Run" leads to... basically nothing: the output pane appears on the right-hand side of the screen, but it just says "Execution" and "Standard error", without actually showing the output of the compiler or running the program.

Duplicate issue #1062: 504 error when executing on Playground
Created: 2024-05-30T13:03:32Z
Was trying to execute some simple code from a rust book and am met with an error from cloudfront:

Closing comment (2024-06-03T20:56:54Z): Duplicate of #955
Repository: rust-lang/rust-playground

Issue #910: Playground responds by 500 error almost everytime when I try to build code
Created: 2023-03-17T11:14:37Z
I running using this link: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021
Request and server response after pressing Build or Run button:
POST /execute HTTP/3
Host: play.rust-lang.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0
Accept: */*
Accept-Language: en,ru-RU;q=0.8,ru;q=0.5,en-US;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021
content-type: application/json
Content-Length: 160
Origin: https://play.rust-lang.org
Alt-Used: play.rust-lang.org
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

[{"channel":"stable","mode":"debug","edition":"2021","crateType":"lib","tests":false,"code":"fn main(){\n    println!(\"Hello world!\");\n}\n","backtrace":false}](https://play.rust-lang.org/execute)

HTTP/3 500 Internal Server Error
x-amz-cf-id: ynZgIJ8QM6iuMNh7iInB5GQgjxFTWIM8n9F3zaZXeiBtIDkf5hHfMg==
content-type: text/html
content-length: 170
alt-svc: h3=":443"; ma=86400
server: nginx
date: Fri, 17 Mar 2023 11:11:51 GMT
x-cache: Error from cloudfront
via: 1.1 d9a98758c9298742942e003275c97f92.cloudfront.net (CloudFront)
x-amz-cf-pop: OTP50-C1

<html>
<head><title>500 Internal Server Error</title></head>
<body>
<center><h1>500 Internal Server Error</h1></center>
<hr><center>nginx</center>
</body>
</html>

Duplicate issue #908: Allow captured identifiers in format strings
Created: 2023-03-17T07:23:34Z
Format strings can capture arguments simply by writing {ident} in the string, since 1.58.0 stable. (Announced in rust blog)
This works in Rust now:
// https://stackoverflow.com/a/70504075/9235421

fn main() {
    let msg = "here";
    let s = format!("Abc {msg}");  
    println!("Hi t{msg}");   // prints "Hi there"
    println!("{s}");         // prints "Abc here" 
}
But in Rust Playground it throws this error:

Response was not JSON: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data

Also, Rust Playground provides no sharable link to such a playground.

Closing comment (2023-03-17T11:48:07Z): It does, there's just a current operational issue. Duplicate of #910
Repository: rust-lang/rust-playground

Issue #884: Playground now deletes `gist` query parameter
Created: 2023-01-19T03:43:45Z
Suddenly, the playground both at https://play.rust-lang.org and https://play.integer32.com redirect a URL with a gist query parameter to a URL without that parameter, which makes it more difficult to shorten the URL and then test that the shortened URL works, because the shortened URL is destroyed in the process.

Duplicate issue #887: "Permalink to the playground" redirects to non-permalink url
Created: 2023-01-20T17:34:57Z
When I click on "Permalink to the playground" the browser URL first becomes one with &gist=... i.e. a permalink one, but then after a split second playground redirects me to the non-&gist=..., non-permanent URL.
This is very confusing, as the "usual" way to share code does not work anymore:

Write the code
Click "Permalink to the playground"
Copy the browser URL (<-- does not work anymore)

This has caused me (and others) to post links to playground like "https://play.rust-lang.org/?version=stable&mode=debug&edition=2021" which do not point to any particular code.

Closing comment (2023-01-20T18:20:08Z): Duplicate of #884
Repository: rust-lang/rust-playground

Issue #96: copy and paste does not work
Created: 2017-01-23T13:06:05Z
It seems like it is not possible to copy and/or paste text, neither via keyboard shortcuts or the context menu. (Firefox 50.1.0, Ubuntu)

Duplicate issue #227: Copy (Ctrl+C) doesn't work
Created: 2017-11-02T11:03:54Z
It never has for me (though I some other editor bugs have been fixed; play is a lot more usable than it was originally).
E.g. if I select some text and press Ctrl+C (or right-click, copy), my clipboard is filled with �.
Paste (with text from another source) does work. Copy+Paste does nothing (presumably bad clipboard contents ignored).
Using Firefox 55.0.3 on Fedora 25.

Closing comment (2017-11-02T12:31:04Z): Duplicate of #96