jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. struct A<'a> { func: &'a fn() -> Option<int> } impl<'a> A<'a> { fn call(&self) -> Option<int> { (*self.func)() } } fn foo() -> Option<int> { None } fn create() -> A<'static> { A { func: &foo, //~ ERROR borrowed value does not live long enough } } fn main() { let a = create(); a.call(); } </ins>

Related discussion:
text: Hello! The following dumps core when run on my machine (Ubuntu 12.04 LTS, rust-nightly downloaded today (18th Apr)). Ziad Hatahet confirmed the same on a slightly older version of rust.
There's an extra layer of indirection in that struct definition. A is a pointer to a pointer to a function. A statement like expands to . That's obviously creating a dangling pointer onto the stack which is why it ends up crashing. Adjusting the struct definition to should make things work as you want. There's also a bug in rustc for even letting that program compile. I'm not sure if it's already been run into and filed.
cc
This fixes it: But I didn't quite understand why.
it probably happens to reset that part of the stack to the right value.
p.s. This is still crashing in . Thanks
Nominating, something fishy is going on here.
Here's the simplest possible reduction I could make:
Is the compiler mixing up the function pointer with the actual function code? That is, is like So writing is like , i.e. a non- reference to the function pointer.
It's just creating an alloca, storing the function pointer into it, borrowing that, and returning the borrowed pointer. For example, on the program I get this LLVM IR: Basically, the borrow checker doesn't seem to be in on the joke that is referring to a local alloca.
That is the behaviour I would expect if my statement were true. (The double in the LLVM signature indicates what I was talking about: a function value is already the pointer, and so the name doesn't have lifetime.)
0 backcompat-lang
This is probably a mismatch between trans/mem-categorization. I expect mem-categorization is saying that the "reference to the fn" is a static item, but trans is translating it into an rvalue (and hence on the stack).
Code change:
<ins> error: range endpoint is out of range for `u8` --> $DIR/issue-109529.rs:4:14 | LL |     for _ in 0..256 as u8 {} |              ------^^^^^^ |              | |              help: use an inclusive range instead: `0..=255` | = note: `#[deny(overflowing_literals)]` on by default error: range endpoint is out of range for `u8` --> $DIR/issue-109529.rs:5:14 | LL |     for _ in 0..(256 as u8) {} |              ^^^^^^^^^^^^^^ | help: use an inclusive range instead | LL |     for _ in 0..=(255 as u8) {} |                 + ~~~ error: aborting due to 2 previous errors </ins>

Related discussion:
text: <!-- 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: I expected to see this happen: printing all numbers from 0 to 255 (inclusive) Instead, this happened: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The error is correct, 256 is indeed out of range for u8. You need to use .
You can run that code if you want, by allowing the lint: if you do you'll see that it will print nothing because the overflows and becomes , so it's which is empty. Examples like this where allowing the literal overflow would do something you don't want are exactly why this lint is deny-by-default
I've renamed this issue because the lint is correct. If there's anything to be done here, it would be to add a range-specific suggestion for this situation to help guide towards the correct code.
claim
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. mod foo { pub mod bar { pub mod baz { pub fn name() -> &'static str { module_path!() } } } } fn main() { assert_eq!(module_path!(), "issue-18859"); assert_eq!(foo::bar::baz::name(), "issue-18859::foo::bar::baz"); } </ins>

Related discussion:
text: I'm seeing things like this: Those used to be . My first guess is something changed in that handles crates different from modules?
Example code to reproduce the issue: And output:
Code change:
let (resolver, resolver_caches) = { let (krate, resolver, _) = &*abort_on_err(queries.expansion(), sess).peek(); let resolver_caches = resolver.borrow_mut().access(|resolver| { <del> collect_intra_doc_links::early_resolve_intra_doc_links(resolver, krate, externs) </del> <ins> collect_intra_doc_links::early_resolve_intra_doc_links( resolver, krate, externs, document_private, ) </ins> }); (resolver.clone(), resolver_caches) };

Related discussion:
text: The ICE appears with and , but not . Beta: <details<summary<strongBacktrace</strong</summary<p</p</details
this is a regression affecting the release that is being prepared today.
I'll take a look.
Code change:
if sess.opts.incremental.is_none() { return; } <ins> // This is going to be deleted in finalize_session_directory, so let's not create it if sess.has_errors_or_delayed_span_bugs() { return; } </ins> let query_cache_path = query_cache_path(sess); let dep_graph_path = dep_graph_path(sess);

Related discussion:
text: When compiling a testcase (e.g. the last snippet in on the current nightly, or any of the other examples in that issue on older compilers) with (or Cargo which does that by default), only the initial run will ICE. Subsequent runs will succeed without an ICE, in the absence of any regular errors. However, changing the relevant code (e.g. adding a space) can cause the query that calls to be recomputed and bring the ICE back. IIUC, incremental compilation stores diagnostics and replays them on subsequent runs, but that appears to not apply to ICEs. cc
It looks like without incremental we output artifacts (like ). Do we do this in case of errors too? It seems bad to produce artifacts after an ICE.
Nominating and proposing P-high (mostly because of potential annoyance factor). This should possibly also be labeled I-unsound under the assumption that under the general case of this issue, we might produce artifacts under subsequent runs that may produce UB traces. (However, it is probable that the user will notice the ICE at some other point in time and therefore discard the artifact.)
The current expected behavior of the compiler is to not save any incremental state if an error occurs. may slip through the cracks here.
In that case, it seems to me like it's a matter of recording the fact that we did a (which we already do, ) and then have this mean "there was an error" in terms of "should we save incremental state?".
Yep, the following check should also take into account: While we are at it, we could also add a similar check to and , as not to waste time producing values that will then be discarded anyway:
I'd like to start contributing to rustc and I wanted to ask if this is a good issue to start on (I have read the rustc book)
Sure, this is a decently good issue to start on and should be pretty interesting in terms of learning the infrastructure. If you get stuck, need help, and want to talk synchronously you can hop into https://rust- and we'll try to help out.
fixes this issue. It would still be good to have a test case for it.
I have started to write the code making this test possible, I'll open a PR shortly
Code change:
# ignore-cross-compile -- compiling C++ code does not work well when cross-compiling <del> # This test case makes sure that native libraries are linked with --whole-archive semantics # when the `-bundle,+whole-archive` modifiers are applied to them. </del> <ins> # This test case makes sure that native libraries are linked with appropriate semantics # when the `[+-]bundle,[+-]whole-archive` modifiers are applied to them. </ins> # # The test works by checking that the resulting executables produce the expected output, # part of which is emitted by otherwise unreferenced C code. If +whole-archive didn't work

Related discussion:
text: I am attempting to use the () syntax to control how my test binary is compiled. I have created a repro at In , I tell to link 2 static libraries, one with (+whole-archive) and one without (-whole-archive). I add a nonsense link argument so I can inspect the produced link line. I expect to see linked without whole archive. Instead, I see both and libraries linked with --whole-archive: This may be related to the default documented . When I use nightly and specify it works as expected: However, I cannot use the nightly toolchain, so I cannot use , and seems inappropriate for a final binary crate types like cdylib, staticlib, and executables anyway. Tested with 1.62.1 stable and 1.64 nightly. Possibly related issues: ,
This is a bug introduced in The backward compatibility condition should look like and not .
Could you submit a PR with this fix? (We can backport it to beta if it's done in time.)
Sure, I'll create a PR. I'm not sure what tests to include, however. I had been looking at that exact code and almost submitted a PR earlier, but I wasn't sure about the whole context of that code and all the compatibility needs.
You can try adding a test case with to . One with and , and another with and without any (the compatibility case).
Code change:
<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash // We should probably be able to infer the types here. However, this test is checking that we don't // get an ICE in this case. It may be modified later to not be an error. struct Foo<const NUM_BYTES: usize>(pub [u8; NUM_BYTES]); fn main() { let _ = Foo::<3>([1, 2, 3]); //~ ERROR type annotations needed } </ins>

Related discussion:
text: Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:
Code change:
else { // 10 is not constructed d(10, None) <del> } </del> <ins> }, </ins> ); <del> assert_eq!(get(), vec![3, 8, 7, 1, 2]); </del> <ins> assert_eq!(get(), vec![8, 7, 1, 3, 2]); </ins> } assert_eq!(get(), vec![0, 4, 6, 9, 5]);

Related discussion:
text: <!-- 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: I expected to see this happen: both compiles successfully Instead, this happened: fails to compile <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This may have something to do with , as there is something about let_chain drops here as well, but I don't for sure.
The same behaviour happens with an older compiler version. Here goes an example that compiles with . It is not up to me to decide if this behaviour is a blocker that will revert stabilization but in case of such event, I won't have enough free time to investigate and fix stuff in the near future.
Personally and despite the differences, I think that the version is "correct" and the nested version is surprisingly holding a reference of an owned structure () without an explicit bind.
drops the scrutinee after the statement.
cc who have been dealing with dropping stuff related to
Some things that might be helpful to know: The drop order changes for in also had borrow checker impact and made an example compile (see the PR's thread). I'm not a borrow checker expert, so I might be wrong, but this too might be fixed by drop order changes alone. In I'm studying drop order impacts of conditional statements, motivated by let else, but the test that PR adds also includes let chains. There I observed that let chains generally behave drop order wise like when there is a involved, and when it's a bool. I have only studied them regarding the body contained inside though. This table provides a summary of drop orders (disclaimer: it's outdated for let else):
I've locally amended of to add if let chains: And this is the output: Which actually runs counter to what I wrote above, because it predrops.
Code change:
else { // 10 is not constructed d(10, None) <del> } </del> <ins> }, </ins> ); <del> assert_eq!(get(), vec![3, 8, 7, 1, 2]); </del> <ins> assert_eq!(get(), vec![8, 7, 1, 3, 2]); </ins> } assert_eq!(get(), vec![0, 4, 6, 9, 5]);

Related discussion:
text: It seems that it depends on whether the in the chain is preceded by a or not: if you change the line with to , removing the , you get this: So that rule that I wrote above is not correct, but the underlying behaviour is more complicated. Hmmm...
Thanks
claim
pointed this out to me. It may be motivation to revert the stablization of let-chains on beta. Lets try to ensure we talk about this at Thursday triage label I-compiler-nominated
False alarm; pointed out to me that let-chains is already been marked unstable (on beta and nightly). label: -I-compiler-nominated
Code change:
// Fudge the receiver, so we can do new inference on it. let possible_rcvr_ty = possible_rcvr_ty.fold_with(&mut fudger); let method = self <del> .lookup_method( </del> <ins> .lookup_method_for_diagnostic( </ins> possible_rcvr_ty, segment, DUMMY_SP, call_expr, binding, <del> args, </del> ) .ok()?; // Unify the method signature with our incompatible arg, to

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --No user code, just trying to compile my project. The is <!-- 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. --:
Do you mind checking if this still ICEs on the most recent nightly?
I just did that now, and it looks like the issue is fixed on the latest nightly. (sorry should have tried that in first place!)
That's weird, because I can repro it (cross-compiling for from linux if it matters).
on the latest nightly?
yep: Also the version of winit from the report () is not the latest . I'm working on bisecting and reducing now
Wait, this actually ICEs on stable too and I didn't notice because rustc emitted a bunch of errors after the ICE (?!)
I've reduced it down to this (which is no longer macOS or aarch64 dependent): (The assignment to was of course something more reasonable in the original code, but now I can't seem to replace it without making the ICE go away) This failed to compile without ICE on 1.69: Regression in () searched nightlies: from nightly-2023-03-06 to nightly-2023-04-19 regressed nightly: nightly-2023-04-15 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-stable
Whoops, I seemed to have caused it I'll look into it!
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
Use verbose output. .TP fB--externfR fINAMEfR=fIPATHfR <del> Specify where an external rust library is located. </del> <ins> Specify where an external rust library is located. These should match fIexternfR declarations in the crate's source code. </ins> .TP fB--sysrootfR fIPATHfR Override the system root.

Related discussion:
text: Now, run the following You get the following error: A simple fix to this is to add at the beginning of , but that should not be unnecessary. Reproduces on nightly.
This is currently working as intended, the flags only work for specifying the immediate set of dependencies (those listed in ), and transitive dependencies must be found through paths. You can use to make sure that only transitive dependencies are found in those paths.
If that is the intended behavior, then please reopen this issue and mark it as a documentation problem. I cannot find where this distinction is explained. This section of would imply that: / are for use with native libraries only, not even mentioning the KIND. by itself will not actually search for crates in that directory. should be used for telling rust where to locate any crate and is an intuitive solution to errors like For reference, how do you thus indicate to rust where to locate a crate whose filename does not follow the pattern?
Yeah seems reasonable to leave open as a docs issue. Not sure exhaustive documentation should go into the message but the man page could certainly be up. That... can't actually be done I don't think. The only way the compiler looks for transitive dependencies is via where is the name of the crate.
Code change:
} } <del> // FIXME #31379: We can use methods from imported traits shadowed by non-import items if !binding.is_import() { for glob_binding in resolution.duplicate_globs.iter() { </del> <ins> // We can always use methods from the prelude traits for glob_binding in resolution.duplicate_globs.iter() { if glob_binding.defined_with(DefModifiers::PRELUDE) { </ins> module.shadowed_traits.borrow_mut().push(glob_binding); } }

Related discussion:
text: This compiles: but this doesn't: More generally, a shadowed trait's methods are usable if it is shadowed by an item, but not if it is shadowed by an import. Should methods from shadowed traits be usable?
cc
cc
Nominating for discussion at meeting. Clearly we should be consistent. I'm inclined to think that they should not be available, ever.
I'm of the same thoughts as A new "thing" with the same name as another outer "thing" should not inherit/infer/have/etc. any part of that outer thing. This is the case with , but—according to the presented opinion—it seems like it needs to be made consistent for trait bindings, right?
Is there a reason to shadow traits by name? What happens here is that it must find a method named among the imported traits, and that name has not been shadowed in any way, so it should be callable.
Well, that's the question, isn't it. Imagine then that did have an method -- would you prefer an ambiguity error here, or success?
Ambiguity error if was implemented for in the example (and this error is already implemented). Otherwise it doesn't interfere in any way.
Another more challenging example might be: should the methods from be available, given that it is shadowed by ?
My feeling is that the simplest rule is to say that methods come from "traits that are in scope", and shadowed traits are not in scope. This interpretation is shadowing of items from prelude and globs, which seem like they should clearly not count towards method resolution.
Discussed in meeting and settled on "methods from shadowed traits should be unavailable". triage: P-medium
We also want methods from to be unavailable (from your more challenging example), right?
Code change:
/// Test whether this TLS key has been `set` for the current thread. pub fn is_set(&'static self) -> bool { <del> unsafe { !self.inner.get().is_null() } </del> <ins> unsafe { !(self.inner)().get().is_null() } </ins> } }

Related discussion:
text: There is an  in the scoped TLS module, which allows for sharing of data that wasn't meant to be shared. An unqualified should only_ be used when provides some sort of threadsafe locking mechanism. and do not. This lets us, for example, clone an or between threads, in safe code: Here, we have clones from different threads being interleaved, which can cause unsafety if there's a race on the refcount. We could also cause unsafety with a , or any other non-Sync type. basically lets us share across threads even if . I put the sleeps in there because somehow without them the routines are run serially. Note that this is not a problem with the API. I'm using here because to exploit one needs to be able to share across threads, and has an additional bound which doesn't satisfy. Any usable API will probably have to make the assumption that . Nor is this a problem with , since it can be done with , too. Solution: Make it ... I think. I'm not familiar with this API, and I'm not sure why it's even in the first place.
cc
cc This seems concerning: this is designed to be thread-local, so that e.g. storing a works (which would be safe, if it were guaranteed to stay on one thread). However currently requires unconditionally, hence this overly-accepting impl.
Qualifying the impl with breaks scoped TLS for (see the associated PR); because becomes no longer and thus can't be stuffed inside a static.
I believe the only way statics can be safe is by requiring the absence of Sync. That may sound odd, but consider the following: - sending thread-local references across threads is memory unsafe even with no interior mutability a static with no interior mutability is almost entirely useless, certainly not a common case non- containers offering interior mutabilities are cheaper and preferred to ones, where they can be used The main issue is actually within the libstd TLS implementation: is a wrapper for getters so it's unaffected by it, but may live in a static or a global one, depending on whether the platform natively supports TLS or not. -ing a across threads is actually safe on the architectures which do not have native TLS support. However, allowing it on some architectures and not on others is undesirable. Should use an accessor model like ?