Question: <ins> #![crate_type = "lib"] use super::A; //~ ERROR failed to resolve mod b { pub trait A {} pub trait B {} } /// [`A`] pub use b::*; </ins>

<!-- ICE: Rustc '--crate-type=lib --edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code'', 'thread 'rustc' panicked at 'internal error: entered unreachable code'' File: --code: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Regression in nightly-2023-02-12 found 8 bors merge commits in the specified range commit[0] 2023-02-10: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2023-02-10: Auto merge of - JulianKnodt:arrayconstval, r=cjgillot commit[2] 2023-02-11: Auto merge of - BoxyUwU:deferredprojectionequality, r=lcnr commit[3] 2023-02-11: Auto merge of - Dylan-DPC:rollup-fkl9swa, r=Dylan-DPC commit[4] 2023-02-11: Auto merge of - petrochenkov:doclink2, r=oli-obk commit[5] 2023-02-11: Auto merge of - the8472:rawvec-simpler-layout, r=thomcc commit[6] 2023-02-11: Auto merge of - matthiaskrgr:rollup-qnn380r, r=matthiaskrgr commit[7] 2023-02-11: Auto merge of - cjgillot:sroa-const, r=oli-obk ERROR: no CI builds available between and within last 167 days maybe ? ping


Question: <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. // ignore-pretty #![feature(unsafe_destructor)] use std::rc::Rc; use std::cell::Cell; struct Field { number: uint, state: Rc<Cell<uint>> } impl Field { fn new(number: uint, state: Rc<Cell<uint>>) -> Field { Field { number: number, state: state } } } #[unsafe_destructor] // because Field isn't Send impl Drop for Field { fn drop(&mut self) { println!("Dropping field {}", self.number); assert_eq!(self.state.get(), self.number); self.state.set(self.state.get()+1); } } struct NoDropImpl { _one: Field, _two: Field, _three: Field } struct HasDropImpl { _one: Field, _two: Field, _three: Field } #[unsafe_destructor] // because HasDropImpl isn't Send impl Drop for HasDropImpl { fn drop(&mut self) { println!("HasDropImpl.drop()"); assert_eq!(self._one.state.get(), 0); self._one.state.set(1); } } pub fn main() { let state = Rc::new(Cell::new(1)); let noImpl = NoDropImpl { _one: Field::new(1, state.clone()), _two: Field::new(2, state.clone()), _three: Field::new(3, state.clone()) }; drop(noImpl); assert_eq!(state.get(), 4); state.set(0); let hasImpl = HasDropImpl { _one: Field::new(1, state.clone()), _two: Field::new(2, state.clone()), _three: Field::new(3, state.clone()) }; drop(hasImpl); assert_eq!(state.get(), 4); } </ins>

When a type has no impl, it fields appear to be destructed in order of declaration. When a type does have a impl, that order is apparently reversed. This is very surprising. Example: Prints:
cc who first hit this bug.
The LLVM IR for the Drop glue for : The LLVM IR for the Drop glue for : I don't know why it's getting pointers to each field before calling , they're not used until the cleanup, and they're cleaned up in reverse order. It's also, for some reason, grabbing a pointer to the drop flag (), even though it doesn't use it.
Nominating. Seems pretty strange.
I have an approved commit for this already, it's just failing on the pretty-rpass test at the moment.
I'm OK with disabling the test. Going forward the pretty printer should mainly be used for compiler diagnostics and rustfmt should cover the reformatting use cases, IMO.


Question: /// # Example /// /// ```rust <ins> /// # #![allow(deprecated)] </ins> /// use url::decode; /// /// let url = decode("https://example.com/Rust%20(programming%20language)");

Users should use the cargo-ified Deprecate for a release or two then delete. cc
:+1:
Related:
I tried this: Hoping to deprecate the whole crate, but then building this program does not emit any warning: I expected a deprecation warning on the line. Is there another way to achieve this, or do I need to annotate individual items in the crate?
That should have worked, but you may need to remove the annotation above (they may be conflicting). I would also personally find it very helpful to annotate methods in particular what the path forward is (or just a general post about how to migrate).
Removing worked, thanks. Should this deprecation go through the RFC process, or can I assume that the team wants it since filed this issue? The documentation at explains how to use rust-url, and in particular the concept of relative v.s. non-relative URL schemes (e.g. vs ) which is a bit unusual. I believe this sufficient to make migration straightforward, but I’m obviously biased. Any feedback on the documentation is welcome. (I’ll make the deprecation message include the documentation’s URL, it seems more useful landing page than the github repo.)
Having an issue is sometimes considered a "todo item" rather than "everyone has approved this", you'll find both styles of issues on the issue tracker. We don't have much precedent for deprecating an in-tree crate, so we're forging new territory here. I'd like to start moving crates out of the repo, however, so I hope to have some more on this topic soon.


Question: <del> [target.thumbv7m-none-eabi] # uncomment this to make `cargo run` execute programs on QEMU </del> <ins> [target.thumbv6m-none-eabi] # FIXME: Should be Cortex-M0, but Qemu used by CI is too old </ins> runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" <del> [target.thumbv6m-none-eabi] # uncomment this to make `cargo run` execute programs on QEMU # For now, we use cortex-m3 instead of cortex-m0 which are not supported by QEMU </del> <ins> [target.thumbv7m-none-eabi] </ins> runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" <ins> [target.thumbv7em-none-eabi] runner = "qemu-system-arm -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv7em-none-eabihf] runner = "qemu-system-arm -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.base-none-eabi] # FIXME: Should be the Cortex-M23, bt Qemu does not currently support it runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.main-none-eabi] runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" [target.thumbv8m.main-none-eabihf] runner = "qemu-system-arm -cpu cortex-m33 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel" </ins> [target.'cfg(all(target_arch = "arm", target_os = "none"))'] # uncomment ONE of these three option to make `cargo run` start a GDB session # which option to pick depends on your system

I was working on making a run-make test today for a particular thumb target. While looking over how we do this elsewhere, I found this bit of code: From my local testing, it seems like having multiple lines of this form has the net effect of making the test a no-op that does not test anything: since a target matching line 13 will not match line 14, and vice versa, there are no targets that can run on this test. We should either revert the portion of the commit that did this: or figure out some other way to express the desired property here (or change the semantics of when multiple targets are provided to make it gather all such targets up in a set before doing the check for membership... but I am wary of making such a change since doing it right would require differentiating e.g. processor target vs OS target, for example...)
Also, It looks like there may be other instances of the same mistake elsewhere in the test suite, such as in:
Oof, not good. It shouldn't be hard to make rustbuild outright reject this scenario though.
Further effort on has led me to conclude that these lines do not work at all, at least not for cross-compilation.


Question: && key.ns == MacroNS && nonglob_binding.expansion != LocalExpnId::ROOT { <del> resolution.binding = Some(self.ambiguity( </del> <ins> resolution.binding = Some(this.ambiguity( </ins> AmbiguityKind::GlobVsExpanded, nonglob_binding, glob_binding,

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


Question: use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::infer::DefineOpaqueTypes; use rustc_infer::infer::InferOk; <ins> use rustc_infer::traits::query::NoSolution; </ins> use rustc_infer::traits::ObligationCause; use rustc_middle::middle::stability; use rustc_middle::ty::adjustment::{Adjust, Adjustment, AllowTwoPhase};

I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim


Question: debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {

with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13:


Question: debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {

0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure.


Question: debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {

22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code.


Question: debug!("(building reduced graph for external  crate) building type {}", final_ident); <ins> let modifiers = match new_parent.kind.get() { NormalModuleKind => modifiers, _ => modifiers & !DefModifiers::IMPORTABLE }; </ins> child_name_bindings.define_type(def, DUMMY_SP, modifiers); } DefStruct(def_id) => {

Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:


Question: Some(false) => { cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) })?; } <del> None => match cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) }) { // type unknown - try to unlink Err(err) if err.raw_os_error() == Some(libc::EISDIR) || err.raw_os_error() == Some(libc::EPERM) => { // if the file is a directory unlink fails with EISDIR on Linux and EPERM everyhwere else remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } result => { result?; } }, </del> <ins> None => { // POSIX specifies that calling unlink()/unlinkat(..., 0) on a directory can succeed // if the process has the appropriate privileges. This however can causing orphaned // directories requiring an fsck e.g. on Solaris and Illumos. So we try recursing // into it first instead of trying to unlink() it. remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } </ins> } }

The fix for CVE-2022- (, ) appears to have introduced a regression that can cause file system corruption on some UNIX systems. The new code will attempt to use in any case where it does not know what type of file a directory entry represents. Some systems do not provide that information along with the entry names returned while reading a directory, and even on systems which provide a type hint, that hint may be . In cases where we do not know the type of the entry, the code tries first to unlink it as if it were something other than a directory: The code assumes that on a directory will fail with , or on Linux with the non-standard , but this is not always the case. POSIX does suggests as a failure in some, but not all cases: (See in The Open Group Base Specifications Issue 7, 2018 edition) Implementations are not required to prohibit on directories, and indeed UFS file systems on present day illumos and presumably at least some Solaris systems allow of a directory if the user has sufficient privileges. Other platforms may as well. Unfortunately unlinking a directory on UFS causes a sort of file system corruption that requires an unmount and a trip through to correct. Any code that uses on UFS has since started causing that kind of corruption, which took a bit of work to track down. I think the fix is probably relatively simple, and has the benefit of not touching the code path where we believe we know what sort of entry we are removing: In short, we should try to first, rather than first, as that always fails in a safe way that we can detect. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc (as you're the one how wrote the new code)
Thanks for the ping claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Was this issue reported upstream? Filesystems corrupting themselves seem like a poor failure mode in any case, and in some ways is a violation of the sandboxing that the kernel ought to provide for the user-space applications.


Question: Some(false) => { cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) })?; } <del> None => match cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) }) { // type unknown - try to unlink Err(err) if err.raw_os_error() == Some(libc::EISDIR) || err.raw_os_error() == Some(libc::EPERM) => { // if the file is a directory unlink fails with EISDIR on Linux and EPERM everyhwere else remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } result => { result?; } }, </del> <ins> None => { // POSIX specifies that calling unlink()/unlinkat(..., 0) on a directory can succeed // if the process has the appropriate privileges. This however can causing orphaned // directories requiring an fsck e.g. on Solaris and Illumos. So we try recursing // into it first instead of trying to unlink() it. remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } </ins> } }

It was reported upstream, and we're working on a fix -- but that fix will obviously only be in new versions of the operating system. To expand further on the corruption: the file system becomes inconsistent and requires repair, and the damage such as it is can only be caused by privileged users; i.e., by root or a user with root equivalent privileges. I am not yet aware of a way that it would cause actual data loss, just an interruption to service, but anything is possible. Allowing the linking and unlinking of directories is a regrettable, but seemingly intentional feature we are saddled with through our UNIX heritage. I'm working to disable and eventually remove the feature in the OS -- although we strongly value backwards compatibility, in this case I can't really see a legitimate use case or find a consumer that would be broken by doing so, but we won't know for sure until we try. While this specific case is unfortunate, and we can and will work on our end to try to mitigate the impact, the fact remains that POSIX explicitly documents and allows for implementations where on a directory does not return . For the code to be completely correct on all POSIX systems, it cannot make that assumption. In addition, working around the issue in new versions of the OS doesn't fix existing deployments out there already. Enterprise customers are often reluctant to promptly update their operating system, even though they may update software built and deployed on it -- software that may be written in Rust. I myself hit this issue by upgrading only the Rust compiler to a new stable version, and trying to build and use Rust-based software we have to build UFS ramdisks on illumos. We aim to fix the OS for the future, but the critical regression in Rust needs to be fixed as well for the present. We appreciate everybody who has looked at this so far -- please let me know how I can help expedite the process!
Thanks again for the report. The linked PR should fix the issue. Apparently only and guarantee that trying to a directory fails. , and allow it, at least in theory. After looking around a bit I found that it is even explicitly documented for and . So it is not a bug but a feature there... After changing that in you might want to adapt the man page as well.


Question: Some(false) => { cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) })?; } <del> None => match cvt(unsafe { unlinkat(fd, child.name_cstr().as_ptr(), 0) }) { // type unknown - try to unlink Err(err) if err.raw_os_error() == Some(libc::EISDIR) || err.raw_os_error() == Some(libc::EPERM) => { // if the file is a directory unlink fails with EISDIR on Linux and EPERM everyhwere else remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } result => { result?; } }, </del> <ins> None => { // POSIX specifies that calling unlink()/unlinkat(..., 0) on a directory can succeed // if the process has the appropriate privileges. This however can causing orphaned // directories requiring an fsck e.g. on Solaris and Illumos. So we try recursing // into it first instead of trying to unlink() it. remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } </ins> } }

We can try to avoid this case by default, as is switching to try unknown as a directory first, but you should note that this is still going to be racy. If there's an unprivileged adversary like the CVE supposes, then they can try to race changes between "try (and fail) as a directory" to "unlink as a file", to make it unlink a directory after all and induce corruption. IOW, it sounds like it's not safe for a privileged process to unlink paths at all if they may be changed by lesser privileges .
It should not really cause corruption according to the , just orphaned directories: Of course this can lead to resource exhaustion since the disk space and the inodes cannot be reclaimed until the next .
And that user is only root or otherwise root-like? i.e. it's not just talking about regular access privileges?
For Illumos the process must have root privileges or needs to be in the process privilege set (). Solaris has at some point abolished this privilege and apparently does not allow unlinking directories anymore ().


Question: <del> // check-pass // From https://github.com/rust-lang/rust/issues/72476 trait A { type Projection; } impl A for () { type Projection = bool; } struct Next<T: A>(T::Projection); fn f(item: Next<()>) { match item { Next(true) => {} Next(false) => {} } } fn main() {} </del>

<!-- 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. --When compiling on an Apple M1 processor: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can also reproduce this when compiling on an Intel Macbook
I've encountered the same error on a different platform (x8664) when compiling . The project doesn't use cargo so repro is nontrivial, but from I can see that the ICE started occurring at which is a rollup of . <details<summary<strongBacktrace</strong</summary<p</p</details
Also seems to be hitting starlark-rust, , as per
Somewhat minimized standalone testcase: Builds on stable, fails on nightly. cc
Thanks for the minimization! Seems like we've hit again, but through a different code path. I'm investigating.
I think might be another duplicate of this, triggered when compiling the crate.


Question: | help: change the delimiters to curly braces | <del> LL | y!{ LL | Ϥ} | </del> <ins> LL | y! { /* items */ } |    ^^^^^^^^^^^^^^^ </ins> help: add a semicolon | LL | Ϥ,;

I'm seeing an internal compiler error on the following input (found by ): My compiler version is: I also observe the error on , but not on .


Question: error!("This is an error log") warn!("This is a warn log") info!("this is an info log") <del> debug!("This is a dubug log") </del> <ins> debug!("This is a debug log") </ins> } ```

The logging section of the 0.6 docs ( ) doesn't specify how you log messages. This link is broken: It is not broken in the 0.5 docs, but I believe the API has changed.


Question: // rustc internal (active, staged_api, "1.0.0", None), <del> // Allows using items which are missing stability attributes // rustc internal (active, unmarked_api, "1.0.0", None), </del> // Allows using #![no_core] (active, no_core, "1.3.0", Some(29639)),

According to and in , this feature-gate should not be used. It appears that earlier error checking in the compiler prevents it from ever mattering anyway.


Question: AssocTypeItem(t, b) => ItemEnum::AssocType { generics: t.generics.into_tcx(tcx), bounds: b.into_iter().map(|x| x.into_tcx(tcx)).collect(), <del> default: t.item_type.map(|ty| ty.into_tcx(tcx)), </del> <ins> default: Some(t.item_type.unwrap_or(t.type_).into_tcx(tcx)), </ins> }, // `convert_item` early returns `None` for striped items and keywords. StrippedItem(_) | KeywordItem(_) => unreachable!(),

Run with this in : and inspect . There is an item for the of the blanket impl  and it's default value is . There is an item but the default value is missing. It looks like this: When using instead of the information about the default value is present. It looks like this: This change, which in practice is a regression, is caused by But we can't revert it of course because that will result in ICEs which is even worse. So we need some kind of follow-up fix. labels +A-rustdoc-json +T-rustdoc +C-bug +requires-nightly
It seems like you already suggested a fix. Want to open a PR for it?
Yep I will do that as soon as I get time. Probably today.
It's not in a hurry. Don't hesitate to ask if you need help.


Question: <ins> use rustc_errors::Applicability; use rustc_hir::def_id::DefId; use rustc_middle::mir::visit::Visitor; use rustc_middle::mir::*; use rustc_middle::ty::{ self, subst::{GenericArgKind, Subst, SubstsRef}, PredicateAtom, Ty, TyCtxt, TyS, }; use rustc_session::lint::builtin::FUNCTION_ITEM_REFERENCES; use rustc_span::{symbol::sym, Span}; use rustc_target::spec::abi::Abi; use crate::transform::MirPass; pub struct FunctionItemReferences; impl<'tcx> MirPass<'tcx> for FunctionItemReferences { fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { let mut checker = FunctionItemRefChecker { tcx, body }; checker.visit_body(&body); } } struct FunctionItemRefChecker<'a, 'tcx> { tcx: TyCtxt<'tcx>, body: &'a Body<'tcx>, } impl<'a, 'tcx> Visitor<'tcx> for FunctionItemRefChecker<'a, 'tcx> { /// Emits a lint for function reference arguments bound by `fmt::Pointer` or passed to /// `transmute`. This only handles arguments in calls outside macro expansions to avoid double /// counting function references formatted as pointers by macros. fn visit_terminator(&mut self, terminator: &Terminator<'tcx>, location: Location) { if let TerminatorKind::Call { func, args, destination: _, cleanup: _, from_hir_call: _, fn_span: _, } = &terminator.kind { let source_info = *self.body.source_info(location); // Only handle function calls outside macros if !source_info.span.from_expansion() { let func_ty = func.ty(self.body, self.tcx); if let ty::FnDef(def_id, substs_ref) = *func_ty.kind() { // Handle calls to `transmute` if self.tcx.is_diagnostic_item(sym::transmute, def_id) { let arg_ty = args[0].ty(self.body, self.tcx); for generic_inner_ty in arg_ty.walk() { if let GenericArgKind::Type(inner_ty) = generic_inner_ty.unpack() { if let Some(fn_id) = FunctionItemRefChecker::is_fn_ref(inner_ty) { let ident = self.tcx.item_name(fn_id).to_ident_string(); let span = self.nth_arg_span(&args, 0); self.emit_lint(ident, fn_id, source_info, span); } } } } else { self.check_bound_args(def_id, substs_ref, &args, source_info); } } } } self.super_terminator(terminator, location); } /// Emits a lint for function references formatted with `fmt::Pointer::fmt` by macros. These /// cases are handled as operands instead of call terminators to avoid any dependence on /// unstable, internal formatting details like whether `fmt` is called directly or not. fn visit_operand(&mut self, operand: &Operand<'tcx>, location: Location) { let source_info = *self.body.source_info(location); if source_info.span.from_expansion() { let op_ty = operand.ty(self.body, self.tcx); if let ty::FnDef(def_id, substs_ref) = *op_ty.kind() { if self.tcx.is_diagnostic_item(sym::pointer_trait_fmt, def_id) { let param_ty = substs_ref.type_at(0); if let Some(fn_id) = FunctionItemRefChecker::is_fn_ref(param_ty) { // The operand's ctxt wouldn't display the lint since it's inside a macro so // we have to use the callsite's ctxt. let callsite_ctxt = source_info.span.source_callsite().ctxt(); let span = source_info.span.with_ctxt(callsite_ctxt); let ident = self.tcx.item_name(fn_id).to_ident_string(); self.emit_lint(ident, fn_id, source_info, span); } } } } self.super_operand(operand, location); } } impl<'a, 'tcx> FunctionItemRefChecker<'a, 'tcx> { /// Emits a lint for function reference arguments bound by `fmt::Pointer` in calls to the /// function defined by `def_id` with the substitutions `substs_ref`. fn check_bound_args( &self, def_id: DefId, substs_ref: SubstsRef<'tcx>, args: &Vec<Operand<'tcx>>, source_info: SourceInfo, ) { let param_env = self.tcx.param_env(def_id); let bounds = param_env.caller_bounds(); for bound in bounds { if let Some(bound_ty) = self.is_pointer_trait(&bound.skip_binders()) { // Get the argument types as they appear in the function signature. let arg_defs = self.tcx.fn_sig(def_id).skip_binder().inputs(); for (arg_num, arg_def) in arg_defs.iter().enumerate() { // For all types reachable from the argument type in the fn sig for generic_inner_ty in arg_def.walk() { if let GenericArgKind::Type(inner_ty) = generic_inner_ty.unpack() { // If the inner type matches the type bound by `Pointer` if TyS::same_type(inner_ty, bound_ty) { // Do a substitution using the parameters from the callsite let subst_ty = inner_ty.subst(self.tcx, substs_ref); if let Some(fn_id) = FunctionItemRefChecker::is_fn_ref(subst_ty) { let ident = self.tcx.item_name(fn_id).to_ident_string(); let span = self.nth_arg_span(args, arg_num); self.emit_lint(ident, fn_id, source_info, span); } } } } } } } } /// If the given predicate is the trait `fmt::Pointer`, returns the bound parameter type. fn is_pointer_trait(&self, bound: &PredicateAtom<'tcx>) -> Option<Ty<'tcx>> { if let ty::PredicateAtom::Trait(predicate, _) = bound { if self.tcx.is_diagnostic_item(sym::pointer_trait, predicate.def_id()) { Some(predicate.trait_ref.self_ty()) } else { None } } else { None } } /// If a type is a reference or raw pointer to the anonymous type of a function definition, /// returns that function's `DefId`. fn is_fn_ref(ty: Ty<'tcx>) -> Option<DefId> { let referent_ty = match ty.kind() { ty::Ref(_, referent_ty, _) => Some(referent_ty), ty::RawPtr(ty_and_mut) => Some(&ty_and_mut.ty), _ => None, }; referent_ty .map( |ref_ty| { if let ty::FnDef(def_id, _) = *ref_ty.kind() { Some(def_id) } else { None } }, ) .unwrap_or(None) } fn nth_arg_span(&self, args: &Vec<Operand<'tcx>>, n: usize) -> Span { match &args[n] { Operand::Copy(place) | Operand::Move(place) => { self.body.local_decls[place.local].source_info.span } Operand::Constant(constant) => constant.span, } } fn emit_lint(&self, ident: String, fn_id: DefId, source_info: SourceInfo, span: Span) { let lint_root = self.body.source_scopes[source_info.scope] .local_data .as_ref() .assert_crate_local() .lint_root; let fn_sig = self.tcx.fn_sig(fn_id); let unsafety = fn_sig.unsafety().prefix_str(); let abi = match fn_sig.abi() { Abi::Rust => String::from(""), other_abi => { let mut s = String::from("extern ""); s.push_str(other_abi.name()); s.push_str("" "); s } }; let num_args = fn_sig.inputs().map_bound(|inputs| inputs.len()).skip_binder(); let variadic = if fn_sig.c_variadic() { ", ..." } else { "" }; let ret = if fn_sig.output().skip_binder().is_unit() { "" } else { " -> _" }; self.tcx.struct_span_lint_hir(FUNCTION_ITEM_REFERENCES, lint_root, span, |lint| { lint.build("taking a reference to a function item does not give a function pointer") .span_suggestion( span, &format!("cast `{}` to obtain a function pointer", ident), format!( "{} as {}{}fn({}{}){}", ident, unsafety, abi, vec!["_"; num_args].join(", "), variadic, ret, ), Applicability::Unspecified, ) .emit(); }); } } </ins>

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.


Question: <ins> use rustc_errors::Applicability; use rustc_hir::def_id::DefId; use rustc_middle::mir::visit::Visitor; use rustc_middle::mir::*; use rustc_middle::ty::{ self, subst::{GenericArgKind, Subst, SubstsRef}, PredicateAtom, Ty, TyCtxt, TyS, }; use rustc_session::lint::builtin::FUNCTION_ITEM_REFERENCES; use rustc_span::{symbol::sym, Span}; use rustc_target::spec::abi::Abi; use crate::transform::MirPass; pub struct FunctionItemReferences; impl<'tcx> MirPass<'tcx> for FunctionItemReferences { fn run_pass(&self, tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { let mut checker = FunctionItemRefChecker { tcx, body }; checker.visit_body(&body); } } struct FunctionItemRefChecker<'a, 'tcx> { tcx: TyCtxt<'tcx>, body: &'a Body<'tcx>, } impl<'a, 'tcx> Visitor<'tcx> for FunctionItemRefChecker<'a, 'tcx> { /// Emits a lint for function reference arguments bound by `fmt::Pointer` or passed to /// `transmute`. This only handles arguments in calls outside macro expansions to avoid double /// counting function references formatted as pointers by macros. fn visit_terminator(&mut self, terminator: &Terminator<'tcx>, location: Location) { if let TerminatorKind::Call { func, args, destination: _, cleanup: _, from_hir_call: _, fn_span: _, } = &terminator.kind { let source_info = *self.body.source_info(location); // Only handle function calls outside macros if !source_info.span.from_expansion() { let func_ty = func.ty(self.body, self.tcx); if let ty::FnDef(def_id, substs_ref) = *func_ty.kind() { // Handle calls to `transmute` if self.tcx.is_diagnostic_item(sym::transmute, def_id) { let arg_ty = args[0].ty(self.body, self.tcx); for generic_inner_ty in arg_ty.walk() { if let GenericArgKind::Type(inner_ty) = generic_inner_ty.unpack() { if let Some(fn_id) = FunctionItemRefChecker::is_fn_ref(inner_ty) { let ident = self.tcx.item_name(fn_id).to_ident_string(); let span = self.nth_arg_span(&args, 0); self.emit_lint(ident, fn_id, source_info, span); } } } } else { self.check_bound_args(def_id, substs_ref, &args, source_info); } } } } self.super_terminator(terminator, location); } /// Emits a lint for function references formatted with `fmt::Pointer::fmt` by macros. These /// cases are handled as operands instead of call terminators to avoid any dependence on /// unstable, internal formatting details like whether `fmt` is called directly or not. fn visit_operand(&mut self, operand: &Operand<'tcx>, location: Location) { let source_info = *self.body.source_info(location); if source_info.span.from_expansion() { let op_ty = operand.ty(self.body, self.tcx); if let ty::FnDef(def_id, substs_ref) = *op_ty.kind() { if self.tcx.is_diagnostic_item(sym::pointer_trait_fmt, def_id) { let param_ty = substs_ref.type_at(0); if let Some(fn_id) = FunctionItemRefChecker::is_fn_ref(param_ty) { // The operand's ctxt wouldn't display the lint since it's inside a macro so // we have to use the callsite's ctxt. let callsite_ctxt = source_info.span.source_callsite().ctxt(); let span = source_info.span.with_ctxt(callsite_ctxt); let ident = self.tcx.item_name(fn_id).to_ident_string(); self.emit_lint(ident, fn_id, source_info, span); } } } } self.super_operand(operand, location); } } impl<'a, 'tcx> FunctionItemRefChecker<'a, 'tcx> { /// Emits a lint for function reference arguments bound by `fmt::Pointer` in calls to the /// function defined by `def_id` with the substitutions `substs_ref`. fn check_bound_args( &self, def_id: DefId, substs_ref: SubstsRef<'tcx>, args: &Vec<Operand<'tcx>>, source_info: SourceInfo, ) { let param_env = self.tcx.param_env(def_id); let bounds = param_env.caller_bounds(); for bound in bounds { if let Some(bound_ty) = self.is_pointer_trait(&bound.skip_binders()) { // Get the argument types as they appear in the function signature. let arg_defs = self.tcx.fn_sig(def_id).skip_binder().inputs(); for (arg_num, arg_def) in arg_defs.iter().enumerate() { // For all types reachable from the argument type in the fn sig for generic_inner_ty in arg_def.walk() { if let GenericArgKind::Type(inner_ty) = generic_inner_ty.unpack() { // If the inner type matches the type bound by `Pointer` if TyS::same_type(inner_ty, bound_ty) { // Do a substitution using the parameters from the callsite let subst_ty = inner_ty.subst(self.tcx, substs_ref); if let Some(fn_id) = FunctionItemRefChecker::is_fn_ref(subst_ty) { let ident = self.tcx.item_name(fn_id).to_ident_string(); let span = self.nth_arg_span(args, arg_num); self.emit_lint(ident, fn_id, source_info, span); } } } } } } } } /// If the given predicate is the trait `fmt::Pointer`, returns the bound parameter type. fn is_pointer_trait(&self, bound: &PredicateAtom<'tcx>) -> Option<Ty<'tcx>> { if let ty::PredicateAtom::Trait(predicate, _) = bound { if self.tcx.is_diagnostic_item(sym::pointer_trait, predicate.def_id()) { Some(predicate.trait_ref.self_ty()) } else { None } } else { None } } /// If a type is a reference or raw pointer to the anonymous type of a function definition, /// returns that function's `DefId`. fn is_fn_ref(ty: Ty<'tcx>) -> Option<DefId> { let referent_ty = match ty.kind() { ty::Ref(_, referent_ty, _) => Some(referent_ty), ty::RawPtr(ty_and_mut) => Some(&ty_and_mut.ty), _ => None, }; referent_ty .map( |ref_ty| { if let ty::FnDef(def_id, _) = *ref_ty.kind() { Some(def_id) } else { None } }, ) .unwrap_or(None) } fn nth_arg_span(&self, args: &Vec<Operand<'tcx>>, n: usize) -> Span { match &args[n] { Operand::Copy(place) | Operand::Move(place) => { self.body.local_decls[place.local].source_info.span } Operand::Constant(constant) => constant.span, } } fn emit_lint(&self, ident: String, fn_id: DefId, source_info: SourceInfo, span: Span) { let lint_root = self.body.source_scopes[source_info.scope] .local_data .as_ref() .assert_crate_local() .lint_root; let fn_sig = self.tcx.fn_sig(fn_id); let unsafety = fn_sig.unsafety().prefix_str(); let abi = match fn_sig.abi() { Abi::Rust => String::from(""), other_abi => { let mut s = String::from("extern ""); s.push_str(other_abi.name()); s.push_str("" "); s } }; let num_args = fn_sig.inputs().map_bound(|inputs| inputs.len()).skip_binder(); let variadic = if fn_sig.c_variadic() { ", ..." } else { "" }; let ret = if fn_sig.output().skip_binder().is_unit() { "" } else { " -> _" }; self.tcx.struct_span_lint_hir(FUNCTION_ITEM_REFERENCES, lint_root, span, |lint| { lint.build("taking a reference to a function item does not give a function pointer") .span_suggestion( span, &format!("cast `{}` to obtain a function pointer", ident), format!( "{} as {}{}fn({}{}){}", ident, unsafety, abi, vec!["_"; num_args].join(", "), variadic, ret, ), Applicability::Unspecified, ) .emit(); }); } } </ins>

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


Question: - [Rustc now catches more cases of `pub_use_of_private_extern_crate`][80763] - [Changes in how proc macros handle whitespace may lead to panics when used with older `proc-macro-hack` versions. A `cargo update` should be sufficient to fix this in all cases.][84136] <ins> - [Turn `#[derive]` into a regular macro attribute][79078] </ins> [84136]: https://github.com/rust-lang/rust/issues/84136 [80763]: https://github.com/rust-lang/rust/pull/80763

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Input to is able to see underlying derive attributes. This is not supposed to happen as per the change in . A to remove this effect. But onwards, underlying attributes are visible again to derive and this is not mentioned in . Example code is available here: In the following code below, generates a function named which prints all derive attributes visible to it. is defined as: Ouputs a blank line: : :
cc - I believe the new behavior is the one we want, since it makes derived 'just another attribute'. If so, we should document it more clearly in the release notes.
This change was made by , but that PR was never tagged with for some reason.
Triage: dropping and as this isn't an actual regression.


Question: <ins> // build-pass fn main() { let _ = &[(); usize::MAX]; } </ins>

<!-- 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: code compiles in a reasonable amount of times or the slice gets elided entirely. Instead, this happened: code takes multiple minutes to compile/gets killed by the playground. <!-- 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. --: Also tested on playground stable and nightly.
The code compiled in about 6 seconds in Rust 1.29 and 1.30 : . Before that it had capacity error. After that it exceeded 15 seconds limit of godbolt. This is a but I cannot tag it.
It looks like this also works correctly on 1.31 stable as well:
Decided on as in the prioritization working group procedure.
Cc
Fixed in .


Question: }; if self.in_root && item.vis.node.is_pub() { <del> self.derives.push(ProcMacroDerive { </del> <ins> self.macros.push(ProcMacro::Derive(ProcMacroDerive { </ins> span: item.span, trait_name: trait_ident.name, function_name: item.ident, attrs: proc_attrs, <del> }); </del> <ins> })); </ins> } else { let msg = if !self.in_root { "functions tagged with `#[proc_macro_derive]` must

The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)


Question: use rustc_middle::ty::query::Providers; use rustc_middle::ty::TyCtxt; use rustc_session::Session; <ins> use rustc_span::hygiene::DesugaringKind; </ins> use rustc_span::Span; #[derive(Clone, Copy, Debug, PartialEq)]

I've been playing around with today, and it comes in super handy in blocks. However, it seems to run into issues when combined with the feature. I tried this code: I expected to see this happen: the code should compile just fine. Instead, this happened: This is a continuation of the discussion . As , this code (following the from the label-break-value RFC) compiles: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
So the error is generated here if I had to guess, I would assume that this function ought to be modified to check whether the and, if so, not to emit the error. (See  rust docs for a bit more info.)
Tagged as E-mentor since there are some instructions above.
claim


Question: <ins> fn g() where 'static: 'static, dyn 'static: 'static + Copy, //~ ERROR at least one trait is required for an object type { } fn main() {} </ins>

<!-- 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 <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I think this is the code crashing: Assigning P-low by the same rationale as , but I expect this to be much easier to fix than , , or
No longer crashing: `


Question: // except according to those terms. struct BuildData { <ins> foo: isize, //~ NOTE `foo` first declared here </ins> foo: isize, <del> foo: isize, //~ ERROR field `foo` is already declared </del> <ins> //~^ ERROR field `foo` is already declared [E0124] //~| NOTE field already declared </ins> } fn main() {

From: src/test/compile- Error E0124 needs a spanlabel and a spannote replaced with a span_label, updating it from: To:
Error message updated in .


Question: let ans = s(); //~^ ERROR this function takes 1 parameter but 0 parameters were supplied //~| NOTE the following parameter type was expected <ins> //~| NOTE expected 1 parameter </ins> let ans = s("burma", "shave"); //~^ ERROR this function takes 1 parameter but 2 parameters were supplied //~| NOTE the following parameter type was expected <ins> //~| NOTE expected 1 parameter </ins> }

From: src/test/compile- Error E0061 needs a span_label, updating it from: To: Bonus: the types could be incorporated into the label rather than a note (though we may want to avoid types with long names in the label)
Planning on tackling the bonus here. Is there a prefered max length for output on the console. In the case it would exceed this should i truncate the typename or just not include?
- great point. If you want to work on truncation, feel free to add it, too. I'm not sure if the term crate will tell you the current terminal size, but it may.
I'm fixing and I noticed that it and this issue currently share the same code for generating this error, and adding code to add a to the message in would fix both.
Did you do the bonus as well? I can tackle that if you haven't.
I haven't yet - I can fix the issue (currently testing/fixing unit tests) and you can take on the bonus part of the issue.
Sounds great to me! Thanks.
- I opened up issue to track the bonus portion of the work for you.


Question: // FIXME we need to revisit this for #67176 if rvalue.has_param() { <ins> trace!("skipping, has param"); </ins> return None; } if !rvalue

Fuzzer generated MIR, reduced, and UB-free under Miri (for real this time :sweatsmile:) Segfaults with enabled: , which is a valid pointer, somehow got propagated as 0: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That seems undesirable. Is there a surface Rust program that can produce this MIR? Asking primarily for prioritization purposes.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Minimized test case:
Here's an example using stable surface syntax (). Seems to have been introduced in 1.70, with in particular.
Nevermind seems like I was wrong. <details</details
It's not an LLVM miscompilation, the code is already by the time it goes to LLVM. With So it's defiantly happening in MIR ConstProp
The problem seems to be that when running on the statement , the frames arn't updated, so when it runs on , it thinks is their for local . , on to add logging and test. ()
claim
Cc


Question: relevant_pr_url, relevant_pr_user, pr_reviewer, <del> current_datetime </del> <ins> current_datetime, github_token, </ins> ): <ins> # type: (str, str, str, str, str, str, str) -> str </ins> '''Updates `_data/latest.json` to match build result of the given commit. ''' with open('_data/latest.json', 'r+') as f:

Updated the toolstate repository at https://rust-lang- currently does not seem to work, see e.g. To "tool failed to build"-issues are being created, either. remarked that the error . Cc


Question: impl<T: fmt::Debug> ops::FnOnce<(),> for Debuger<T> { type Output = (); fn call_once(self, _args: ()) { <del> //~^ ERROR `call_once` has an incompatible type for trait: expected "rust-call" fn, found "Rust" fn </del> <ins> //~^ ERROR `call_once` has an incompatible type for trait //~| expected "rust-call" fn, //~| found "Rust" fn </ins> println!("{:?}", self.x); } }

The multi-line errors should be extended to include this testcase. missed this because the didn't go through . I tried but that didn't work either. If someone can point me to to where to catch it, I can probably fix this too. cc Code: Error: Change to:


Question: error[E0038]: the trait alias `SelfInput` cannot be made into an object <del> --> $DIR/self-in-generics.rs:5:19 </del> <ins> --> $DIR/self-in-generics.rs:12:19 </ins> | LL | pub fn f(_f: &dyn SelfInput) {} |                   ^^^^^^^^^

<!-- 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. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:


Question: use crate::cmp::Ordering; use crate::fmt::{self, Debug, Display}; <ins> use crate::intrinsics::is_nonoverlapping; </ins> use crate::marker::{PhantomData, Unsize}; use crate::mem; use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn};

In , it was uncovered that is making some rather strong assumptions: two s with different address but the same type must not overlap. Not only is this a scarily non-local safety invariant, it is also fundamentally incomaptible with some APIs that ought to be correct, as demonstrated by this snippet (thanks to and for help with working out the example): to see the issue: will duplicate parts of the memory range when there is overlap, which leads to double-drop (other parts of the memory range are just lost, leading to memory leaks, but that is not the main issue here). This is not itself a soundness issue as it requires unsafe code to trigger UB. But this likely reflects an unintended consequence of . This got stabilized in as part of That commit references and an RFC, but is not mentioned in either of them. was in Accept that is unsound and document "non-overlap" as part of the safety invariant. This seems very fragile. Make not misbehave on overlap, either by panicking or by only swapping the non-overlapping parts. Cc
was in , which was authored by a "Charlie Fan". This is probably
Cc
This makes the method sound, but it seems like there could be other seems-like-they-should-be-ok cell projections that break under this behavior.
I don't think so. This makes the function behave "strangely", but since no data is duplicated nor discarded, I think it is sound.
I share this hunch, although the code, out of nowhere, may look very contrived. Consider: So it seems like -king (at least for non- types) is the only option that would allow us too keep the structural property of s, which, imho, is a very intuitive programmer mindset (and thus, a mistake that many would do should they not know about this caveat), and so a quite important thing to preserve .
That is an example of the "strange" behavior not being the right thing for this code, but it is not an unsoundness of per se. Your unsafe code is simply making wrong assumptions about the functional behavior of . Current favors the first operand in case of overlap (according to documentation); unsafe code that incorrectly assumes it would favor the second operand would be equally wrong. I don't see a bug in either way. IMO it seems rather strange to only panic for non- types.


Question: use crate::cmp::Ordering; use crate::fmt::{self, Debug, Display}; <ins> use crate::intrinsics::is_nonoverlapping; </ins> use crate::marker::{PhantomData, Unsize}; use crate::mem; use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn};

Btw, also exists. does not have array/slice projection functions though and they would be wrong due to the counts, so overlapping probably truly are not a thing.
At the very least, an argument that aren't allowed to overlap is easier to defend than that aren't allowed to overlap. Plus also, doesn't have guaranteed layout in the first place, so any example using tuples is (currently) implementation-detail-tied even before hitting . You could still construct an example using only types, of course; just replace the tuple with an actual type. You could even make it . As I understand it, there's three main cases here. ping two nonoverlapping is fine. ping two partially overlapping without any bound on has a sound, if surprising, definition, where the nonoverlapping part of the arrays are swapped. ping two partially overlapping unknown is unsound in any definition, unless both has no safety invariants and the overlapping portion is . The third case is obviously the most restricting one, and is defined on . To expound on first of the two subissues: Consider a type with the extra safety invariant that the second must be double the first . could even be . It would be valid to create two from , as you'd have and . There is no possible definition of (other than a no-op) which preserves the safety invariant. And of course the impl doesn't even know about the safety invariant. I could probably create an even worse example using underaligned types and relying on a specific endianness, perhaps even accidentally breaking validity invariants (think around partially overlapping ). The only two resolutions I'm confident in are making always panic for overlapping cells (because there could be safety invariants being broken) or forbidding overlapping s to -compatible types (optionally: that would be broken by ). And I don't like the subtle implications of the latter (e.g. being unsound for unbound ).
I don't think would be immediately unsound, you would still need a way to create overlapping s.
In particular, they certainly can only overlap in restricted ways -- if they overlap such that one's sits on the other's , I can already cause UB without just by storing into that and then reading it as a . Oh I see... to only swap the non-overlapping parts we have to make an argument that these parts have the same type (safety+validity invariant).


Question: use crate::cmp::Ordering; use crate::fmt::{self, Debug, Display}; <ins> use crate::intrinsics::is_nonoverlapping; </ins> use crate::marker::{PhantomData, Unsize}; use crate::mem; use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn};

Which... seems utterly bogus now that I think about it. Worse, the invariant could correlate the overlapping with the non-overlapping part, as in your example. (Removed a whole bunch of nonsense where I try to find some special cases that work.) Yeah we should make it panic.^^ It is unsound to create an to these though, even without I can already violate the safety invariant here by setting the second reference to . Ergo this is not a problem for , we can already assume such references do not exist. I am confused, is there a negation missing somewhere in this sentence?
Fair. I'm fairly confident that it'd be possible to come up with some safety invariant that a partial swap would break, though, with more data-dependent qualities. The parenthetical is an optional relaxation of the potential requirement (but at the cost of a lot of complexity).
But shouldn't it be forbidding overlapping s to -incompatible types? Not that I know what either of these things mean, but forbidding incompatible seems to make more sense than forbidding compatible.^^
Yeah, poor verbage. I meant roughly "forbidding overlapping s of types that can be used in (i.e. sized types)", with the optional extension of "only for those actually broken by " (however that would be defined).
that partially overlapping s through an enum is problematic even without :
Enums isn't really the same thing. That enum projections are unsound , but as also discussed in that article, struct projections are typically ok, and the array projection discussed here is essentially a struct projection, not an enum projection.
I would like to bring up my crate  which allows projecting through using a macro. example usage: Note: doesn't allow projecting through enums for exactly the reasons that explained. I'm not sure how could interact with to produce bad behavior, because you can only project to fields, which can't be swapped with their parent, but just in case someone else finds something interesting. i.e. This isn't possible, so it's not possible to project through to a field that's the same type as the parent. Alongside the fact that all fields are disjoint means that cell-project should only produce overlapping if they are also .
I agree with here. Sum types and product types are different, and really should commute around product types, i.e., ought to be sound.


Question: use crate::cmp::Ordering; use crate::fmt::{self, Debug, Display}; <ins> use crate::intrinsics::is_nonoverlapping; </ins> use crate::marker::{PhantomData, Unsize}; use crate::mem; use crate::ops::{CoerceUnsized, Deref, DerefMut, DispatchFromDyn};

You can use , which led me to this issue (it'd be good if we could support field projection inside of and ).
While you could use to check that the tuple layout conforms to the C-like layout needed to do such projection, I don't see how your specific use of would lead to two partially overlapping though. Note that the problem is not with projecting to a single field, but to a group/subset containing multiple fields (or like in the array/slice example, to a subarray/subslice with length ).
Oh I see, you're right. False alarm.


Question: <ins> error[E0038]: the trait alias `BB` cannot be made into an object --> $DIR/self-in-const-generics.rs:9:16 | LL | fn foo(x: &dyn BB) {} |                ^^ | = note: it cannot use `Self` as a type parameter in a supertrait or `where`-clause error: aborting due to previous error For more information about this error, try `rustc --explain E0038`. </ins>


Question: // except according to those terms. /// Creates a `Vec` containing the arguments. <ins> /// /// `vec!` allows `Vec`s to be defined with the same syntax as array expressions. /// There are two forms of this macro: /// /// - Create a `Vec` containing a given list of elements: /// /// ``` /// let v = vec![1, 2, 3]; /// assert_eq!(v[0], 1); /// assert_eq!(v[1], 2); /// assert_eq!(v[2], 3); /// ``` /// /// - Create a `Vec` from a given element and size: /// /// ``` /// let v = vec![1; 3]; /// assert_eq!(v, vec![1, 1, 1]); /// ``` /// /// Note that unlike array expressions this syntax supports all elements /// which implement `Clone` and the number of elements doesn't have to be /// a constant. </ins> #[macro_export] #[stable(feature = "rust1", since = "1.0.0")] macro_rules! vec { <del> ($x:expr; $y:expr) => ( <[_] as $crate::slice::SliceExt>::into_vec( $crate::boxed::Box::new([$x; $y])) </del> <ins> ($elem:expr; $n:expr) => ( $crate::vec::from_elem($elem, $n) </ins> ); ($($x:expr),*) => ( <[_] as $crate::slice::SliceExt>::into_vec(

Super easy to implement for anyone interested. The implementation in the RFC is sound, although the new code should be abstracted out into a function that the macro calls for inline and macro-sanity reasons. The function needs to be marked as public/stable, but should otherwise be marked as #[doc(hidden)], as it is not intended to be called directly -- only by the macro.
Willing to mentor on details.
I'd like to give it a shot :)
By the way: The seems very sparse. If it's okay, I'd expand that a bit while I'm on it, or should that go into a seperate PR?
Yeah, that's totally reasonable to do at the same time!
Great! What would be the preferred place where to put the new function? I've it to as for now (currently compiling it)
Since it's supposed to only be used by the macro (and will be doc(hidden)), it makes sense to me to put it in Putting it in makes sense, too, though.
has a section labeled "Internal methods and functions" that seemed to fit well.


Question: <del> error[E0658]: :literal fragment specifier is experimental and subject to change (see issue #35625) --> $DIR/feature-gate-macro-literal-matcher.rs:14:19 | LL | macro_rules! m { ($lt:literal) => {} } |                   ^^^^^^^^^^^ | = help: add #![feature(macro_literal_matcher)] to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </del>

Tracking issue for rust-lang/rfcs.
Is anyone working on implementation already? If not I can take a crack at it.
I'll probably do it.
Huh oh, we have an issue already: do we mean to include potentially minus-prefixed literals? If yes, we have a problem because 1. it means we have to return an Expr instead of a Lit, which means I'm not sure one will be able to use the bound fragment in a non-expr context (for example in a static array type?) and 2. it's no longer always a single-TT, so the benefits in terms of future-proofing are a bit less good. If we don't... well, we loose expressivity. I have no idea what is more intuitive though... Would you, as a Rust user, expect to parse ? I certainly can think of use cases for this...
good point. I think I would have expected it, I also agree with the complications.
Can't we upgrade Lit to support negative literals?
I'd expect "literal" (or a future integer-literal specifier) to include (negative 5), but not (the negation of positive 5). Perhaps that expectation doesn't match reality, though. For instance, based on parsing rules for non-literals, I'd expect to act like . So, if handling both and as literals makes this easier, that works. But "literal" definitely needs to include negative numbers, or we'd have a weird user trap to explain.
I'd expect "literal" (or a future integer-literal specifier) to include -5 (negative 5), but not - 5 (the negation of positive 5). Unary operators, including minus, are processed purely by the parser at the moment, no lexer involved. So their treatment is whitespace agnostic. (I personally think this is a good thing.)
I agree with is not syntactically different from and has no reason to be. But I also agree with the fact that the user will probably expect negative numbers to work as literals (even it – syntactically – they're not).
is also supported in literal patterns while arbitrary expressions are not. It'd be reasonable to support it in fragments as well.
Another thing that won't match is a macro call, like , or any of the other macros that I think of as expanding to a literal (, ...).


Question: <del> error[E0658]: :literal fragment specifier is experimental and subject to change (see issue #35625) --> $DIR/feature-gate-macro-literal-matcher.rs:14:19 | LL | macro_rules! m { ($lt:literal) => {} } |                   ^^^^^^^^^^^ | = help: add #![feature(macro_literal_matcher)] to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </del>

I dunno, maybe this is not such a good idea after all. Re-reading the RFC in a more skeptical light, I felt like the "Motivation" section could use some more concrete use cases. Maybe this is just failure of imagination on my part, though! I think the likelihood of this feature attracting people who really want constant expressions should be acknowledged as a drawback, too.
That's fine IMO. Personally I'd like it to match only explicit literals in code to distinguish, for example, between literal and identifier and produce different code for them. Right now this is not possible because all of , , are too broad and conflict with each other.
Hi All, I have implemented this feature in my fork of Rust over 1.25.0, under this branch: Following a quick review by a rustc mentor I may have the free time to provide a full pull request for this.
BTW label has the tooltip "implemented in nightly and unstable" but I did not see it there, i.e. commits & pull requests referencing this. Did I miss it?
The implementation that I worked on was merged, yay!
Is there anything stopping an FCP for this?
It's currently merged in unstable; do you mean an FCP to declare it stable?
Yes, an FCP to stabilise. Should have clarified.
Currently, it is not possible to pass a literal from a macro to another macro. . I think this is a bug.
Interesting! That is a bug. I opened to track it.
Agreed, this should be allowed just like passing any other node types.
Is there anything else preventing this from being stabilized? The issue above has been fixed.
This has baked for some time now and I believe it should be ready for stabilization. So let's start the review. merge The feature gate test is here: Unstable book: Tests defined here:
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), 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!


Question: <del> error[E0658]: :literal fragment specifier is experimental and subject to change (see issue #35625) --> $DIR/feature-gate-macro-literal-matcher.rs:14:19 | LL | macro_rules! m { ($lt:literal) => {} } |                   ^^^^^^^^^^^ | = help: add #![feature(macro_literal_matcher)] to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </del>

See for info about what commands tagged team members can give me.
Reading through the tests, I see that is a literal. While that makes sense to me, I remember hearing that it wasn't, but was instead a negation operator and a literal. Am I misremembering?
cc on
I agree that it makes sense. I would say that even if is interpreted as negation + a literal, I would probably still want the macro matcher to accept since that behavior seems more intuitive. In other words, I would see being more as an implementation detail than what a literal is in the mental model.
I think that the nuance with causes a bit of a problem, because I don't think it should be treated as a literal, but I also don't think that the current implementation of would allow detecting it either. You could naïvely allow but that would allow which is clearly wrong.
there are tests currently implemented that verify that is detected as a literal.
I worded that wrong; I meant that only having a matcher and not being able to distinguish strings and numbers means that you can't easily make not a literal.
for procedural macros the input as lexed by the compiler is (two tokens) but procedural macros can create tokens that are negatives (like ). In that sense matching for makes sense to me.
Are literals generated by the compiler counted as true literals? A quick example would be something like: This fails to match, as the expansion, I guess, happens after the selection. I just naively assumed that would have worked.
is not a literal generated by the compiler, it is an identifier followed by an exclamation mark followed by a set of parentheses containing some tokens. See for example: If you were to use it in expression position, it would be interpreted as an invocation of which expands to a string literal. In this case and in your macro though, it is never in a syntactic position where it would be treated as an expression.
I can understand semantically why it doesn't make sense, I just thought it would have, but that being said, I already changed it to , so there's no issue. It just made more sense to me as a literal, because according to the compiler, it could generate a literal from it. I guess it was more a question than an actual issue.
This is true, but there's more to it!


Question: <del> error[E0658]: :literal fragment specifier is experimental and subject to change (see issue #35625) --> $DIR/feature-gate-macro-literal-matcher.rs:14:19 | LL | macro_rules! m { ($lt:literal) => {} } |                   ^^^^^^^^^^^ | = help: add #![feature(macro_literal_matcher)] to the crate attributes to enable error: aborting due to previous error For more information about this error, try `rustc --explain E0658`. </del>

A few built-in macros can expand their arguments eagerly through ~m a g i c~, so they accept and likes even if they expect string literals: Fortunately (or not), this currently cannot be done in user-defined macros.
I actually just realised that I can't change it to , as it's used in . So, I've just had to manually unroll the macro. ! It doesn't look pretty. :( Ninja edit: I just tested what actually happens if you try to pass in a non-literal with . It rejects it the exact same way. Does the already make use of this feature? If not, the seems to propagate the required token. Oh, unless the compiler steps in... That's actually probably the case... I've reverted it back to the type.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Since you implemented this, would you be willing to write up the stabilization PR?
sure
This appears to be missing from the Rust reference


Question: } else { resolution.binding = Some(nonglob_binding); } <del> resolution.shadowed_glob = Some(glob_binding); </del> <ins> if let Some(old_binding) = resolution.shadowed_glob { assert!(old_binding.is_glob_import()); if glob_binding.res() != old_binding.res() { resolution.shadowed_glob = Some(this.ambiguity( AmbiguityKind::GlobVsGlob, old_binding, glob_binding, )); } else if !old_binding.vis.is_at_least(binding.vis, this.tcx) { resolution.shadowed_glob = Some(glob_binding); } } else { resolution.shadowed_glob = Some(glob_binding); } </ins> } (false, false) => { return Err(old_binding);

<!-- 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. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
`
label +S-bug-has-mcve
What is the expected output here? Can this actually compile, and if so, what does refer to?


Question: snapshot.recover_diff_marker(); } if self.token == token::Colon { <del> // if next token is following a colon, it's likely a path // and we can suggest a path separator self.bump(); if self.token.span.lo() == self.prev_token.span.hi() { </del> <ins> // if a previous and next token of the current one is // integer literal (e.g. `1:42`), it's likely a range // expression for Pythonistas and we can suggest so. if self.prev_token.is_integer_lit() && self.may_recover() && self.look_ahead(1, |token| token.is_integer_lit()) { // FIXME(hkmatsumoto): Might be better to trigger // this only when parsing an index expression. </ins> err.span_suggestion_verbose( <del> self.prev_token.span, "maybe write a path separator here", "::", </del> <ins> self.token.span, "you might have meant a range expression", "..", </ins> Applicability::MaybeIncorrect, ); <del> } if self.sess.unstable_features.is_nightly_build() { // FIXME(Nilstrieb): Remove this again after a few months. err.note("type ascription syntax has been removed, see issue #101728 <https://github.com/rust-lang/rust/issues/101728>"); </del> <ins> } else { // if next token is following a colon, it's likely a path // and we can suggest a path separator self.bump(); if self.token.span.lo() == self.prev_token.span.hi() { err.span_suggestion_verbose( self.prev_token.span, "maybe write a path separator here", "::", Applicability::MaybeIncorrect, ); } if self.sess.unstable_features.is_nightly_build() { // FIXME(Nilstrieb): Remove this again after a few months. err.note("type ascription syntax has been removed, see issue #101728 <https://github.com/rust-lang/rust/issues/101728>"); } </ins> } }

Having written Python for several hours, I made this mistake and couldn't realize what was wrong for a while. No response claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not sure whether it's worth to fix this right now. will significantly change this code, basically requiring a rewrite of this diagnostic.
Agreed, it's reasonable to wait for type ascription removal. Thanks for the info!
Now we should fix this error message: is not OK, we'd better suggest to use . I think you need to add proper logic for this part of code:


Question: /// Creating a pointer `b` to contents of another reference Reborrow(Span), <del> /// Creating a pointer `b` to contents of an upvar ReborrowUpvar(Span, ty::UpvarId), </del> /// Data with type `Ty<'tcx>` was borrowed DataBorrowed(Ty<'tcx>, Span),

This issue is a proposal for the deprecation of error code . I opened a PR () as part of an effort to add long error explanations for error codes that didn't have one (). I chose and for my erroneous code example, I used the example from . I quickly realized, through running the example and other code that would also raise and through the CI failure message, that was not being raised. I went back to consult the issue I received the original code example from and noticed comments about not occurring anymore with . The issue was eventually labeled with . But, looking at the current contents of the file, can still be emitted even while it isn't: also doesn't have any UI tests as it is part of the error codes in . Since , is no longer actually emitted (although it is in code that it could) thanks to , I believe it should be deprecated. I would be happy to help deprecate the error code, if it is decided that it should happen. I would just need to know the proper steps to take to deprecate an error code. If there are reasons for why it is still an error code, I would love to be enlightened. claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
If is not emitted anymore then it can be removed immediately. A crater run can also be done to ensure that this is the case. I'm also happy to do this if you want.
Sure, that sounds good.
Sorry just for clarification, do you want me to do the PR or you?


Question: let ty = tcx.type_of(def_id).instantiate_identity(); if ty.references_error() { // If there is already another error, do not emit an error for not using a type parameter. <del> assert!(tcx.dcx().has_errors().is_some()); </del> <ins> // Without the `stashed_err_count` part this can fail (#120856). assert!(tcx.dcx().has_errors().is_some() || tcx.dcx().stashed_err_count() > 0); </ins> return; }

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: ().haserrors().issome()'', 'thread 'rustc' panicked at 'assertion failed: ().haserrors().issome()'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc
in 'ish ICEs, I am seeing ice now, im wondering if that also relates to somehow :thinking:
Quite likely, I'll take a look.
I can reproduce this. It's Saturday morning here, I might get to it today, if not I'll look on Monday morning.
Fixing this is really easy, I just need to adjust the assertion a tiny bit. The hard part is deciding where to put the test. is the obvious place, but then I get complaining that there are too many files in that directory. Suggestions?
just bump the limit by one like everybody else? :upsidedownface: :seenoevil:
I ended up putting the test in , because it happens during type checking.


Question: #[proc_macro_attribute] pub fn expect_print_stmt(attr: TokenStream, item: TokenStream) -> TokenStream { assert!(attr.to_string().is_empty()); <del> assert_eq!(item.to_string(), "println!("{}" , string);"); </del> <ins> assert_eq!(item.to_string(), "println!("{}", string);"); </ins> item }

proc-macro derive panicked All of the 62 regressions are due to old versions of having an assert expecting instead of . So this is again a consequence of whitespace changes in pretty-printing (). I think we should be able to fix this by special casing the comma token during token stream pretty-printing and not printing the space before it.
Fixed in
Just FYI, we discussed this in the meeting. We felt like the action here was appropriate -- while in general we do not guarantee stability of pretty printing, it makes sense to be judicious, and in this particular case not having a leading space before just looks better anyway.


Question: parse_only: parse_only, no_trans: no_trans, no_analysis: no_analysis, <ins> no_rpath: no_rpath, </ins> debugging_opts: debugging_opts, android_cross_path: android_cross_path, write_dependency_info: write_dependency_info,

Currently (something after 0.5) rustc (IIUIC) is using rpaths to point libs and binaries to the appropriate locations. This is problematic when rustc and the other libs/bins are package e.g. for Fedora. The rpath usage should be made optional - can be used instead - and LDLIBRARYPATH.
Why is this problematic for packaging? Is it because the rpath values end up with the wrong values? Each crate's rpath has several values, one of which is supposed to be the final installation location (controlled with ). Can we just provide more control over which locations are used during rpathing?
In general Fedora recommends to not use rpaths [0], because the paths are hardcoded in the binary. Fedora preferres to point the dynamic linker to the appropriate paths [1]. But yes, we are more flexible about internal libraries - which the case is here. So yes, it would also help us if we could controll the rpath path (which goes a bit into the direction if issue ) [0] [1]
The following rpath is used in e.g. the cargo binary: The rpath referres to rpm's buildroot, where the lib won't stay (it will be instaled to ) Maybe the problem could adressed if the rpath would respect - but this could lead to problems at build time. Maybe LDLIBRARYPATH can be used to point to the correct dir's at build time, and the rpath can be used to point to the correct dir's at runtime. Just my 2ct - but you ar ethe expert :)
Thanks for those links. We do generate rpaths with the expectation that some of them will be invalidated by moving the binaries around. It's possible we could consider removing rpath, but it sure is nice to not think about dynamic loading when running binaries out of my build directory. We could easily add a flag to the configure script, to turn off the rpath for all the rust-provided libraries, with the assumption that package managers would modify during install. If we did that I feel like we would still want the installed rustc to generate rpaths with user-built libraries - otherwise the experience would be different depending on the rust installation. We could also just remove rpath completely - it doesn't work on windows anyway.


Question: parse_only: parse_only, no_trans: no_trans, no_analysis: no_analysis, <ins> no_rpath: no_rpath, </ins> debugging_opts: debugging_opts, android_cross_path: android_cross_path, write_dependency_info: write_dependency_info,

Another thing to consider is that, if we just used rustpkg for all builds, and let rustpkg install all libraries at a known location, then we might be able to conveniently not use rpath while still doing the right thing at load time. Can user directories like be put into ?
Yes - I can fully understand how easy running rust in the build directory is when using rpaths :) For the build directory use case it should be possible to create wrappers for rustc and friends which use to point to the correct dirs. You mention thet some libs might reside in , could you explain the overall concept you are following with this? In general I'd expect libraries to appear in /lib, /usr/lib some and some private /usr/lib/myapp. There are also some xdg specs that specify and - but let usfirst see what you say about ~/.rustpkg. Oh, I don't think that ~/.rustpkg would be expanded correctly if put into
Just to summarize my thoughts: If rpath is used, the rpath path beeing used should only use directories below (to point to non-standard dirs containing libs relevant for a rust component). The rpath path should not point to any build-time dir. To include libraries at buildtime or when using the binaries in the build directory I'd suggest using wrappers (isn't autotools doing it like this?) which set appropriately.
Any follow up thoughts?
Our package manager will by default not be installing libraries to a system location and will instead put them in the user's directory, . This doesn't seem out of the ordinary to me; consider cabal, etc. The behavior you recommend requires some deep changes to how Rust works, so need to be considered carefully. Does the current behavior prevent packaging in Fedora, and is there a minimal change we can make to unblock packaging? You'll probably be interested in this subject.
Thanks for the rustpkg explanation. Do I understand that rustpkg will create binaries and libs with rpaths pointing to the user's specific rustpkg dir ? My feeling is that this user specific rpaths should be configurable at build time. The use case is obviously when the binary or lib is going to be installed systemwide. The only rpath exception is the rpath pointing to the system wide package specific libdir (e.g. ).


Question: parse_only: parse_only, no_trans: no_trans, no_analysis: no_analysis, <ins> no_rpath: no_rpath, </ins> debugging_opts: debugging_opts, android_cross_path: android_cross_path, write_dependency_info: write_dependency_info,

I think that I'll spend a bit more time with looking at and and might get a better feeling for the problem. Btw.: I noted that the libdir isn't configurabel. Fedora for example keeps x86_64 libs in (/usr)?/lib64, and i686 in (/usr)/lib. IIUIC this is currently not possible with rust as the libs will be installed to /usr/lib/arch-specific-path
The point about libdir is well taken and I updated . I am not entirely sure how rustpkg does it's build now or how and intend for it to work, but based on the current language design I would expect that, yes, binaries installed to would have rpaths pointing there. Currently there are several rpaths configured for each linked library so that they hopefully fall back to something useful when the libraries are moved around during install or during the bootstrapping process, something like: The relative path to the library The absolute path to where the library was at build time The system installation path Under this scheme I would expect that would, when linking against libraries in , create rpaths to .
Yes, there are several rpaths used (seen in and ) and I'd say - even with looking at rust itself, without the packaging glasses on - that it should be configurable what rpaths are used. Maybe it should be an option of . As said, system wide binaries are the best example for binaries where you don't want to many rpaths - including no rpaths pointing to some user dir.
Please don't tag TJC :(
Sorry, TJC! Maybe it's time to give in and start working on Rust :) Seriously though, sorry. I'm sure it's a real PITA.
mentioned that this is a security issue, which I didn't realize. Debian also says .
By the way, it's possible to strip this with but it would be much nicer to not require a third party tool.
I generally wonder why you don't add a user-specific to to point to the user specific rustpkg dir instead of using rpath. That makes it much easier to cope with - and that would also be in par with (at least) the Fedora guidelines. And I suppose with Debian's too, as it's the common way. (See 3rd party java binaries. They modify the to point to some hidden dir in the userdir.)
We used to.


Question: parse_only: parse_only, no_trans: no_trans, no_analysis: no_analysis, <ins> no_rpath: no_rpath, </ins> debugging_opts: debugging_opts, android_cross_path: android_cross_path, write_dependency_info: write_dependency_info,

Users kept forgetting and/or getting annoyed having to adjust it when running from a build dir. Rpaths made it possible to run foo/bar/rustc no matter which rustc you chose.
right. IIUIC - I always feel like a noob when it comes to autotools - autotools are generating wrappers for binaries which are created during a build process and moves the original binaries to hiddend irectories. The wrappers are then modifying the environment (setting env vars etc) to achieve the same goal (so e.g. that rustc can be run from the dev directory without messing with the env vars yourself). I wonder if this could help.
Okay, it's actually not autools which creates these wrappers but libtool:
Sorry, I didn't mean to imply a disinterest in fixing this better, just noting how it came to be. Also strongly disinterested in using libtool. Would prefer going back to telling users to set env vars.
How about defaulting to static linking (when it works)? Dynamic linking is valuable, but mostly for global installs handled by a package manager. Of course, if we end up with a bunch of tools using that would be wasteful. I think RPATH will just lead to confusion, and it's an easy security hole to leave open.
I would be very happy to get static linking working well enough to make it a default in many such cases. But we ought to do the right thing when linking dynamically too. Is rpath-using- considered acceptable? I.e. is it just the absolute paths that are problematic?
The absolute paths are the ones that can easily be a security issue, so isn't that bad. I would still rather avoid it for a globally installed package but it's easy enough to strip for people who don't need it and won't be an issue if you don't know about it (like the absolute path could be). Using the rpath could be a flag, but the absolute path should never be there.
Nominating for milestone 2: backwards compatible. (The choice of whether one needs to put a setting in or use some configure flag for certain systems, etc, seems like a backwards compatibility issue. Though maybe I misunderstand and these are issues only for people developing itself, not for clients of ?) It also could well be that this is more appropriately assocated with milestone 1: well-defined.


Question: parse_only: parse_only, no_trans: no_trans, no_analysis: no_analysis, <ins> no_rpath: no_rpath, </ins> debugging_opts: debugging_opts, android_cross_path: android_cross_path, write_dependency_info: write_dependency_info,

I suspect and have a more concrete notion about this.
I don't have anything much to add to this despite it coming up for triage today. I think it has to be fixed still, I'm still happy to do it via whatever combination of static linking by default and use of is sufficient for packagers, and I haven't seen any clear movement on it in the meantime.
accepted for backwards-compatible milestone
I'm getting worried that we won't resolve this for 1.0. I agree this is important to fix. Here's my current suggestion: Modify the build system to once again set LDLIBRARYPATH/PATH to find the appropriate dynamic libraries. Add a flag to rustc to disable rpath Add a configure flag to disable rpathing the rust build itself. Packagers can use this to do whatever they want. With this logic the rust package itself could avoid rpath where distros have their own way of dealing with library paths. The rustc installed by these distros would still be rpathing user's crates for the sake of convenience. Is this an acceptable compromise or do distros want us to completely disable rpath? I'm afraid that doing so would provide an inconsistent developer experience depending on how rustc is acquired; if we need to do that then we instead must find a way to completely eliminate rpath.
If we start to just statically link everything by default then rpath becomes much less important and we can just say it's up to users to figure it out if they opt into dynamic linking.
I think we should completely remove absolute rpaths. It's okay to have $ORIGIN-based ones but it may not be a good default. I'm not sure what the answer is to that, but agree that static linking basically resolves this.
It doesn't appear that this is fully working. There are still rpaths in the binaries when configured with even though the flag for rustc does work. /usr/bin/rustc: RPATH=$ORIGIN/../lib:/build/rust-git/src/rust/x8664-unknown-linux-gnu/stage1/lib/rustlib/x8664-unknown-linux-gnu/lib:/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib
What steps did you follow to having the rpath show up? I thought I double checked on linux that the configure flag worked, but I may have overlooked something.


Question: enum PlaceAncestryRelation { Ancestor, Descendant, <ins> SamePlace, </ins> Divergent, }

<!-- 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. --This bug popped up in CI on a project of ours. This does not reproduce on stable, but does reproduce on nightly and the latest beta (). Bisection shows that was the first build with the regression. Further bisection points to being the commit that introduced the regression. If I had to guess from the PRs in the rollup I'd say seems the most likely, since it touched the code around the error source. <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label: +regression-from-stable-to-beta
Reduced:
This assertion is indeed introduced in . The two captures have the same place but different CaptureInfo. cc
Interesting. It's a bit hard to imagine how could have introduced this, since that just sorts a list. Fascinating! Maybe somebody from has a clue?
Actually, it's not at all hard to imagine, because introduced the following: The projections are actually the same, but the types differ in regions, which probably means that this comment is wrong:
Yeah, I just checked and the region of the match is an inferenced variable and gives an concrete ReFree instead.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Did some analysis: We cannot just replace the with . This will create two mutable references in edition 2021 and fail borrowck. Pre-2018 the places do get merged later so the issue isn't exposed. None of the upvar code makes use of the region info, and writeback will erase it anyway. So I think the fix should just be have the region erased when inserting/looking up from capture_information. I can submit a PR if you haven't started
I just started looking at it but if you have a solution, go for it!


Question: enum PlaceAncestryRelation { Ancestor, Descendant, <ins> SamePlace, </ins> Divergent, }

Happy to review your PR
I'm not sure about region code that much but regionchk uses the regions created: I think at one point mentioned getting rid of the region field entirely in UpvarBorrow, but since it wasn't required the discussion didn't proceed. Also it's more like this is a bug of the capture analysis than the sorting. We should never have two same places going into min capture in the list.
I was thinking about erasing the region from s (i.e. the key of captureinformation). But it turns out that's used later to create upvar tuple... So I switched captureinformation from HashMap to a linear vec looked up with custom eq fn instead.