jiebi/CodeConvo huggingface dataset:
Code change:
let crate_types = if options.proc_macro_crate { vec![config::CrateType::ProcMacro] } else { <del> vec![config::CrateType::Dylib] </del> <ins> vec![config::CrateType::Rlib] </ins> }; let sessopts = config::Options {

Related discussion:
text: I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
Code change:
#![feature(ptr_offset_from)] #![feature(rustc_attrs)] #![feature(receiver_trait)] <del> #![feature(slice_from_raw_parts)] </del> #![feature(specialization)] #![feature(staged_api)] #![feature(std_internals)]

Related discussion:
text: In stable Rust, the only way to get a with an arbitrary length is through . Unfortunately, that function returns a , which makes it very dubious to use with arbitrary raw pointers.
Given that isn't defined for , what would be the value of being able to create ?
Why would you want one, but also, this seems like it depends on (yet to be decided?) details of the memory model. Is the fleeting moment where a reference exists in enough to invoke UB if the pointer is invalid?
If the reference is , then this is insta-UB for sure.
Is there anything holding [] from stabilizing? If not, I'd like to propose stabilization of these functions, as they are rather simple in concept and allow avoiding manifesting references during (slice) pointer manipulation. cc If I'm reading the various issue threads correctly, the validity invariant of pointer metadata is at max that of the metadata type. For slice pointers, the metadata is typed at . Context: I happen to currently be writing a library that cannot use the reference-based functions, because though the pointers are known to be non-null (and valid), it is not (and cannot be, with the current abstraction) known whether the pointer has unique or shared provenance (thus should use or to be sound). (Specifically, I'm now adding the bits required to handle erasing slice types. I can bifurcate my function into and , but so far, it works fine with one operating over , and it'd be sad to have the / split hanging around even after these functions stabilize (assuming they can)).
I don't recall any reason that cannot be stabilized.
The implementation PR used this feature requested as a tracking issue, but this wasn’t labelled properly. Doing so now.
By the way, would also cover this :)
Code change:
let mut _0: *const &u8; let mut _2: *const &u8; let mut _3: *const &u8; <ins> let mut _4: *const &u8; </ins> scope 1 (inlined generic_cast::<&u8, &u8>) { <del> debug x => _3; let mut _4: *const &u8; </del> <ins> debug x => _4; let mut _5: *const &u8; </ins> } bb0: { StorageLive(_2); StorageLive(_3); <del> _3 = _1; </del> StorageLive(_4); <del> _4 = _3; -         _2 = move _4 as *const &u8 (PtrToPtr); +         _2 = move _4; </del> <ins> _4 = _1; StorageLive(_5); _5 = _4; -         _3 = move _5 as *const &u8 (PtrToPtr); +         _3 = move _5; StorageDead(_5); </ins> StorageDead(_4); <del> StorageDead(_3); </del> <ins> -         _2 = move _3 as *const &u8 (PtrToPtr); +         _2 = move _3; </ins> _0 = _2; <ins> StorageDead(_3); </ins> StorageDead(_2); return; }

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: it compiles, since raw pointer casts should be allowed even for completely different types. Instead, this happened: it fails with: It looks like for some reason the compiler creates a lifetime obligation here. Strangely, it works with : .
I've looked into this. The issue is that typeck considers this cast to be a "coercion cast", because typeck thinks that you could replace the function body with just since the types are the same (it also triggers the lint (allow-by-default)). HIR typeck isn't aware of lifetimes. So then THIR building and MIR building build MIR that doesn't contain a cast but instead just assigns one to the other. The borrow checker is rightfully not pleased. The bug here is that the THIR does not contain an explicit cast anymore. I'm not sure how to best fix this, as the current logic for "is this a no-op cast (called coercion cast in the code)" is just "try to coerce the types in the same way that happens on coercion sites and if it works it has to be useless". Which is wrong in the presence of lifetimes. It seems like the current strategy works this way because it reuses some code in THIR building. Thinking about it a little more, this is very special to pointer casts, because only pointer casts are allowed to change the type like this. Maybe THIR building should just special case pointer casts to always be emitted?
Unfortunately due to this bug there is that should be turned into a raw pointer cast, but we cannot.
I think that's a different case, these are boxes and not raw pointers, and box-box casts are not allowed to do arbitrary changes (and are in fact coercion casts, so the doesn't actually do anything). The error there is correct and this needs a transmute.
I'd like to replace the transmutes by raw pointer casts, which IMO is much preferable, similar to But this bug is in the way of that.
Code change:
// extern-return-TwoU64s // foreign-fn-with-byval // issue-28676 <ins> // issue-62350-sysv-neg-reg-counts </ins> // struct-return // ignore-android

Related discussion:
text: We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).
Code change:
// extern-return-TwoU64s // foreign-fn-with-byval // issue-28676 <ins> // issue-62350-sysv-neg-reg-counts </ins> // struct-return // ignore-android

Related discussion:
text: Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway
Code change:
} // Determine if a node with the given attributes should be included in this configuation. <del> fn in_cfg(&mut self, attrs: &[ast::Attribute]) -> bool { </del> <ins> pub fn in_cfg(&mut self, attrs: &[ast::Attribute]) -> bool { </ins> attrs.iter().all(|attr| { // When not compiling with --test we should not compile the #[test] functions if !self.should_test && is_test_or_bench(attr) {

Related discussion:
text: This fails on stable because rust still parses the unstable module: It's possible to work around this by conditionally defining a macro and then having the macro define the module but that's a bit messy:
Or implement the module in another file. I think this is a fundamental limitation -- you can't skip forward over an item if you don't understand the syntax that the item is using. The only way we could solve it is with time travel, i.e., doing a point release of stable that knows the syntax but not what it means.
That's actually what I'm doing in my project (still the same problem). That is, I have the following in my : And a module,
Modules are parsed before 's are parsed, which has been an issue for as long as I can remember. Can someone find whether there is an issue tracking this?
Dupe of . cc ( expert!)
Though this'll be fixed by the above PR, the workaround for current stable is
Code change:
} // Determine if a node with the given attributes should be included in this configuation. <del> fn in_cfg(&mut self, attrs: &[ast::Attribute]) -> bool { </del> <ins> pub fn in_cfg(&mut self, attrs: &[ast::Attribute]) -> bool { </ins> attrs.iter().all(|attr| { // When not compiling with --test we should not compile the #[test] functions if !self.should_test && is_test_or_bench(attr) {

Related discussion:
text: The ABI string for is validated while being parsed, meaning one can get errors about in 'd off modules: (Compiled without .) This isn't necessarily wrong, but it is weird and somewhat annoying if one needs it. (It can be worked-around by hiding the block behind a macro: .)
Any ideas where we could move the check into? Any of borrowck, typeck, lints, privacy and resolve don’t exactly fit. I think trans thematically is the best place to have it, but it is a shame to have it error out so late for such an easy to detect and obvious error. I’m personally fine keeping it a parse error, IMO there’s no reason to have cfg blocks with code that does not compile.
NB. we can add a special pass if necessary (i.e. there's no reason for us to compromise by putting the error in trans). Yeah, of course. However, there are cases when the d code does compile, e.g. I encountered this in where I an ABI and had to use it in inside a module. Similarly, if we add ABIs in future, someone might have code designed to compile with Rust 1.0.0, but can take advantage of the newer ABI if it is available.
The block might be to gate nightly-only code. The code within the gated block is compiled only when a cargo feature is enabled; the code outside it works both on stable and nightly. I hit it myself; I'm playing with the SIMD work from pull request, but I want to keep the crate working on stable. .
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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

Related discussion:
text: Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.
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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

Related discussion:
text: Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.
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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

Related discussion:
text: Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)
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. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>

Related discussion:
text: It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.
Code change:
There’s just one line of this first example left: ```rust,ignore <del> println!("You guessed: {}", input); </del> <ins> println!("You guessed: {}", guess); </ins> } ``` This prints out the string we saved our input in. The `{}`s are a placeholder, <del> and so we pass it `input` as an argument. If we had multiple `{}`s, we would </del> <ins> and so we pass it `guess` as an argument. If we had multiple `{}`s, we would </ins> pass multiple arguments: ```rust

Related discussion:
text: Just found the Learn chapter has appeared in nightlies. While working through it the very first bit of code it gets me to run has a bug! It is note the last line we are printing which is there return value of read_line (appears to be number of bytes read) and not the actual string which is what the chapter text implies. Trivial fix... Took me a while to find, but I figured out where the book source is and will submit PR despite it being one word change so far ;).
I guess I made my pull request from that commit badly, but it's I guess this should be closed if that is accepted.
Code change:
<ins> // compile-flags: -Zsave-analysis </ins> // only-x86_64 <ins> // Also test for #72960 </ins> #![feature(asm)]

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. --code from ./src/test/ui/asm/issue- <!-- 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. --repo is @ <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Does this still happen with (now merged)
I can confirm its fixed. We can probably close this issue.
Closing this, thanks for taking a look!
Code change:
}; ``` <del> At the moment, `if` and `match`, as well as the looping constructs `for`, `while`, and `loop`, are forbidden inside a `const`, `static`, or `const fn`. </del> <ins> At the moment, `for` loops, `.await`, and the `Try` operator (`?`) are forbidden inside a `const`, `static`, or `const fn`. </ins> <del> This will be allowed at some point in the future, but the implementation is not yet complete. See the tracking issue for [conditionals] or [loops] in a const context for the current status. </del> <ins> This may be allowed at some point in the future, but the implementation is not yet complete. See the tracking issues for [`async`] and [`?`] in `const fn`, and (to support `for` loops in `const fn`) the tracking issues for [`impl const Trait for Ty`] and [`&mut T`] in `const fn`. </ins> <del> [conditionals]: https://github.com/rust-lang/rust/issues/49146 [loops]: https://github.com/rust-lang/rust/issues/52000 </del> <ins> [`async`]: https://github.com/rust-lang/rust/issues/69431 [`?`]: https://github.com/rust-lang/rust/issues/74935 [`impl const Trait for Ty`]: https://github.com/rust-lang/rust/issues/67792 [`&mut T`]: https://github.com/rust-lang/rust/issues/57349 </ins>

Related discussion:
text: I have to use some sort of loop construct within a const function. does explain that loop constructs are at the moment not supported, but as I was trying out first and the compiler rejected it, it would have been helpful if the explanation would hint me towards working. I think the doc just needs a small update and I think the file to update is I tried this code: <!-- 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 --
claim
, , and are also allowed, but is not.
if it helps, the reason is forbidden but the others work is that uses and traits in const functions are still unstable (search for 'for loops' on https://rust-).
yeah, that's understandable. The confusion on my side was simply that I didn't know I was allowed to user other control flow constructs until somebody mentioned it on IRC I actually could.
Code change:
<ins> error[E0597]: borrowed value does not live long enough --> $DIR/issue-52049.rs:16:10 | LL |     foo(&unpromotable(5u32)); |          ^^^^^^^^^^^^^^^^^^ - temporary value only lives until here |          | |          temporary value does not live long enough | = note: borrowed value must be valid for the static lifetime... error: aborting due to previous error For more information about this error, try `rustc --explain E0597`. </ins>

Related discussion:
text: suggests but still won't give us a lifetime. We should not emit the if the required lifetime is for the inside the source presume there's some code already checking for producing the "borrowed value must be valid for the static lifetime" message, find that code and bubble up the knowledge about that until you have it in the scope of the "consider using a binding to increase its lifetime" message 't emit the message in that case 'll already fail a bunch of tests, I don't think you need any new tests. Running should succeed and give you a bunch of changes to commit. Check that all changes make sense and just commit them.
can I take this on if nobody is working on this?
All yours!
closing it, as required code change has been merged.
Code change:
id, expr_ty.repr(self.tcx()), def); match def { <del> def::DefStruct(..) | def::DefVariant(..) => { </del> <ins> def::DefStruct(..) | def::DefVariant(..) | def::DefFn(..) | def::DefStaticMethod(..) => { </ins> Ok(self.cat_rvalue_node(id, span, expr_ty)) } <del> def::DefFn(..) | def::DefStaticMethod(..) | def::DefMod(_) | def::DefForeignMod(_) | def::DefStatic(_, false) | </del> <ins> def::DefMod(_) | def::DefForeignMod(_) | def::DefStatic(_, false) | </ins> def::DefUse(_) | def::DefTrait(_) | def::DefTy(_) | def::DefPrimTy(_) | def::DefTyParam(..) | def::DefTyParamBinder(..) | def::DefRegion(_) | def::DefLabel(_) | def::DefSelfTy(..) | def::DefMethod(..) => {

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).