jiebi/CodeConvo huggingface dataset:
Code change:
self.super_terminator(terminator, location); match &terminator.kind { <del> TerminatorKind::Call { func, .. } => { </del> <ins> TerminatorKind::Call { func, args, .. } => { </ins> let ConstCx { tcx, body, param_env, .. } = *self.ccx; let caller = self.def_id().to_def_id();

Related discussion:
text: In particular, applies to all unstable const features. Fixing this bug here is not even that hard I think: somewhere around here there needs to be a check that the argument has type . Re: , AFAIK that one is also blocked on figuring out how the diagnostics should look like, and a further concern (though maybe not blocking) is .
I guess that might make this a non-issue, where it is proposed also would require as first argument.
For reference: , which was recently merged. The plan is to fix the behaviour of in the Rust 2021 edition. Given that this ICE is listed as a blocker for , does this mean that stabilizing that will have to wait for the next edition?
No, because breaking changes are allowed to be made to unstable features without moving to a new edition; that's kinda the whole idea. The 2021 edition will effectively just extend the same restriction to all invocations, const context or not.
I'd like to tackle this but I'm not very experienced with the CTFE code. I get that we need to check from the that we've matched on in this branch and we need to match on the enum, but: For the first question, I see and that we probably want to check that the type of the tuple and that there's variants of that are , but do we stop the iteration when we get one that is a type? Is the projection list always guaranteed to terminate in a variant of that has a ? And once we have an instance of , do we just check that there's any_ projection in the list that has a ?
you can use to get the type of the . Then you can test its to be .
Code change:
match eh_action { EHAction::None | EHAction::Cleanup(_) => return continue_unwind(exception_object, context), <del> EHAction::Catch(_) => return uw::_URC_HANDLER_FOUND, </del> <ins> EHAction::Catch(_) => { // EHABI requires the personality routine to update the // SP value in the barrier cache of the exception object. (*exception_object).private[5] = uw::_Unwind_GetGR(context, uw::UNWIND_SP_REG); return uw::_URC_HANDLER_FOUND; } </ins> EHAction::Terminate => return uw::_URC_FAILURE, } } else {

Related discussion:
text: When I tested 1.40.0-beta.5 on , never completed on . When I run that test on arm directly, I get: The same happens when I use official builds of Rust 1.40-beta and 1.41-nightly, so it's not just a problem with Fedora's build of rustc or LLVM. This test didn't exist before , but running 1.39 on the current test just fails even earlier, as expected, "entered unreachable code: catch_unwind should not have caught foreign exception." I tried compiling the C++ part with GCC 9.2.1 and Clang 9.0.0, both with the same result. That's using libstdc++ either way though, because we don't have LLVM's libc++ available. cc
cc
PS: while I initially saw this on Fedora rawhide, my followup testing has been on stable Fedora 31.
That is very strange. And this behavior only occurs on ARM? I'm tempted to say that this is a bug in GCC's unwinder (in libgcc). Can you try this C++-only code to see if it has the same issue? a.cpp b.cpp This should print the message once and then fail with an uncaught exception.
Yes, the other arches completed and passed that test. Needs for , but then it works:
I tried stable 1.39 again commenting out the call to , then gets stuck in the same "caught foreign exception in catch" loop on the C++ side. In fact, this happens on every compiler I tried back to 1.13, which is the earliest I could get working at all! So at least it's not a new problem. Maybe we're generating bad unwind data, or maybe my libgcc has a bug in handling foreign exceptions, I don't know...
I think this might be a bug in the way the personality routine in libstdc++ (libsupc++ actually) handles foreign exceptions on ARM. Can you try using libc++ instead of libstdc++? Just change the linker args for rustc from to .
Oh, I found that Fedora does have libc++ packaged, and . But when I tried to use it simply as you indicate, foreign exceptions don't seem to be caught at all, in either direction.
Code change:
match eh_action { EHAction::None | EHAction::Cleanup(_) => return continue_unwind(exception_object, context), <del> EHAction::Catch(_) => return uw::_URC_HANDLER_FOUND, </del> <ins> EHAction::Catch(_) => { // EHABI requires the personality routine to update the // SP value in the barrier cache of the exception object. (*exception_object).private[5] = uw::_Unwind_GetGR(context, uw::UNWIND_SP_REG); return uw::_URC_HANDLER_FOUND; } </ins> EHAction::Terminate => return uw::_URC_FAILURE, } } else {

Related discussion:
text: I see the binary still gets linked implicitly though, I think because adds it to std. I'll try to get a full build of rustc with just libc++ instead.
It's fine to link to , since that contains the libunwind implementation. The actual C++ personality functions are in libstd++/libc++abi. Can you post the test output with libc++?
Maybe this is obvious, but I have to compile the C++ part with clang++, not g++, or it gets "undefined reference to ". I wasn't sure whether to also use , but either way the C++ exception is not caught by Rust: So I commented out again to just try :
you may need to explicitly link libcxxabi depending on how libcxx was built. That should fix undefined reference error.
I did use -- do you mean more than that? If anyone else is interested in arm-linux, it would be great to get more hands on this, because that target is not a high priority for me. I will probably disable this test for arm in Fedora in the meantime.
I managed to reproduce this on Arch Linux with , so it's definitely not a Fedora-only issue.
no, that should be fine. Guess passing to the Clang (supported since 9.0.0) doesn't help either?
The link error was only when using g++ to compile That much was ok with clang++. I just tried adding to the clang command too, but got "argument unused during compilation".
I'm hitting this on Debian too. Running by itself does result in infinite-loop printing however the rust test suite is actually running . Directly running this however exits immediately, so I don't know why the test is hanging. I'll see if I can grab the environment from next time.
Ah nvmd, I just had to wrap the thing in single-quotes to reproduce the loop, the output of "pstree" is misleading.
Since this test is new in 1.40 I'll just for the time being in Debian.
Should be fixed by
Code change:
if let Some(path) = env::var_os("PATH") { new_path.extend(env::split_paths(&path)); } <ins> if sess.target.target.options.is_like_msvc { new_path.extend(msvc::host_dll_path()); } </ins> env::join_paths(new_path).unwrap() }

Related discussion:
text: On nightly (and beta I believe) the compiler will currently fail when cross compiling from x86_64 to x86 (after ensuring the standard library is in the right location) with the message: I believe this is a regression from and , which were backported, so I believe this is a stable regression. That being said I doubt anyone other than Cargo CI is doing this, so it may not be that big. I also believe that is working on a patch, but this should help track this issue.
I have been doing this with ring and ring-based projects for many months.
Code change:
llvm::LLVMRustInstallFatalErrorHandler(); <ins> fn llvm_arg_to_arg_name(full_arg: &str) -> &str { full_arg.trim().split(|c: char| { c == '=' || c.is_whitespace() }).next().unwrap_or("") } let user_specified_args: FxHashSet<_> = sess .opts .cg .llvm_args .iter() .map(|s| llvm_arg_to_arg_name(s)) .filter(|s| s.len() > 0) .collect(); </ins> { <del> let mut add = |arg: &str| { let s = CString::new(arg).unwrap(); llvm_args.push(s.as_ptr()); llvm_c_strs.push(s); </del> <ins> // This adds the given argument to LLVM. Unless `force` is true // user specified arguments are *not* overridden. let mut add = |arg: &str, force: bool| { if force || !user_specified_args.contains(llvm_arg_to_arg_name(arg)) { let s = CString::new(arg).unwrap(); llvm_args.push(s.as_ptr()); llvm_c_strs.push(s); } </ins> }; <del> add("rustc"); // fake program name if sess.time_llvm_passes() { add("-time-passes"); } if sess.print_llvm_passes() { add("-debug-pass=Structure"); } if sess.opts.debugging_opts.disable_instrumentation_preinliner { add("-disable-preinline"); } </del> <ins> add("rustc", true); // fake program name if sess.time_llvm_passes() { add("-time-passes", false); } if sess.print_llvm_passes() { add("-debug-pass=Structure", false); } </ins> if sess.opts.debugging_opts.generate_arange_section { <del> add("-generate-arange-section"); </del> <ins> add("-generate-arange-section", false); </ins> } if get_major_version() >= 8 { match sess.opts.debugging_opts.merge_functions

Related discussion:
text: It would be rather hard, however, to re-create the set of passes meaningfully, I suspect. Even the compiler delegates this to methods within LLVM, iirc.
I think using might work on stable.
So did that help,
Unfortunately not. Specifying this gives me:
Code change:
#![feature(iter_advance_by)] #![feature(slice_group_by)] #![feature(slice_partition_dedup)] <del> #![feature(vec_spare_capacity)] </del> #![feature(string_remove_matches)] #![feature(const_btree_new)] #![feature(const_default_impls)]

Related discussion:
text: The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- Initial implementation ()
FWIW, here is a full-featured API provided by an external crate:
I wonder how this API relates to . It would be great if there was some safe API that wrapped around the use of to access a 's spare capacity, then updated based on the s .
Maybe we should follow that example and generalize to return ?
has implemented that, albeit as a private function. Sounds like a good idea to me.
Since exists now I think is redundant.
That's not actually true due to pointer invalidation, see and
I think it would be better to have this feature sooner rather than later. I'm starting to notice instances where people are doing things that are probably or definitely UB because they want this functionality. So I think this API falls squarely into the standard library's mission to provide pre-built and correct implementations of things that are subtle or difficult to get right.   (originally posted on but per Ralf's comments there, it is probably better to have this method for the above use cases)
I agree. I've been using this in my code and found it to be very useful. Even though is more general, I've never had a need for it and I feel that is useful on its own. The API being stabilized is: merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
Code change:
#![feature(iter_advance_by)] #![feature(slice_group_by)] #![feature(slice_partition_dedup)] <del> #![feature(vec_spare_capacity)] </del> #![feature(string_remove_matches)] #![feature(const_btree_new)] #![feature(const_default_impls)]

Related discussion:
text: See for info about what commands tagged team members can give me.
while waiting for this feature to be stabilized, you should suggest that and use one of the convenience methods in:
:bell: This is now entering its final comment period, as per the . :bell:
Ralf mentioned this on , mostly rewording with my own opinion: I would prefer not to recommend that function, because even if you just want access to the spare region, under SB, these interfaces invalidate all pointers to the initialized region. I think that's too much of a footgun for codebases where people are already writing code that is rejected by Miri.
I wonder how many people do keep outstanding pointers to the initialized part while toying with the extra part 's implementation is already better than their 0-elems slices that get -ly converted into non-empty slices (and currently better than the stdlib one since it doesn't involve a 12-week delay for stable Rust). Anyhow, I've just released a new version () with a dedicated adapter: , for extra good measure.
To be clear, my concern is that the splitting interfaces are adding a landmine for the future. If I'm sending someone a PR I'll make sure it passes Miri at the time, but that's a hard condition to maintain. Especially because the two aforementioned codebases have dependencies that do int-ptr casts, an operation that Miri just doesn't understand at the moment, so it would be hard to advocate Miri in CI.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Code change:
<ins> // This test ensures that non-glob reexports don't get their attributes merge with // the reexported item whereas glob reexports do. // Regression test for <https://github.com/rust-lang/rust/issues/120487>. #![crate_name = "foo"] #![feature(doc_cfg)] // @has 'foo/index.html' // There are two items. // @count - '//*[@class="item-table"]//div[@class="item-name"]' 2 // Only one of them should have an attribute. // @count - '//*[@class="item-table"]//div[@class="item-name"]/*[@class="stab portability"]' 1 mod a { #[doc(cfg(not(feature = "a")))] #[cfg(not(feature = "a"))] pub struct Test1; } mod b { #[doc(cfg(not(feature = "a")))] #[cfg(not(feature = "a"))] pub struct Test2; } // @has 'foo/struct.Test1.html' // @count - '//*[@id="main-content"]/*[@class="item-info"]' 1 // @has - '//*[@id="main-content"]/*[@class="item-info"]' 'Available on non-crate feature a only.' pub use a::*; // @has 'foo/struct.Test2.html' // @count - '//*[@id="main-content"]/*[@class="item-info"]' 0 pub use b::Test2; </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: ! Instead, this happened: ! This is issue from First screenshot is of and second is of
Probably , it shouldn't have affected glob re-exports but maybe did (cc
Taking a look.
Same issue with a simple reexport:
That's what was meant to do, it wasn't meant to affect globs though.
I think there is another issue with how it's handled because nothing is listed on the item itself too: !
Ok so it's the expected output for a non-glob reexport. I wrote the fix for glob reexports, just need to add tests.
Latest nightly fixed the issue for but it didn't fix the issue for . In latest nightly below example doesn't work its last working version was also .
Noted. Sending a fix for it as well. :)
Fixed in
Code change:
pub mod dump_mir; pub mod early_otherwise_branch; pub mod elaborate_drops; <ins> pub mod function_item_references; </ins> pub mod generator; pub mod inline; pub mod instcombine;

Related discussion:
text: I tried this code: I expected to see this happen: The compilation succeed or guide me to (1) cast the to with . (2) borrow the : . But in this case the addresses printed are the same (what?). Instead, this happened*: Cryptic error message: There is : . It took me minutes before I found the workaround. But it still surprised me. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This creates a reference-to-function-pointer (type ), a double indirection. So it is not what you want. The error could possibly be improved, and the entire situation documented better, but I think getting an error is expected here. is not a function pointer, it is an anonymous ) (of size 0) indicating exactly the function it was created from. This type coerces to a function pointer, but cannot know what type to coerce it to. Printing function pointers is easy (well, if they are not polymorphic via ), but printing these function singleton ZSTs is hard.
It might also be worth linting against .
helps with the docs. But to close this issue, it would probably make sense to write a lint against where is the name of a function. That should be a matter of adding a new in which checks all expressions for being . That path we can pass to to get a . Now we just need to check if that refers to a function: pass the to . At least I hope that makes sense, someone stop me if this is all wrong. ;)
I'd like to help write this lint. The default level for the lint should be right? claim
Yeah, feels like a reasonable start.
Nominated for lang team discussion. It seems we usually ask for lints to be approved before shipping them, so let's get that process started. sorry for this, I wasn't aware of this part of the process. You can still go ahead and implement this if you want, but depending on what the lang team decides, we should submit this lint to clippy instead of the compiler itself. That might require minor adjustments, but the main work you are putting in and the testcases will be useful either way.
Code change:
pub mod dump_mir; pub mod early_otherwise_branch; pub mod elaborate_drops; <ins> pub mod function_item_references; </ins> pub mod generator; pub mod inline; pub mod instcombine;

Related discussion:
text: :)
As a point of interest, this would have been extremely useful in helping debug a segfault in The original code used , not .
Without the cast, this should not compile as transmute checks that the sizes match. I assume what you describe happens when using , i.e., not just remove the but also add a .
Unfortunately I never committed the broken code so I'm not sure what I had originally ... the closest thing is which doesn't compile. Sorry for the noise.
no worries. I already have the lint implemented, but in that case I'll wait until they discuss to write the tests
I think should compile. That's no noise, it seems very relevant. :)
poll T-lang Should we add a lint for taking a reference to a fn?
Team member has asked teams: T-lang, for consensus on: [x] [x] [x] [ ] [x] [ ]
I think I agree here, but to confirm: this isn't actually about linting the taking of a reference to a place of type, but just about using on the voldemort-typed function name constants, right?
Yes.
Discussed in a (rather small) meeting today: Those present felt a lint would make sense. If somebody wanted to go ahead and try to author one, please feel free and nominate the resulting PR for discussion.
all right, so if you want to open a PR, everything is settled for that. :)
Code change:
<ins> // Copyright 2018 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. // // compile-pass trait DictLike<'a> { type ItemsIterator: Iterator<Item=u8>; fn get(c: Self::ItemsIterator) { c.into_iter(); } } trait DictLike2<'a> { type ItemsIterator: Iterator<Item=u8>; fn items(&self) -> Self::ItemsIterator; fn get(&self)  { for _ in self.items() {} } } fn main() {} </ins>

Related discussion:
text: This appears to now be fixed.
Neat! Just needs a test if there isn't one already.
There's , but I'm not sure if that qualifies as testing this in particular. If not, I can add one.
Marking as E-needstest. I don't think the test I linked previously really fits this case.
Code change:
let res = binding.res(); self.check_reserved_macro_name(key.ident, res); self.set_binding_parent_module(binding, module); <del> let mut resolution = self.resolution(module, key).borrow_mut(); let old_binding = resolution.binding(); let mut t = Ok(()); if let Some(old_binding) = resolution.binding { if res == Res::Err && old_binding.res() != Res::Err { // Do not override real bindings with `Res::Err`s from error recovery. } else { </del> <ins> self.update_resolution(module, key, |this, resolution| { if let Some(old_binding) = resolution.binding { if res == Res::Err && old_binding.res() != Res::Err { // Do not override real bindings with `Res::Err`s from error recovery. return Ok(()); } </ins> match (old_binding.is_glob_import(), binding.is_glob_import()) { (true, true) => { if res != old_binding.res() { <del> resolution.binding = Some(self.ambiguity( </del> <ins> resolution.binding = Some(this.ambiguity( </ins> AmbiguityKind::GlobVsGlob, old_binding, binding, )); <del> } else if !old_binding.vis.is_at_least(binding.vis, self.tcx) { </del> <ins> } else if !old_binding.vis.is_at_least(binding.vis, this.tcx) { </ins> // We are glob-importing the same item but with greater visibility. resolution.binding = Some(binding); }

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. --With the latest nightly, the bytemuck crate fails to compile. This was compiling yesterday and the issue seems to be traits are not imported with super::*. Please see the issue in the bytemuck repository: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in searched nightlies: from nightly-2023-06-10 to nightly-2023-06-20 regressed nightly: nightly-2023-06-20 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: cc
<details<summaryi made a mistake making the example, see below </summaryThis should error in coherence, but instead errors with It looks like if there is a derive macro and trait with the same name, glob imports don't resolve the trait anymore. Note that works correctly </details
Maybe the reduced it incorrect? I found that it also throw an error for 1.70?
hm, maybe your change simply exposed an existing bug in more cases
I will check it later claim
ah no, I made a stupid mistake, i should have used :D, my example only got from the prelude which only contains the macro.
This is resolved, of course. Only tagging this with Nilstrieb's estimated priority for historical analysis later.
Now that this fix is merged, what time tonight should we expect a new nightly release?
0:00 according to a server somewhere. In practice, usually UTC 0:00. So it should be being cut sometime soon. Or 24 hours from now. Either one.