Question: ) -> io::Result<(Process, StdioPipes)> { let maybe_env = self.env.capture_if_changed(); <del> let mut si = zeroed_startupinfo(); si.cb = mem::size_of::<c::STARTUPINFO>() as c::DWORD; si.dwFlags = c::STARTF_USESTDHANDLES; </del> let child_paths = if let Some(env) = maybe_env.as_ref() { env.get(&EnvKey::new("PATH")).map(|s| s.as_os_str()) } else {

More importantly, this is de facto the default way of how a process is created in Windows. Defaulting to really makes me confused before reading the internal source code.
Not always. Parent process can still set those handles to something other than . For example, if you launch App P from IntelliJ it actually prints "Hello World!" in a loop but not in the spawned console which is empty, but in IntelliJ internal terminal. returns non invalid handle. This solution would make behaviour different depending on how you launch your app. Also, you can explicitly ask to create new console with even if your app already uses console subsystem. In this case you also likely want to avoid inheriting handles because you want output of the spawned process to be displayed in the new console, not in the existing one. This solution doesn't help with this.
I can't verify your statements since I don't have IntelliJ atm, but even it's true, isn't it IntelliJ setting up the console with maybe some special debugging API? How to you modify the code of P to achieve the same? And realistically speaking, do people actually do that with GUI apps? I think in this case, it's impossible to be 100% sure where the user wants the output at. New option might be the way to go.
Your prediction was dead-on, as it came true in While we can do this, as is proposing, it seems best here that we create a function, or set of functions, that explicitly handle this kind of situation rather than guessing.
Even with new APIs, we still need reasonable default behaviour. And the Command API is documented as inheriting handles by default. However, currently the API neglects the "no handle set" case entirely as that's not really a thing in POSIX or ISO C (well, you can close stdio but that's usually considered a Bad Thing unless you're being very very careful).


Question: // from the CodeView line tables in the object files. self.cmd.arg("/DEBUG"); <ins> // Default to emitting only the file name of the PDB file into // the binary instead of the full path. Emitting the full path // may leak private information (such as user names). // See https://github.com/rust-lang/rust/issues/87825. // // This default behavior can be overridden by explicitly passing // `-Clink-arg=/PDBALTPATH:...` to rustc. self.cmd.arg("/PDBALTPATH:%_PDB%"); </ins> // This will cause the Microsoft linker to embed .natvis info into the PDB file let natvis_dir_path = self.sess.sysroot.join("librustlibetc"); if let Ok(natvis_dir) = fs::read_dir(&natvis_dir_path) {

Spawned off of When passing to rustc I would expect all paths that start with to be replaced with , instead a is still present. Note that this happens even in release mode, because rustc always tells the msvc linker to generate files. This can be "fixed" by passing either , or to rustc, but doing so will break backtraces with ( already prints almost nothing in release mode). As a sidenote, do we really need backtraces in release mode, and by consequence files? They will break anyway if only the is distributed or the directory is deleted. Moreover this shouldn't be needed in the first place since promises to "remap source names in all output (compiler messages and output files)" (from the output of ), "including ). Also note that neither nor the rustc book mention the need to pass one of those arguments to rustc to remap/remove the path to the file, which makes it harder for non-experts to know how to remove them. :
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Perhaps this should be amended to say compiler output but not linker outputs. PDB files are generated at the linking step, which is probably why sees non-determinism for --crate-type=bin (linked) and not for --crate-type=rlib (not linked). Passing to the linker to put a relative path to the PDB files is probably the best choice, as it is the least destructive, and the debugger will look for PDB files next to the executables, so it will be able to find it. Chromium uses this for its Windows linking step as well: ;drc=;l=2358 Doing this with could work if you can figure out which "to-be-remapped" path is going to be the path being written by the linker, and then pass the resulting path to . I must confess I am not sure how linking is being done, but I assume the binary is being linked by a dedicated linker, not by rustc itself? If so that is not too reliable. rustc could provide a switch to remove the absolute path to PDB files, which would just map to . The value proposition there seems low, since you can pass that as the user anyway.


Question: // from the CodeView line tables in the object files. self.cmd.arg("/DEBUG"); <ins> // Default to emitting only the file name of the PDB file into // the binary instead of the full path. Emitting the full path // may leak private information (such as user names). // See https://github.com/rust-lang/rust/issues/87825. // // This default behavior can be overridden by explicitly passing // `-Clink-arg=/PDBALTPATH:...` to rustc. self.cmd.arg("/PDBALTPATH:%_PDB%"); </ins> // This will cause the Microsoft linker to embed .natvis info into the PDB file let natvis_dir_path = self.sess.sysroot.join("librustlibetc"); if let Ok(natvis_dir) = fs::read_dir(&natvis_dir_path) {

Determinism is important for both release and debug builds, so I don't believe there is anything release-mode specific here or that a solution should be chosen that doesn't deal with debug mode? Could you say what is breaking about backtraces with ?
Without that flag I get something like: <details<summaryBacktrace</summary<p</p</detailsBut with it it just prints: <details<summaryBacktrace</summary<p</p</detailsThis seems to happen because the pdb file is searched relative to the current working directory, and when running that's often not the directory with the executable and pdb files. appears to work, but only as long as you execute it from the crate root, which is definitely not ideal.
Can move to the crate root before executing the target executable? Then cargo could pass (or debug) while other build systems pass or whatever works for them?
Wouldn't that break any workflow that relies on the current working directory always being where is executed from?
I think this meant the crate root instead of the cwd? I had no idea that would be a common thing, but you're right. It would change any use of . I would expect to be more commonly used for relative paths, as it doesn't depend on running from a cargo source tree, but maybe I am wrong. Regardless, I can see why changing behaviour isn't ideal. The MSVC linker doesn't present a whole lot of options though, as the path relative to where you plan to run the binary has to be encoded into the pdb files if you want a deterministic output. It seems the options are: -determinisic output, backtraces always work, debuggers work: PDB absolute paths. This is the default behaviour. output, , and backtraces work from the exe's directory: output, backtraces work from the crate root, but debuggers won't work: Have I missed an option? There's no option that I can see with both deterministic output and backtraces working from arbitrary working directories. AIUI, this github issue is about --remap-path-prefix not adding a flag, essentially. It would be nice if deterministic builds were easier to get!


Question: // from the CodeView line tables in the object files. self.cmd.arg("/DEBUG"); <ins> // Default to emitting only the file name of the PDB file into // the binary instead of the full path. Emitting the full path // may leak private information (such as user names). // See https://github.com/rust-lang/rust/issues/87825. // // This default behavior can be overridden by explicitly passing // `-Clink-arg=/PDBALTPATH:...` to rustc. self.cmd.arg("/PDBALTPATH:%_PDB%"); </ins> // This will cause the Microsoft linker to embed .natvis info into the PDB file let natvis_dir_path = self.sess.sysroot.join("librustlibetc"); if let Ok(natvis_dir) = fs::read_dir(&natvis_dir_path) {

But based on all of the above, it seems to me that is better solved through Cargo than through rustc's , perhaps behind a Cargo flag in As a convenience, maybe could provide an option to move to the exe's directory to run it, instead of users doing , which would let option 2 be more ergonomic while also supporting debuggers.
Would it be possible to have create a symbolic link to the file or the directory when it's not already present in the current working directory? This would partially solve the ergonomic problems of approaches 2 and 3
It'd probably be easier to have set , which effect the default search path for the used for
Any update on this? :)
I've just opened which solves the problem by making always pass to the linker. This seems like the best solution to me. The PR is currently blocked on backtrace-rs not handling this properly, but I've opened , which will hopefully fix that.


Question: //@ revisions: m68k //@[m68k] compile-flags: --target m68k-unknown-linux-gnu //@[m68k] needs-llvm-components: m68k <ins> //@ revisions: csky //@[csky] compile-flags: --target csky-unknown-linux-gnuabiv2 //@[csky] needs-llvm-components: csky </ins> // FIXME: disabled on nvptx64 since the target ABI fails the sanity check // see https://github.com/rust-lang/rust/issues/117480 /* revisions: nvptx64 [nvptx64] compile-flags: --target nvptx64-nvidia-cuda [nvptx64] needs-llvm-components: nvptx */ <del> // FIXME: disabled since it fails on CI saying the csky component is missing // see https://github.com/rust-lang/rust/issues/125697 /* revisions: csky [csky] compile-flags: --target csky-unknown-linux-gnuabiv2 [csky] needs-llvm-components: csky */ </del> #![feature(rustc_attrs, unsized_fn_params, transparent_unions)] #![cfg_attr(not(host), feature(no_core, lang_items), no_std, no_core)] #![allow(unused, improper_ctypes_definitions, internal_features)]

In we're trying to test the ABI adjustment logic of all targets. This generally works as the test is nocore and LLVM has backends for all targets available -- except it does not seem possible to test the csky target that way. Trying to add the usual leads to an error from tidy: The test passes just fine locally, so it seems like at least the downloaded LLVM has the component. I don't know why it was not to tidy's list. Cc
cc but also I think this was just an oversight.
FWIW if one just adds this to a test it does pass on CI but of course it may just be silently ignored, hard to say whether the test actually runs... this stuff makes tests quite fragile. :/
Yeah, the tidy check was to reduce the fragility because a lot of people were giving names other than the LLVM component's name, like riscv64 instead of riscv, etc.
The remaining question then is, how sure are we that the components accepted by tidy are all available on some CI runner?
Also, something else must have been going on... I this test before that sanity check was to tidy. Sadly the logs for failure are already gone.


Question: <ins> // This is a non-regression test for const-qualification of unstable items in libcore // as explained in issue #67053. // const-qualification could miss some `const fn`s if they were unstable and the feature // gate was not enabled in libcore. #![stable(feature = "core", since = "1.6.0")] #![feature(const_if_match)] #![feature(rustc_const_unstable)] #![feature(staged_api)] enum Opt<T> { Some(T), None, } impl<T> Opt<T> { #[rustc_const_unstable(feature = "foo")] #[stable(feature = "rust1", since = "1.0.0")] const fn unwrap_or_else<F: FnOnce() -> T>(self, f: F) -> T { //~^ ERROR destructors cannot be evaluated at compile-time //~| ERROR destructors cannot be evaluated at compile-time match self { Opt::Some(t) => t, Opt::None => f(), //~ ERROR E0015 } } } fn main() {} </ins>

As shown in const-qualification can ignore some s, in the context of libcore / rustc crates: This should not compile without "miri unleashed"; const-qualification does not see this function as const since the unstable feature is not enabled, and thus does not check it. It outside of libcore, nor . cc More discussion is also available . I have a fix and will post a PR shortly. There are a couple of existing cases in where this matters (for and ), and I'll fix those at the same time.


Question: <ins> error[E0277]: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` --> $DIR/issue-76168-hr-outlives-3.rs:6:1 | LL | / async fn wrapper<F>(f: F) LL | | LL | | LL | | LL | | where LL | |     F:, LL | |     for<'a> <i32 as FnOnce<(&'a mut i32,)>>::Output: Future<Output = ()> + 'a, | |______________________________________________________________________________^ expected an `FnOnce<(&'a mut i32,)>` closure, found `i32` | = help: the trait `for<'a> FnOnce<(&'a mut i32,)>` is not implemented for `i32` error[E0277]: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` --> $DIR/issue-76168-hr-outlives-3.rs:6:10 | LL | async fn wrapper<F>(f: F) |          ^^^^^^^ expected an `FnOnce<(&'a mut i32,)>` closure, found `i32` | = help: the trait `for<'a> FnOnce<(&'a mut i32,)>` is not implemented for `i32` error[E0277]: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` --> $DIR/issue-76168-hr-outlives-3.rs:13:1 | LL | / { LL | | LL | |     let mut i = 41; LL | |     &mut i; LL | | } | |_^ expected an `FnOnce<(&'a mut i32,)>` closure, found `i32` | = help: the trait `for<'a> FnOnce<(&'a mut i32,)>` is not implemented for `i32` error[E0277]: expected a `FnOnce<(&'a mut i32,)>` closure, found `i32` --> $DIR/issue-76168-hr-outlives-3.rs:6:1 | LL | / async fn wrapper<F>(f: F) LL | | LL | | LL | | LL | | where LL | |     F:, LL | |     for<'a> <i32 as FnOnce<(&'a mut i32,)>>::Output: Future<Output = ()> + 'a, | |______________________________________________________________________________^ expected an `FnOnce<(&'a mut i32,)>` closure, found `i32` | = help: the trait `for<'a> FnOnce<(&'a mut i32,)>` is not implemented for `i32` error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

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
Regression in cc :sweat_smile:
I knew this was a source of ICEs Most of these should already be reachable if they are in the body of a constant used in an array length. If you want to try fuzzing by sticking code into a const body...


Question: <ins> // Regression test for <https://github.com/rust-lang/rust/issues/111415>. // This test ensures that only impl blocks are documented in bodies. #![crate_name = "foo"] // @has 'foo/index.html' // Checking there are only three sections. // @count - '//*[@id="main-content"]/*[@class="small-section-header"]' 3 // @has - '//*[@id="main-content"]/*[@class="small-section-header"]' 'Structs' // @has - '//*[@id="main-content"]/*[@class="small-section-header"]' 'Functions' // @has - '//*[@id="main-content"]/*[@class="small-section-header"]' 'Traits' // Checking that there are only three items. // @count - '//*[@id="main-content"]//*[@class="item-name"]' 3 // @has - '//*[@id="main-content"]//a[@href="struct.Bar.html"]' 'Bar' // @has - '//*[@id="main-content"]//a[@href="fn.foo.html"]' 'foo' // @has - '//*[@id="main-content"]//a[@href="trait.Foo.html"]' 'Foo' // Now checking that the `foo` method is visible in `Bar` page. // @has 'foo/struct.Bar.html' // @has - '//*[@id="method.foo"]/*[@class="code-header"]' 'pub fn foo()' // @has - '//*[@id="method.bar"]/*[@class="code-header"]' 'fn bar()' pub struct Bar; pub trait Foo { fn bar() {} } pub fn foo() { pub mod inaccessible {} pub fn inner() {} pub const BAR: u32 = 0; impl Bar { pub fn foo() {} } impl Foo for Bar {} } </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. --Consider the following code is local to and inaccessible, and should not be documented. Instead, rustdoc currently documents the module at the same level as . <!-- 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. --: </details
cc does this have to do with those changes you made to item collection?
Very likely. I won't be able to fix it until next week though. EDIT: I suspect it broke from
I just realized that this is broken on stable, too, so I think the cause may be older than that?
Oh. I'm at least happy to realize that I didn't break it recently. Thanks for the report. Will fix it monday.


Question:
let cache = cache(); write!(w, "
Implementors

 Implementors

 ")?; if let Some(implementors) = cache.implementors.get(&it.def_id) {

A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.


Question: <ins> // check-pass fn foo<T>(t: T) -> usize where for<'a> &'a T: IntoIterator, for<'a> <&'a T as IntoIterator>::IntoIter: ExactSizeIterator, { t.into_iter().len() } fn main() { foo::<Vec<u32>>(vec![]); } </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. --This code compiles correctly: However, this code does not: The only change was effectively replacing with . My understanding is that these are supposed to be equivalent as it is . The exact compile error is as follows: The error also occurs on the Nightly compiler.
We currently do not normalize projections if they contain unbound variables (stuff which is introduced using a qualifier, in your example). This means that we never actually see that is equal to . cc but I don't think we can do much about cases like this for now.
Is this the same underlying issue as and possibly
I think has a similar cause. is caused by something different, probably related to
Using trait objects instead of has the same issue
Came up with another interesting version. This will fail to typecheck: Replacing the header of foo with this will successfully typecheck: Might be useful for diffing.
Fixed by . Not going to close this because this is a simple example that didn't ICE, but still failed to compile.


Question: <ins> // check-pass fn foo<T>(t: T) -> usize where for<'a> &'a T: IntoIterator, for<'a> <&'a T as IntoIterator>::IntoIter: ExactSizeIterator, { t.into_iter().len() } fn main() { foo::<Vec<u32>>(vec![]); } </ins>

I believe this should successfully compile, but it currently fails claiming that vec's iterator isn't ExactSizeIterator: Things compile correctly if the bounds are changed to rather than .
It does seem like it should compile... cc
Another instance of this from : fails with
do you know of a workaround for this bug? It's currently blocking me and I'm not entirely sure how else to structure my code.
The only workaround I know of is to remove the lifetime parameter Steven Fackler
I believe this issue I ran in to might be related - . I was trying to put a bound on an associated type from two different types and require them to be , but Rust always just wanted to assume the types must be the same. By creating a separate trait that is implemented without relying on an HRTB, and then using the HRTB around that trait, it did compile. I'm fairly sure this is a bug. rustc ought to still be able to resolve what the associated type actually is and then evaluate traits on that. It seems like it's trying to look for implementations on a hypothetical associated type black box rather than the real type it points to.
Another example, when trying to bind :
Ran into this in one of my own projects, and used this odd workaround (suggested on satck overflow):
Another variation of this issue (as far as I can tell): Fails with:
I just ran into this (): I get the following error on latest stable (1.52.1): The workaround in my case was to pull out the associated type into a type parameter, and require that it be invariant w.r.t. the universally quantified lifetime parameter ():
Fixed by , marking as needs-test because wasn't an ICE and a simple enough example I'd like to have a test for.
This bug might not be completely fixed. Here is another test case that still fails on nightly and beta: EDIT: Made the case a bit smaller:
is the smallest example I can find: This below works: While this doesn't: Can you confirm that the second case works in your PR as well?
is still not fixed on latest nightly. cc EDIT: I suspect that this example is some form of .
Another bug of this kind:


Question: <ins> //! Email me at <hello@example.com>. //! Email me at <hello-world@example.com>. //! Email me at <hello@localhost> (this warns but will still become a link). // @has email_address/index.html '//a[@href="mailto:hello@example.com"]' 'hello@example.com' // @has email_address/index.html '//a[@href="mailto:hello-world@example.com"]' 'hello-world@example.com' // @has email_address/index.html '//a[@href="mailto:hello@localhost"]' 'hello@localhost' </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: rustdoc parses the link as an email address and renders it as a mailto: link. Instead, this happened: <!-- 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. --(from a GitHub Actions run, the latest nightly won't install on my Arch box due to broken components)
This turned out to be a bug in my docs; I didn't intend for this to be rendered as a link, but I was hoping for a better error message.
I think this PR introduced this new behavior:
This is weird - rustdoc should be ignoring any link that has in it:
Ah I see the issue - should only be reported if the link isn't ignored. do you have time to fix it? It should be as simple as adding the same check here:
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
can part of the fix here be to improve the error message? "Unknown disambiguator" doesn't tell me much about what is wrong or how to fix it.
I'm confused. After there won't be an error message, because the link shouldn't have been treated as an intra-doc link in the first place. Are you asking for a lint that warns about docs that will be rendered as mailto: links? I'm not sure how useful that is, mailto: links are normal and reasonable to write.
based on the UI tests that are checked in, if I actually intend to use an intradoc link with a disambiguator and fat finger as , the error message is not super friendly.
Hmm, what would you like to see instead? There's quite a few valid disambiguators, I'm not sure it makes sense to list them all. Maybe we could add a header to the disambiguator section of and link there?
Ideally I'd like to see a suggestion to use a disambiguator that corresponds to an item that is currently in scope or otherwise resolvable via the path after the invalid disambiguator.


Question: <ins> //! Email me at <hello@example.com>. //! Email me at <hello-world@example.com>. //! Email me at <hello@localhost> (this warns but will still become a link). // @has email_address/index.html '//a[@href="mailto:hello@example.com"]' 'hello@example.com' // @has email_address/index.html '//a[@href="mailto:hello-world@example.com"]' 'hello-world@example.com' // @has email_address/index.html '//a[@href="mailto:hello@localhost"]' 'hello@localhost' </ins>

Hmm, that seems useful, although I think it should be a separate issue. Maybe we could try resolving without a disambiguator and see if there are any results? That would need a pretty significant overhaul of how it works currently, right now all the errors are emitted eagerly which would end up with a lot more verbose output that might not be relevant. What would you expect to see if the link isn't valid even without the disambiguator?
I think an extra to more docs on intradoc link disambiguators would be helpful per your previous comment. The idea to attempt to resolve items for all invalid disambiguators feels similar to the Ruby CLI and REPL's "did you mean" feature, which I find quite useful.
The PR improving the diagnostics is being reverted in , reopening the issue.
I don't think this is still a regression; the diagnostics improvement was not part of the fix for the regression. (The regression was fixed in .)
Yeah, never had a tracking issue.
was relanded in


Question: <ins> //@ check-pass // issue: rust-lang/rust#123824 // This test is a sanity check and does not enforce any stable API, so may be // removed at a future point. fn main() { let x = f32::from(3.14); let y = f64::from(3.14); } </ins>

After we started seeing the following compile failure: I repro'd this locally on but we have so we're fairly sure that it started with . Of the changes in that rollup is the only one that seemed to touch float stuff, but I'm not sure how adding some extra impls for and would break inference in this case.
cc is it possible that adding the the impls for / may have caused type inference regression here?
It must be, but I don't know why since wasn't touched. Also reproduced locally
When there is only one applicable impl it can guide inference, as soon as there are multiple it can't use those and instead goes to default-numeric-fallback which appears to be for floating point.
Correct.
Just coming to the same conclusion - the literal is getting guided to f32 on stable since that's the only type that fits the , but when there are more options it gets the default float literal type of f64
I'll put up a PR to remove these impls for now but what is the correct longer term fix? cc
label -needs-triage +A-inference +F-f16andf128
Race condition <img width="497" alt="image" src=""
I did not remove the feature label lol (it wasn't even in the list), welldone GitHub
Theoretically, type inference regressions are permitted as part of Rust's 1.0 stability guarantees. In practice, if the regressions are too bad, the changes usually get reverted and are subsequently blocked indefinitely iirc. However, we could make use of editions if the worst comes to the worst. See arrays & . I think we have something similar queued up for Rust 2024. On mobile, can't link.
I put a fix up at and opened to further discuss what we want to do here. Thanks for identifying this so quick!
if you get the chance, could you link some of the places that caused this failure? It would be good to have some references for how this behavior is being relied on in the wild.
that we caught it on. It's a pretty simple case (that type is just an type alias) and seems reasonable to break on an edition boundary (or even just on a release as long as there's a machine applicable suggestion to fix it).
Hi! I'm from the Bevy project.


Question: <ins> //@ check-pass // issue: rust-lang/rust#123824 // This test is a sanity check and does not enforce any stable API, so may be // removed at a future point. fn main() { let x = f32::from(3.14); let y = f64::from(3.14); } </ins>

We caught this bug with too, though the error originates from the crate (0.3.18).
Awesome, thanks for the report! I started a list of known regressions at , and there is a crater run going to figure out how best to deal with this behavior. The fix for this was merged so should be available on the next nightly (couple of hours?).


Question: <ins> error[E0277]: the size for values of type `dyn ToString` cannot be known at compilation time --> $DIR/issue-61525.rs:14:33 | LL |         1.query::<dyn ToString>("") |           -----                 ^^ doesn't have a size known at compile-time |           | |           required by a bound introduced by this call | = help: the trait `Sized` is not implemented for `dyn ToString` note: required by a bound in `Example::query` --> $DIR/issue-61525.rs:2:14 | LL |     fn query<Q>(self, q: Q); |              ^ required by this bound in `Example::query` help: consider relaxing the implicit `Sized` restriction | LL |     fn query<Q: ?Sized>(self, q: Q); |               ++++++++ error[E0308]: mismatched types --> $DIR/issue-61525.rs:14:33 | LL |         1.query::<dyn ToString>("") |           --------------------- ^^ expected trait object `dyn ToString`, found `&str` |           | |           arguments to this function are incorrect | = note: expected trait object `dyn ToString` found reference `&'static str` note: associated function defined here --> $DIR/issue-61525.rs:2:8 | LL |     fn query<Q>(self, q: Q); |        ^^^^^ error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>

Issues with this diagnostic: method is not being invoked on a trait object; it's invoked on the concrete value . note suggests importing the same trait that is already being reported about.
/cc also looks relevant based on the title, but appears to have a different enough error message.
Is the following output from enough?
I don't feel like it's at the usual amazing quality . My points still appear to exist: In some magical world, I might hope for something like this (and I'm very flexible in that): I tried to address my points via the s.


Question: use serde::{Deserialize, Serialize}; /// rustdoc format-version. <del> pub const FORMAT_VERSION: u32 = 19; </del> <ins> pub const FORMAT_VERSION: u32 = 20; </ins> /// A `Crate` is the root of the emitted JSON blob. It contains all type/documentation information /// about the language items in the local crate, as well as info about external items to allow

At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:


Question: opaque_type_key, self.fcx.infcx.tcx, true, <del> decl.origin, </del> ); self.typeck_results.concrete_opaque_types.insert(opaque_type_key.def_id, hidden_type);

Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that


Question: <meta charset="utf-8" /> <title>{title}</title> <del> <link href='http://fonts.googleapis.com/css?family=Oswald:700|Inconsolata:400' </del> <ins> <link href='http://fonts.googleapis.com/css?family=Oswald:700|Inconsolata:400,700' </ins> rel='stylesheet' type='text/css'> <link rel="stylesheet" type="text/css" href="{root_path}{krate}/main.css">

It's currently very bright and distracting (IMO). (Sorry :( ) Current scheme, for future triage/comparison purposes: !
I think I should reconsider my career in graphic design.
I'm looking at this.
(The relevant file is , if you're lost. :) )
BTW I was wondering, why not just use for src line numbering? Probably more optimized/idiomatic in the browser.
Also, it's pretty much impossible to have consistency between rustdoc and the old codemirror (tutorial) since both parsers behave very differently. would it be possible to pass the standalone documentation through rustdoc?
Doesn't this mean every line is a new tag? Also, it possibly screws with copy-paste and making the formatting consistent. This bug is specifically about the colour scheme of rustdoc since it's so wild. Also, about using rustdoc for everything.
My preference for the highlighting scheme is bold for keywords, green for macros, red for strings (the current color is fine), gray for comments (would be nice if code within comments were highlighted). I'd also like to hear more suggestions before we change it.
Something I hacked up a few days ago: ! (The macro colour wasn't "optimised" at all.)
No, it would look like this: I think it would be better to use that since that's the browser native numberings. No it doesn't. The identifier of a list aren't inlined with the content. is an example.
Oh, awesome. It does seem like a good idea, if you can get that to work.
Another note: current rustdoc parsing could be improved, i.e. the "ident" class corresponds to variable names, function names, paths, parameters... could be more split if you ask me.
The highlighting is performed by just by the token types the lexer (with a little bit of extra logic for attributes, macros and $ non-terminals in macros) and so does not have that information.


Question: <ins> // Copyright 2015 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. trait Trait<'a> { type A; type B; } fn foo<'a, T: Trait<'a>>(value: T::A) { let new: T::B = unsafe { std::mem::transmute_copy(&value) }; } fn main() { } </ins>

Minimised example: Both the and the fail in the same way, with an ICE: Adding bounds to and on the trait or in the fn’s where clause doesn’t fix it, but changing to does fix it. (In the particular case that I was dealing with, the lifetime could_ be changed to where this was a problem, but it would only have taken a slight variation of it for me to be in a situation where I needed a non- implementation. There were, of course, other arguments which were using the .) The whole thing around there seems a bit fragile and I’m not quite sure what’s supposed to work and what’s not; if we just take an and transmute it to , for example, we get “error: cannot transmute to or from a type that contains type parameters in its interior [E0139]”. Anyway, an ICE is always a bug, so here’s the report!
No longer repros. compiles now. Fails with: But no ICE.


Question: <ins> // Copyright 2015 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. trait Trait<'a> { type A; type B; } fn foo<'a, T: Trait<'a>>(value: T::A) { let new: T::B = unsafe { std::mem::transmute_copy(&value) }; } fn main() { } </ins>

While trying to learn how to return a closure.... I came across this.. gives....
Commenting-out the body of still results in an ICE.
I can't seem to produce an ICE no matter what I do.
Those closure kinds info are already gone, so I think many related bugs are gone as well. e.g. I cannot reproduce a bug related to closure kinds and macro


Question: Err(ManuallyDrop::into_inner(data.p)) }; <del> // Compatibility wrapper around the try intrinsic for bootstrap #[inline] </del> <ins> // Compatibility wrapper around the try intrinsic for bootstrap. // // We also need to mark it #[inline(never)] to work around a bug on MinGW // targets: the unwinding implementation was relying on UB, but this only // becomes a problem in practice if inlining is involved. #[cfg(not(bootstrap))] use intrinsics::r#try as do_try; #[cfg(bootstrap)] #[inline(never)] </ins> unsafe fn do_try(try_fn: fn(*mut u8), data: *mut u8, catch_fn: fn(*mut u8, *mut u8)) -> i32 { <del> #[cfg(not(bootstrap))] { intrinsics::r#try(try_fn, data, catch_fn) } #[cfg(bootstrap)] { use crate::mem::MaybeUninit; </del> <ins> use crate::mem::MaybeUninit; #[cfg(target_env = "msvc")] type TryPayload = [u64; 2]; #[cfg(not(target_env = "msvc"))] type TryPayload = *mut u8; let mut payload: MaybeUninit<TryPayload> = MaybeUninit::uninit(); let payload_ptr = payload.as_mut_ptr() as *mut u8; let r = intrinsics::r#try(try_fn, data, payload_ptr); if r != 0 { </ins> #[cfg(target_env = "msvc")] <del> type TryPayload = [u64; 2]; </del> <ins> { catch_fn(data, payload_ptr) } </ins> #[cfg(not(target_env = "msvc"))] <del> type TryPayload = *mut u8; let mut payload: MaybeUninit<TryPayload> = MaybeUninit::uninit(); let payload_ptr = payload.as_mut_ptr() as *mut u8; let r = intrinsics::r#try(try_fn, data, payload_ptr); if r != 0 { #[cfg(target_env = "msvc")] { catch_fn(data, payload_ptr) } #[cfg(not(target_env = "msvc"))] { catch_fn(data, payload.assume_init()) } </del> <ins> { catch_fn(data, payload.assume_init()) </ins> } <del> r </del> } <ins> r </ins> } // We consider unwinding to be rare, so mark this function as cold. However,

This is a regression from the last couple of days. Looks like the compiler for something forever. Curiously, the run with completes successfully. I'll investigate in more detail. The list of tests: All of the tests are supposed to report errors.
Here's the backtrace:
Looks like this is caused by the recent unwinding changes. cc
GCC toolchain version on which this reproduced:
Does this happen with stage 1 rustc or stage 2 rustc?
Stage 1, e.g. I'll check stage 2 now.
( is confirmed to be the cause, removing .)
I have a pretty good idea of what the problem might be. I'm traveling right now but I'll try to have a PR up by tonight.
The issue doesn't reproduce with a stage 2 compiler. That's great news long term, but broken stage 1 still makes any compiler work involving testing hard.
I don't have a Windows machine to test on right now, but can you try marking and with in to see if that fixes the issue?
can you try marking and with in to see if that fixes the issue? It does! Thanks for a workaround.


Question: &exports, machine, !sess.target.is_like_msvc, <del> /*comdat=*/ false, </del> <ins> // Enable compatibility with MSVC's `/WHOLEARCHIVE` flag. // Without this flag a duplicate symbol error would be emitted // when linking a rust staticlib using `/WHOLEARCHIVE`. // See #129020 true, </ins> ) { sess.dcx() .emit_fatal(ErrorCreatingImportLibrary { lib_name, error: error.to_string() });

<!-- 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. --I tried to build using a simple then . I expected to see this happen: linking success. Instead, this happened: MSVC link returns LNK2005 and fails to the static library. It most recently worked on: 1.77.2 <!-- Provide the version you are using that has the regression. --: This is caused by both and When creating stdlibs, each MR causes the Rust compiler to add an export of ; one comes from api-ms-win-core-synch-l1-2-0.dll and the other from This error will not be found until one consumes the Rust-generated library. I am filing this report to consolidate the ones in and <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged
cc
Using for a rust staticlib seems weird to me but cc
The purpose is to allow reexporting a subset of symbols on MSVC. This can be achieved with partial linking elsewhere, but this is not doable on Windows. I wrote about a specific application here:
Sorry, I'm confused, are you trying to create a dynamic or static library? The article that you linked to talks about static libraries, but the backtrace in the OP shows that you are creating a dynamic library.
Both: I'm using the Rust-produced static library through , plus a module definition file, to create a dynamic library. This is because (apart from size considerations) GNOME's gobject-introspection needs a shared library, and Meson will only accept targets that are generated by itself. Further context is here:
In this particular case, because of the imports present in the stdlib, linking something against the Rust-produced static librsvg is enough to trigger the issue.
I am still struggling to understand why is needed, at least for MSVC.


Question: &exports, machine, !sess.target.is_like_msvc, <del> /*comdat=*/ false, </del> <ins> // Enable compatibility with MSVC's `/WHOLEARCHIVE` flag. // Without this flag a duplicate symbol error would be emitted // when linking a rust staticlib using `/WHOLEARCHIVE`. // See #129020 true, </ins> ) { sess.dcx() .emit_fatal(ErrorCreatingImportLibrary { lib_name, error: error.to_string() });

So the DLL is created here: is used so that the DLL includes every single object in the staticlib, even if it's unneeded or indeed causes conflicts. But then is used to add a which presumably defines what actually gets exported from the DLL. What I'm not understanding is what would be different if, for MSVC, it just linked normally without ? I.e. using instead.
On MSVC, static linking doesn't let you reexport dependencies' symbols automatically, they're subject to DCE. . However, PE-COFF static libraries don't support symbol visibility, so the is there to make all Rust symbols private and keep only the librsvg ones. See e.g. and for consequences of not blocking out symbols like .
Sure but the should work regardless of if is used or not because using the export will force the linker to go looking for the symbol(s) listed in the file. E.g. as a test I have the following static lib (using to make symbols easier to find): Which I compile into a static lib using: rustc -O --crate-type=staticlib And I have the following file: Which for simplicity I compile via rustc but I'm using an empty file and also raw linker arguments: rustc -O --crate-type=cdylib -C link-args=" " This compiles and if I see the two functions I wanted: No std symbols are exported.
Independent of whether whole-archive is necessary for this specific use case, we should support linking rust staticlibs with whole-archive, even if because of the fact that not linking with whole-archive can mask linker errors, which will later show up when any change to the cgu partitioning is made, which often causes people to report a regression even though their crate is at fault.
If I repeat the above using even in this simple case I get a bunch of errors, not just : I'm not really sure if rustc can currently guarantee that whole archive will work without doing some of the work of a linker. Which sounds like a new feature and not specific to MSVC.
All duplicate symbol errors for are caused by That it works without is by accident and likely to break in case of cgu partitioning changes.


Question: &exports, machine, !sess.target.is_like_msvc, <del> /*comdat=*/ false, </del> <ins> // Enable compatibility with MSVC's `/WHOLEARCHIVE` flag. // Without this flag a duplicate symbol error would be emitted // when linking a rust staticlib using `/WHOLEARCHIVE`. // See #129020 true, </ins> ) { sess.dcx() .emit_fatal(ErrorCreatingImportLibrary { lib_name, error: error.to_string() });

Sure, and then if I compile the static library with and use whole archive then I get a whole slew of errors, which I'll spoiler for length <details<summarylinker errors</summary</details
There are also some technical details in that kleisauke linked. windows-gnu is unaffected because it uses legacy import libraries format.
To get back to address case we could either: Filter symbols when building a staticlib Try using COMDAT in generated raw-dylibs (might not work in this situation)
Filter in what way?
When linking raw dylibs into a staticlib we could exclude the objects containing . Except for one.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: -C lto // no-prefer-dynamic // ignore-emscripten no threads support use std::thread; static mut HIT: usize = 0; thread_local!(static A: Foo = Foo); struct Foo; impl Drop for Foo { fn drop(&mut self) { unsafe { HIT += 1; } } } fn main() { unsafe { assert_eq!(HIT, 0); thread::spawn(|| { assert_eq!(HIT, 0); A.with(|_| ()); assert_eq!(HIT, 0); }).join().unwrap(); assert_eq!(HIT, 1); } } </ins>

nightly-2017-10-24 contains a libtest with bad DWARF: I can reproduce this if I recompile libtest locally: The problem can be fixed by disabling thinlto (and keeping the codegen units is ok). I noticed this with nightly-2017-10-24 because it is the first nightly compiled with thinlto, but the problem also occurs if I compile libtest with thinlto enabled using earlier compilers (eg nightly-2017-10-17). Inspecting the DWARF, a DIE at that local ref offset does exist in another codegen unit, so the problem seems to be that we should be using a global ref instead.
cc'ing since he's been poking around in LLVM's DWARF generation code recently.
Sorta smells like an LLVM bug -- but hard to say. Who should investigate?
triage: P-medium if you are able to investigate as part of ThinLTO work would be great.
It's likely that this is the cause of , which even if the underlying segfault were fixed would likely prevent backtraces from happening on OSX.
This is unfortunately not "automagically fixed" if we upgrade to LLVM 5
Making progress. First up, minimized Rust source code via creduce to get: Next up let's see if we can reduce it to one object file: Ok looks like only one object file is invalid! Let's take a look the LLVM IR: Ok let's see what's happening by minimizing the LLVM IR: yielding which I . I checked out LLVM trunk, , and looks like the error is still on LLVM trunk.
I'm not sure at this point if this is an LLVM bug, a rustc bug, or a ThinLTO bug. I've managed to extract what I believe is a for this which reproduces the error. I'm hoping fixing that IR will fix all other related issues to this at this point in time. For those of you more familiar with debug information (probably everyone other than me!) mind taking a look at that IR? Does it look "obviously wrong"? If it's "obviously wrong" I can try to work backwards to figure out what piece of the pipeline introduced such a wrong piece, but if it looks correct I can open an LLVM bug saying that we think it may be broken (and maybe they'll say it's "obviously wrong"!)


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: -C lto // no-prefer-dynamic // ignore-emscripten no threads support use std::thread; static mut HIT: usize = 0; thread_local!(static A: Foo = Foo); struct Foo; impl Drop for Foo { fn drop(&mut self) { unsafe { HIT += 1; } } } fn main() { unsafe { assert_eq!(HIT, 0); thread::spawn(|| { assert_eq!(HIT, 0); A.with(|_| ()); assert_eq!(HIT, 0); }).join().unwrap(); assert_eq!(HIT, 1); } } </ins>

cc
Er, I went ahead and to go ahead and broaden the search.
The DWARF is definitely badly formed: it's using a unit-relative offset to reference the parameter type, when it should be using a section-relative offset because the type is in a different unit. The bad offset is occurring for a parameter to subprogram in . The problem is that subprograms and share the same , but have different units ( and ). Based on some print debugging, it appears that LLVM doesn't handle this case. So and are constructed in unit , but when is constructed, it reuses the existing DIE as its parent, and so it also ends up in unit . So my guess is that when the parameter is constructed, it uses the unit that was specified to determine if the parameter and type are in the same unit, and thus gets it wrong.
thanks for the info! I know basically nothing about DWARF though and malformed whatnots, so the IR here is heavily edited by both machines (creduce/bugpoint) and me (to make it more readable). My assumption is that if LLVM accepts IR and generates an object file it shouldn't yield such a dwarfdump error, but are you thinking that given possibly valid LLVM IR the dwarfdump error is possible? If so that may make reduction far more difficult... Or do you think that this looks like upstream LLVM needs to get updated?
I don't think the editing of the IR caused the problem. I'll check later, but I think it's quite likely that the same problem occurs for the unedited IR. I don't know if the LLVM developers intend for this to be valid IR, or if they are missing a validation check somewhere. I think they may have never encountered this possibility. clang divides code into units based on files, so I don't think it ever splits code in the same scope across multiple units, whereas I think rust splits code into units quite differently. That's a bit of conjecture on my part though, it might be better to ask someone who knows more (I only know about DWARF, not LLVM or rustc). Reading the LLVM code a bit more, I think it will be possible to fix there by stopping it from sharing the scope (the scope creation is initiated and the sharing check is ). It's also worth reconsidering how rust splits code into units though.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: -C lto // no-prefer-dynamic // ignore-emscripten no threads support use std::thread; static mut HIT: usize = 0; thread_local!(static A: Foo = Foo); struct Foo; impl Drop for Foo { fn drop(&mut self) { unsafe { HIT += 1; } } } fn main() { unsafe { assert_eq!(HIT, 0); thread::spawn(|| { assert_eq!(HIT, 0); A.with(|_| ()); assert_eq!(HIT, 0); }).join().unwrap(); assert_eq!(HIT, 1); } } </ins>

It might make sense to ensure all code for a given type is kept in the same unit.
Ah ok that all makes sense. Note though that rustc is very much like clang when it comes to debuginfo/codegen units. The major difference here is that LLVM is doing inlining across codegen units via ThinLTO, and that's likely where these new situations are arising from.
I see, yep my understanding of how rust partitions units was wrong. So when using ThinLTO, the additional units by ThinLTO only contain information needed for the additional inlined functions? Do these inlined functions always share scopes/types with unit , or can we determine when they do? If so, it'd be nice to add them to unit instead of creating additonal units. I think this would get us DWARF that looks the same as that generated for . eg dwarfdump is happy if I run:
interesting! I'd have to look into the internals of ThinLTO to know for sure though. It seems like LLVM isn't ready (maybe?) for multiple codegen units in debug info in one LLVM module (a codegen unit), but it makes sense to me what you're thinking about having all inlined debug info share the same codegen unit information. Now where that change would go in LLVM I'm not entirely sure...
Does firefox use fat LTO? There's been a couple of bugs that have some similarities to this ( and maybe ). Also note that absence of dwarfdump errors doesn't mean the offsets are all okay. dwarfdump is only complaining if the offset is larger than the unit length, but even if it's less it may still incorrectly be a local ref. So there may be more instances that are unnoticed.
cc ^
I can reproduce using normal LTO. Library crate is: Binary crate is: Also here's a thin LTO version that gives smaller IR than the previous Vec test case:
Thanks It definitely sounds like at this point this is an existing bug we've just never hit before. My inclination would be to paper over this if we can. Unfortunately though I don't know how to fix this at the LLVM IR layer. My naive idea would be to just point everything at one codegen unit for each LLVM module (debug-info-wise) but I don't know how to change existing debuginfo of a module.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: -C lto // no-prefer-dynamic // ignore-emscripten no threads support use std::thread; static mut HIT: usize = 0; thread_local!(static A: Foo = Foo); struct Foo; impl Drop for Foo { fn drop(&mut self) { unsafe { HIT += 1; } } } fn main() { unsafe { assert_eq!(HIT, 0); thread::spawn(|| { assert_eq!(HIT, 0); A.with(|_| ()); assert_eq!(HIT, 0); }).join().unwrap(); assert_eq!(HIT, 1); } } </ins>

I'm not able to access currently, so not sure exactly what Adrian's suggestions were, but here's a that fixes LLVM to use a global ref when needed. It's not as simple as comparing parent DIEs, because the variable is initially , so the check . I don't have a lot of confidence in the patch, but maybe it's a useful starting point for someone who knows more about LLVM.
awesome thanks! I think LLVM's bugzilla is back now so indicating such.
I've confirmed that applying your patch to LLVM fixes having malformed debug information. Next up I'm confirming that it
Sure enough it fixes the issue! would you be interested in sending the patch upstream?
I prefer if someone who knows more about LLVM could upstream the patch.
Would this be something you could do, You can evaluate the changes to the generated DWARF best, I think.
We do use for Firefox builds, yes.
Sure, I will do this. I think the issue is more an LLVM thing than a DWARF thing, though; not certain I know enough there to say whether the patch is good, but I will at least do the shepherding. Also I wanted to point out that knows quite a bit about DWARF; he's one of the principals on
Actually maybe there's nothing to do here except merge this into rust-llvm?
Yes, I think so. I'll do that.
Cool, thanks!
oh no worries! I've tested it locally now and will submit a PR soon (with another change or two)
Ok, thanks
I've opened up which I think should close this out (and also re-enables ThinLTO in a few locations)
Hi, I get a Dwarf Error with GDB 8.0.1 on one of the files of Rust 1.23.0 that was built was Rust 1.23.0 on Fedora 27, in a build enabled with debuginfo. Is it related to this issue or should I open a new one? Relevant build flags:
yeah I believe that's this issue, it should be fixed in 1.24 though!


Question: drop(tx); thread.join().unwrap(); <ins> if !check { update_rustfmt_version(build); } </ins> }

Since rustfmt is deterministic and idempotent, running it twice on the same file should always have the same output (if it's not both of those things, it's a bug). So we can avoid running it unless the file has changed, which should make without arguments much faster. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This will need to be careful to still rerun rustfmt when we bump its version (which happens about every 6 weeks). Maybe we can generate a file and format everything if it doesn't yet exist or has the wrong version.
Hello, I want to work on that. How would the detection of modified files work ?
you can use to see modified files. Make sure to fall back to formatting all files if that command fails for some reason, we support building from source tarballs without git installed.
This means that already-commited files that were not formatted when committed would not be formatted, right ?
Ah, good point. You can use to find where the two diverged and compare all files since then. And should still look at all files unconditionally.
Thanks, I will start working on this ! claim
That assumes that the rust-lang remote is labeled as origin. I call that upstream and my fork origin. Using the local master may also not work if one does on branch.
Yes, has a more general solution.
PR is up at


Question: self.index = index; } <del> pub fn look_ahead(&self, n: usize) -> Option<&TokenTree> { self.stream.0[self.index..].get(n).map(|(tree, _)| tree) </del> <ins> pub fn look_ahead(&self, n: usize) -> Option<TokenTree> { self.stream.0[self.index..].get(n).map(|(tree, _)| tree.clone()) </ins> } }

Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the


Question: fn roundtrip(_1: *const u8) -> *const u8 { debug x => _1; let mut _0: *const u8; <del> let mut _2: *mut u8; let mut _3: *const u8; </del> <ins> let mut _2: *const u8; let mut _3: *mut u8; let mut _4: *const u8; </ins> bb0: { StorageLive(_2); StorageLive(_3); <del> _3 = _1; _2 = move _3 as *mut u8 (PtrToPtr); _0 = move _2 as *const u8 (PointerCoercion(MutToConstPointer)); </del> <ins> StorageLive(_4); _4 = _1; _3 = move _4 as *mut u8 (PtrToPtr); _2 = move _3 as *const u8 (PointerCoercion(MutToConstPointer)); StorageDead(_4); </ins> StorageDead(_3); <ins> -         _0 = move _2 as *const u8 (PtrToPtr); +         _0 = move _2; </ins> StorageDead(_2); return; }

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


Question: <ins> // compile-flags:--test // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // build-pass #![no_std] extern crate alloc; /// ``` /// assert!(true) /// ``` pub fn f() {} </ins>

I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.


Question: <ins> // compile-flags:--test // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // build-pass #![no_std] extern crate alloc; /// ``` /// assert!(true) /// ``` pub fn f() {} </ins>

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


Question: crate fn run( krate: clean::Crate, <del> renderopts: config::RenderOptions, </del> <ins> mut renderopts: config::RenderOptions, </ins> cache: formats::cache::Cache, tcx: TyCtxt<'_>, options: ScrapeExamplesOptions, ) -> interface::Result<()> { let inner = move || -> Result<(), String> { // Generates source files for examples <ins> renderopts.no_emit_shared = true; </ins> let (cx, _) = Context::init(krate, renderopts, cache, tcx).map_err(|e| e.to_string())?; // Collect CrateIds corresponding to provided target crates

<!-- 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 rendering docs for a crate with: That puts this in the sidebar: ! In this case, and are dependencies (which I don't want to document). And is the name of one of the examples, this is a dead link.
cc - running on dependencies seems like a cargo bug, but showing them in the sidebar seems like it's an issue in rustdoc.
Thanks for the report I will take a look this week.
Ok, I have fixed the issue where examples show up in the crates list. However, I wasn't able to reproduce the issue with non-examples appearing in the crates list. Specifically, my setup was: I could not get to appear in the sidebar when using .
Thanks I tried some more things, and I think what happened is that I used it without at first, and then without clearing the folder, did it with , which apparently doesn't remove the dependencies from the sidebar. So I guess that part of the issue is about not working quite right when these artefacts already exist, and unrelated to .


Question: impl<'tcx> FnCtxt<'_, 'tcx> { fn pattern_cause(&self, ti: TopInfo<'tcx>, cause_span: Span) -> ObligationCause<'tcx> { <del> let code = Pattern { span: ti.span, root_ty: ti.expected, origin_expr: ti.origin_expr }; </del> <ins> let code = Pattern { span: ti.span, root_ty: ti.expected, origin_expr: ti.origin_expr.is_some() }; </ins> self.cause(cause_span, code) }

<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest to the user that they need to initialize the enum variant's value in order to use the . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix


Question: #[allow(missing_docs)] pub mod color { /// Number for a terminal color <del> pub type Color = u16; </del> <ins> pub type Color = u32; </ins> pub const BLACK: Color = 0; pub const RED: Color = 1;

does not emit color output when running under a tmux session with set correctly to (supported by the latest versions of ncurses) even with when is set to . On the machine in question (macOS) the term file for is installed and returns the following: Per cargo should be invoking rustc with the flag, and indeed, returns 'Option color given more than once. Executing also does not produce color output, but does.
I have a similar bug on Archlinux. I used to get colored output on this system, but that recently stopped working for rustc. (Cargo is still fine for me.) If I add in and run in , I get Result::unwrap()Err/lib/terminfo/x/xterm-256colorncursesNEWS file does mention a new (incompatible) file format with a different magic number: Could rustc switch to whatever Cargo uses for colored terminal output?
A work-around for my machine was temporarily downgrading the packages, and copying the old file to .
Yes rustc should be able to switch at any time
Thanks for the workaround!
Changing from to also seems to work as a temporary workaround. (note: this may affect other terminal applications)
Another work-around if you're using sh: This sets to a possibly incorrect value, but limits its impact to only the output of a command.
That worked for me as well. I had no colour with . I downgraded to , which was what I had in , and now I have colour again.
I have a similar issue: In my regular terminal emulator (not tmux), there are no colors from rustc (as executed with ), colors from cargo itself are working fine. The default setting for there is: . The problem is fixed by setting to . Inside tmux however, colors work just fine, there seems to be by default.
Colors are fixed in the latest nightly (thanks to o/)
This is fixed for me in today’s nigthly, presumably by
With the current nightly I still have no colors with and have to use as a work around. What might still be broken?
Terminal colors are still broken with . however, does use colors, so there's clearly still a discrepancy between how and use termcolor
It works fine for me with ncurses 6.1, even rustup has colors again since the last version .


Question: #[allow(missing_docs)] pub mod color { /// Number for a terminal color <del> pub type Color = u16; </del> <ins> pub type Color = u32; </ins> pub const BLACK: Color = 0; pub const RED: Color = 1;

I’d like to note though that things like destroy this for some reason (even if is set). It took me some time to figure that out
I'm using ncurses 6.1 on Fedora 28 and everything appears to be working fine except for test colors. In mentioned that a bit tricky due to how the build works, but we can always tackle that later. What is the barrier to migrating libtest from to ? For now, it's leaving my test output looking like this. !
I have an in-progress patch for libtest but I ran into I'm guessing that's the build issue that is referring to. I don't know how linking libtest works, but I'm happy to try to fix the build if someone can point me in the right direction.


Question: && expected.iter().any(|tok| matches!(tok, TokenType::Token(TokenKind::Eq))) { // Likely typo: `=` → `==` in let expr or enum item <del> return Err(self.dcx().create_err(UseEqInstead { span: self.token.span, suggestion: self.token.span.with_lo(self.token.span.lo() + BytePos(1)), })); </del> <ins> return Err(self.dcx().create_err(UseEqInstead { span: self.token.span })); </ins> } if self.token.is_keyword(kw::Move) && self.prev_token.is_keyword(kw::Async) {

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: 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: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium


Question: <ins> error: unnamed fields are not allowed outside of structs or unions --> $DIR/anon-struct-in-enum-issue-121446.rs:7:9 | LL |         _ : struct { field: u8 }, |         -^^^^^^^^^^^^^^^^^^^^^^^ |         | |         unnamed field declared here error: anonymous structs are not allowed outside of unnamed struct or union fields --> $DIR/anon-struct-in-enum-issue-121446.rs:7:13 | LL |         _ : struct { field: u8 }, |             ^^^^^^^^^^^^^^^^^^^^ anonymous struct declared here error: aborting due to 2 previous errors </ins>

<!-- ICE: Rustc '' 'error: internal compiler error: expected ADT to be an item', 'error: internal compiler error: expected ADT to be an item' File: --snippet: 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: [adtdef] computing ADT definition for [adtdef] computing ADT definition for [typeof] computing type of [inferredoutlivescrate] computing the inferred outlives predicates for items in this crate [inferredoutlivesof] computing inferred outlives predicates of [predicatesdefinedon] computing predicates of [predicatesof] computing predicates of [collectmoditemtypes] collecting item types in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Oh, seems that more checks are needed to prevent unnamed fields from occurring in enums.
claim


Question: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. enum A { A { foo: usize, } } fn main() { let x = A::A { foo: 3 }; match x { A::A { fob } => { println!("{}", fob); } } } </ins>

With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .


Question: <ins> error[E0425]: cannot find value `e` in this scope --> $DIR/issue-114423.rs:7:51 | LL |     let (r, alone_in_path, b): (f32, f32, f32) = (e.clone(), e.clone()); |                                                   ^ not found in this scope error[E0425]: cannot find value `e` in this scope --> $DIR/issue-114423.rs:7:62 | LL |     let (r, alone_in_path, b): (f32, f32, f32) = (e.clone(), e.clone()); |                                                              ^ not found in this scope error[E0425]: cannot find value `g` in this scope --> $DIR/issue-114423.rs:11:22 | LL |     let _ = RGB { r, g, b }; |                      ^ help: a local variable with a similar name exists: `b` error[E0308]: mismatched types --> $DIR/issue-114423.rs:7:50 | LL |     let (r, alone_in_path, b): (f32, f32, f32) = (e.clone(), e.clone()); |                                ---------------   ^^^^^^^^^^^^^^^^^^^^^^ expected a tuple with 3 elements, found one with 2 elements |                                | |                                expected due to this | = note: expected tuple `(f32, f32, f32)` found tuple `(f32, f32)` error[E0560]: struct `RGB` has no field named `r` --> $DIR/issue-114423.rs:11:19 | LL |     let _ = RGB { r, g, b }; |                   ^ `RGB` does not have this field | = note: all struct fields are already assigned error[E0308]: mismatched types --> $DIR/issue-114423.rs:11:25 | LL |     let _ = RGB { r, g, b }; |                         ^ expected `f64`, found `f32` | help: you can convert an `f32` to an `f64` | LL |     let _ = RGB { r, g, b: b.into() }; |                         ++  +++++++ error: aborting due to 6 previous errors Some errors have detailed explanations: E0308, E0425, E0560. For more information about an error, try `rustc --explain E0308`. </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. --<!-- 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
Regression in
I think it's enough to change to be without .


Question: fn mir_const_qualif(&self, id: DefIndex) -> mir::ConstQualifs { match self.kind(id) { <del> EntryKind::Const(qualif, _) </del> <ins> EntryKind::AnonConst(qualif, _) | EntryKind::Const(qualif, _) </ins> | EntryKind::AssocConst( AssocContainer::ImplDefault | AssocContainer::ImplFinal

Currently with const generics you can create a "specialized" implementation, such as: Which has the following output: (playground link: ) However, when using such a type in another crate this causes a stack overflow in the compiler. For example, with the following code (full example: ): I would expect it to produce the same output as the playground link above, however it produces the following:
A bisect shows this stopped crashing after , marked as needing a test
I was still encountering this in my code with and after trying to minimize it seems that the original example is fixed but the stack overflow still occurs when the const expression in the has braces around it. After experimenting I found some more examples of what works and what doesn't: (see to try it) compiles and runs successfully while and (or ) crash the compiler with the same error as the original: :


Question: <ins> error: expected one of `,` or `>`, found `==` --> $DIR/issue-87493.rs:8:22 | LL |     T: MyTrait<Assoc == S::Assoc>, |                      ^^ expected one of `,` or `>` | help: if you meant to use an associated type binding, replace `==` with `=` | LL |     T: MyTrait<Assoc = S::Assoc>, |                      ~ error[E0107]: this trait takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-87493.rs:8:8 | LL |     T: MyTrait<Assoc == S::Assoc>, |        ^^^^^^^------------------- help: remove these generics |        | |        expected 0 generic arguments | note: trait defined here, with 0 generic parameters --> $DIR/issue-87493.rs:1:11 | LL | pub trait MyTrait { |           ^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0107`. </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: Playground: I expected to see this happen: The error message should indicate that the should be a single . Instead, this happened: The error message gives no hint of the correct syntax. It gives two errors, neither of which are helpful: This error is unhelpful because it says "expected one of or ", but is also allowed. Also, the suggestion to use curly braces is a red herring. This error is unhelpful because I am not specifying const arguments; I'm specifying associated types. Rust version according to 1.53.0
cc


Question: RUN /tmp/build-cloudabi-toolchain.sh x86_64-unknown-cloudabi COPY dist-various-2/build-fuchsia-toolchain.sh /tmp/ RUN /tmp/build-fuchsia-toolchain.sh <del> # FIXME(#61022) - reenable solaris # COPY dist-various-2/build-solaris-toolchain.sh /tmp/ # RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 # RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </del> <ins> COPY dist-various-2/build-solaris-toolchain.sh /tmp/ RUN /tmp/build-solaris-toolchain.sh x86_64  amd64   solaris-i386 RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc </ins> COPY dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ # We pass the commit id of the port of LLVM's libunwind to the build script. # Any update to the commit id here, should cause the container image to be re-built from this point on.

Today's nightly (25-05-2019) is missing rust-std for: : https://rust- : https://rust-
This was pointed out in and looks to be fixed in It seems that flew in under the radar of where the actual change to disable these targets happened. want to send a PR to revert the changes so the targets are built again?
Yes, I will do it today.


Question: pub struct DropLogger<'a, T> { extra: T, id: usize, <del> log: &'a panic::AssertUnwindSafe<RefCell<Vec<usize>>> </del> <ins> log: &'a panic::AssertUnwindSafe<RefCell<Vec<usize>>>, </ins> } impl<'a, T> Drop for DropLogger<'a, T> {

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: both compiles successfully Instead, this happened: fails to compile <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This may have something to do with , as there is something about let_chain drops here as well, but I don't for sure.
The same behaviour happens with an older compiler version. Here goes an example that compiles with . It is not up to me to decide if this behaviour is a blocker that will revert stabilization but in case of such event, I won't have enough free time to investigate and fix stuff in the near future.
Personally and despite the differences, I think that the version is "correct" and the nested version is surprisingly holding a reference of an owned structure () without an explicit bind.
drops the scrutinee after the statement.
cc who have been dealing with dropping stuff related to
Some things that might be helpful to know: The drop order changes for in also had borrow checker impact and made an example compile (see the PR's thread). I'm not a borrow checker expert, so I might be wrong, but this too might be fixed by drop order changes alone. In I'm studying drop order impacts of conditional statements, motivated by let else, but the test that PR adds also includes let chains. There I observed that let chains generally behave drop order wise like when there is a involved, and when it's a bool. I have only studied them regarding the body contained inside though. This table provides a summary of drop orders (disclaimer: it's outdated for let else):
I've locally amended of to add if let chains: And this is the output: Which actually runs counter to what I wrote above, because it predrops.


Question: pub struct DropLogger<'a, T> { extra: T, id: usize, <del> log: &'a panic::AssertUnwindSafe<RefCell<Vec<usize>>> </del> <ins> log: &'a panic::AssertUnwindSafe<RefCell<Vec<usize>>>, </ins> } impl<'a, T> Drop for DropLogger<'a, T> {

It seems that it depends on whether the in the chain is preceded by a or not: if you change the line with to , removing the , you get this: So that rule that I wrote above is not correct, but the underlying behaviour is more complicated. Hmmm...
Thanks
claim
pointed this out to me. It may be motivation to revert the stablization of let-chains on beta. Lets try to ensure we talk about this at Thursday triage label I-compiler-nominated
False alarm; pointed out to me that let-chains is already been marked unstable (on beta and nightly). label: -I-compiler-nominated


Question: } } <ins> pub fn rustc_lib_paths(&self, compiler: Compiler) -> Vec<PathBuf> { let mut dylib_dirs = vec![self.rustc_libdir(compiler)]; // Ensure that the downloaded LLVM libraries can be found. if self.config.llvm_from_ci { let ci_llvm_lib = self.out.join(&*compiler.host.triple).join("ci-llvm").join("lib"); dylib_dirs.push(ci_llvm_lib); } dylib_dirs } </ins> /// Adds the compiler's directory of dynamic libraries to `cmd`'s dynamic /// library lookup path. pub fn add_rustc_lib_path(&self, compiler: Compiler, cmd: &mut Command) {

Steps: Checkout commit Have in . In particular, this implies Run Output (on the second run):
cc
For what it’s worth is just what I happened to get after running today. I mentioned it in case something changes later, it’s a coincidence that that commit happens to be related to downloading LLVM from Rust CI.
I think this is a duplicate of
That issue is closed, and its final comment points to this issue.
I just hit this on the following sequence. Do a fresh clone of Run Select option (b) "compiler: Contribute to the compiler itself" Run The build finished like so:
IMO the proper fix for this is to remove error-index's dependency on rustdoc, either by moving the relevant code out into a library that doesn't use rustc_private, or by duplicating the code altogether. There are other ways to solve this but they'll be more complicated and take longer to compile for no real benefit.
by making it invoke rustdoc-the-binary (through ), rather than using rustdoc-the-library.
you should be able to work around this by adding --stage 2 I think.
Thanks, that worked
I think you're right that the binary will be easier - parsing the markdown requires parsing doctests so that it can generate the "Run" button, and parsing doctests requires all of .


Question: <ins> error[E0408]: variable `v` is not bound in all patterns --> $DIR/tabs-trimming.rs:9:16 | LL | ...   v @ 1 | 2 | 3 => panic!("You gave me too little money {}", v), // Long text here: TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT... |       -       ^   ^ pattern doesn't bind `v` |       |       | |       |       pattern doesn't bind `v` |       variable not in all patterns error: aborting due to previous error For more information about this error, try `rustc --explain E0408`. </ins>

The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim


Question: StatementKind::PlaceMention(place) => { self.visit_place( place, <del> PlaceContext::NonUse(NonUseContext::PlaceMention), </del> <ins> PlaceContext::NonMutatingUse(NonMutatingUseContext::PlaceMention), </ins> location ); }

<!-- 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: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy


Question: } }; <del> if self.suggest_constraining_numerical_ty( </del> <ins> if self.suggest_wrapping_range_with_parens( tcx, actual, source, span, item_name, &ty_str, ) || self.suggest_constraining_numerical_ty( </ins> tcx, actual, source, span, item_kind, item_name, &ty_str, ) { return None;

<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should something like this: label +D-confusing +D-invalid-suggestion <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: <ins> //@ aux-build:issue-76736-1.rs //@ aux-build:issue-76736-2.rs // https://github.com/rust-lang/rust/issues/124635 #![crate_name = "foo"] #![feature(rustc_private, staged_api)] #![unstable(feature = "rustc_private", issue = "none")] extern crate issue_76736_1; extern crate issue_76736_2; // @has foo/struct.Foo.html // @has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' pub struct Foo; // @has foo/struct.Bar.html // @has - '//*[@class="impl"]//h3[@class="code-header"]' 'MaybeResult' pub use issue_76736_2::Bar; </ins>

for example lists implementations of in , which aren't visible anyway and the links are also broken.
Not present in the docs for 1.77.2, regression?
cc getting multiple reports of this:
I believe this regressed in (
This was closed but it's still happening on current stable docs, in various traits, Debug being the one that seems the worst: ! !
What page are you looking at? I do not see those implementations on
stable docs, not nightly I understand this was reported the day 1.78.0 was released and 1.79.0 isn't due for a few weeks more, but I feel it should be possible to apply the fix to the current stable docs at least as published on rust- in the meantime
The stable docs are tied to the release, so we would have to make a new release to update them. The fix for this is in 1.80, and will reach stable on July 25.
There's no way to backport it internally? That's unfortunate. I was hoping it would land for 1.79.0 at least
Closing then.
This can in fact be beta backported.
And it was in
Good to know, thank you


Question: generics_of => { table } inferred_outlives_of => { table_defaulted_array } super_predicates_of => { table } <ins> implied_predicates_of => { table } </ins> type_of => { table } type_alias_is_lazy => { cdata.root.tables.type_alias_is_lazy.get(cdata, def_id.index) } variances_of => { table }

<!-- 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: This compiles fine, however if crateb is a separate crate instead of a local module_, it errors with: This is not fixed by the next solver (). <!-- 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. --:
I was able to narrow this down even further:
yep yep makes sense i'll fix it, sorry


Question: if sess.opts.incremental.is_none() { return; } <ins> // This is going to be deleted in finalize_session_directory, so let's not create it if sess.has_errors_or_delayed_span_bugs() { return; } </ins> debug!("save_work_product_index()"); dep_graph.assert_ignored();

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


Question: Some(hir::CoroutineKind::Coroutine(_)) | Some(hir::CoroutineKind::Desugared(hir::CoroutineDesugaring::Gen, _)) | None => { <del> return hir::ExprKind::Err(self.dcx().emit_err(AwaitOnlyInAsyncFnAndBlocks { await_kw_span, item_span: self.current_item, })); </del> <ins> // Lower to a block `{ EXPR; <error> }` so that the awaited expr // is not accidentally orphaned. let stmt_id = self.next_id(); let expr_err = self.expr( expr.span, hir::ExprKind::Err(self.dcx().emit_err(AwaitOnlyInAsyncFnAndBlocks { await_kw_span, item_span: self.current_item, })), ); return hir::ExprKind::Block( self.block_all( expr.span, arena_vec![self; hir::Stmt { hir_id: stmt_id, kind: hir::StmtKind::Semi(expr), span: expr.span, }], Some(self.arena.alloc(expr_err)), ), None, ); </ins> } };

<!-- ICE: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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: [hirownerparent] getting HIR parent of [checkunused_traits] checking unused trait imports in crate [analysis] running analysis passes on this crate --
cc
Minimal:


Question: extern crate lint_unused_extern_crate as other; // no error, the use * marks it as used <ins> #[macro_use] extern crate core; // no error, the `#[macro_use]` marks it as used </ins> #[allow(unused_imports)] use rand::isaac::IsaacRng;

When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .