Question:
This could've been written with written as and similarly for /. It was written this way only to make explicit the necessity of one blanket impl for satisfying the other. I'm guessing that extensional equality is not judged, even though it is possible to make such a judgment and such a judgment must be made to compile code that compiles today. on line 12 ought to be equated to (which must be detected at some other point in time else line 13 wouldn't be able to compile). EDIT: Playing around a bit, it looks more and more like it's all about the HKL bounds...
HRTBs (I've been using the wrong nomenclature the whole time!) make projections sad. Very likely a dupe of .
cc
Known issue.
(or Still a bit unclear on y'all's role separation) What's the expected overall approach to fixing this issue? Even if you don't expect a newcomer to handle it, I'd like to know anyway. :-D
actually, I'm not entirely sure. There are a serious of refactorings that I have in mind for the type system / trait resolver, and I've been figuring that after those are done, I would come back to revisit some of these issues, if they still occur, but it may be worth digging into this example (or ) in detail. Honestly it's not all fresh in my mind. The refactorings I am thinking of are, first, lazy normalization (as described ), which may indeed help here, though I've not thought it through very deeply. Second, I'd like to generally rework how the trait checker is working to make it easier to extend the environment as you go -- the current setup, where the set of assumptions etc is semi-fixed when the inference context is created -- makes it hard to "descend through" a binder like and then do trait resolutions and normalizations within that context.
So, potentially w.r.t. lazy normalization, I've been playing with another bit of code (trying to shrink it a bit): From reading the debug logs, it seems that when checking the well-formed-ness of , upon normalizing to , and registering and ing on the implied , the compiler has no idea that and never normalizes to it either. Is this a situation in which the compiler might have assumed that everything was already normalized the best it could be and thus gave up? An aside: does lazy normalization have something to do with ?
Is this It looks similar, but uncertain.
What's the state of this now? I fairly frequently run into problems with associated types involved with HRTBs not projecting/unifying.
Triage: last two comments asking for clarification, no replies. Given comments earlier in the thread, I imagine this issue is "post-chalk".
This is one of the things that the traits working group is kind of actively working towards. It's blocked to some extent on the universes work, see e.g. which tries to unblock that effort, plus lazy norm. I think we'll be making active progress though over the next few months.
Triage: According to , this should get tagged .
I think this issue is related to an error I encountered when trying to use the trait example . The trait is defined as follow: I implemented it for a vector of booleans: I believe this should compile, but it errors. <details<summarySee full error</summary</detailsIt does not recognize that and are the same.
You example compiles now.
Triage: The original issue seems to have been fixed, the example from the issue description compiles just fine now.

<ins> //! If `-o -` or `--emit KIND=-` is provided, output should be written to stdout //! instead. Binary output (`obj`, `llvm-bc`, `link` and `metadata`) //! being written this way will result in an error if stdout is a tty. //! Multiple output types going to stdout will trigger an error too, //! as they would all be mixed together. //! //! See <https://github.com/rust-lang/rust/pull/111626>. use std::fs::File; use run_make_support::{diff, run_in_tmpdir, rustc}; // Test emitting text outputs to stdout works correctly fn run_diff(name: &str, file_args: &[&str]) { rustc().emit(format!("{name}={name}")).input("test.rs").args(file_args).run(); let out = rustc().emit(format!("{name}=-")).input("test.rs").run().stdout_utf8(); diff().expected_file(name).actual_text("stdout", &out).run(); } // Test that emitting binary formats to a terminal gives the correct error fn run_terminal_err_diff(name: &str) { #[cfg(not(windows))] let terminal = File::create("/dev/ptmx").unwrap(); // FIXME: If this test fails and the compiler does print to the console, // then this will produce a lot of output. // We should spawn a new console instead to print stdout. #[cfg(windows)] let terminal = File::options().read(true).write(true).open(r".CONOUT$").unwrap(); let err = File::create(name).unwrap(); rustc().emit(format!("{name}=-")).input("test.rs").stdout(terminal).stderr(err).run_fail(); diff().expected_file(format!("emit-{name}.stderr")).actual_file(name).run(); } fn main() { run_in_tmpdir(|| { run_diff("asm", &[]); run_diff("llvm-ir", &[]); run_diff("dep-info", &["-Zdep-info-omit-d-target=yes"]); run_diff("mir", &[]); run_terminal_err_diff("llvm-bc"); run_terminal_err_diff("obj"); run_terminal_err_diff("metadata"); run_terminal_err_diff("link"); // Test error for emitting multiple types to stdout rustc() .input("test.rs") .emit("asm=-") .emit("llvm-ir=-") .emit("dep-info=-") .emit("mir=-") .stderr(File::create("multiple-types").unwrap()) .run_fail(); diff().expected_file("emit-multiple-types.stderr").actual_file("multiple-types").run(); // Same as above, but using `-o` rustc() .input("test.rs") .output("-") .emit("asm,llvm-ir,dep-info,mir") .stderr(File::create("multiple-types-option-o").unwrap()) .run_fail(); diff() .expected_file("emit-multiple-types.stderr") .actual_file("multiple-types-option-o") .run(); // Test that `-o -` redirected to a file works correctly (#26719) rustc().input("test.rs").output("-").stdout(File::create("out-stdout").unwrap()).run(); }); } </ins>


Question:
This could've been written with written as and similarly for /. It was written this way only to make explicit the necessity of one blanket impl for satisfying the other. I'm guessing that extensional equality is not judged, even though it is possible to make such a judgment and such a judgment must be made to compile code that compiles today. on line 12 ought to be equated to (which must be detected at some other point in time else line 13 wouldn't be able to compile). EDIT: Playing around a bit, it looks more and more like it's all about the HKL bounds...
HRTBs (I've been using the wrong nomenclature the whole time!) make projections sad. Very likely a dupe of .
cc
Known issue.
(or Still a bit unclear on y'all's role separation) What's the expected overall approach to fixing this issue? Even if you don't expect a newcomer to handle it, I'd like to know anyway. :-D
actually, I'm not entirely sure. There are a serious of refactorings that I have in mind for the type system / trait resolver, and I've been figuring that after those are done, I would come back to revisit some of these issues, if they still occur, but it may be worth digging into this example (or ) in detail. Honestly it's not all fresh in my mind. The refactorings I am thinking of are, first, lazy normalization (as described ), which may indeed help here, though I've not thought it through very deeply. Second, I'd like to generally rework how the trait checker is working to make it easier to extend the environment as you go -- the current setup, where the set of assumptions etc is semi-fixed when the inference context is created -- makes it hard to "descend through" a binder like and then do trait resolutions and normalizations within that context.
So, potentially w.r.t. lazy normalization, I've been playing with another bit of code (trying to shrink it a bit): From reading the debug logs, it seems that when checking the well-formed-ness of , upon normalizing to , and registering and ing on the implied , the compiler has no idea that and never normalizes to it either. Is this a situation in which the compiler might have assumed that everything was already normalized the best it could be and thus gave up? An aside: does lazy normalization have something to do with ?
Is this It looks similar, but uncertain.
What's the state of this now? I fairly frequently run into problems with associated types involved with HRTBs not projecting/unifying.
Triage: last two comments asking for clarification, no replies. Given comments earlier in the thread, I imagine this issue is "post-chalk".
This is one of the things that the traits working group is kind of actively working towards. It's blocked to some extent on the universes work, see e.g. which tries to unblock that effort, plus lazy norm. I think we'll be making active progress though over the next few months.
Triage: According to , this should get tagged .
I think this issue is related to an error I encountered when trying to use the trait example . The trait is defined as follow: I implemented it for a vector of booleans: I believe this should compile, but it errors. <details<summarySee full error</summary</detailsIt does not recognize that and are the same.
You example compiles now.
Triage: The original issue seems to have been fixed, the example from the issue description compiles just fine now.

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


Question:
This could've been written with written as and similarly for /. It was written this way only to make explicit the necessity of one blanket impl for satisfying the other. I'm guessing that extensional equality is not judged, even though it is possible to make such a judgment and such a judgment must be made to compile code that compiles today. on line 12 ought to be equated to (which must be detected at some other point in time else line 13 wouldn't be able to compile). EDIT: Playing around a bit, it looks more and more like it's all about the HKL bounds...
HRTBs (I've been using the wrong nomenclature the whole time!) make projections sad. Very likely a dupe of .
cc
Known issue.
(or Still a bit unclear on y'all's role separation) What's the expected overall approach to fixing this issue? Even if you don't expect a newcomer to handle it, I'd like to know anyway. :-D
actually, I'm not entirely sure. There are a serious of refactorings that I have in mind for the type system / trait resolver, and I've been figuring that after those are done, I would come back to revisit some of these issues, if they still occur, but it may be worth digging into this example (or ) in detail. Honestly it's not all fresh in my mind. The refactorings I am thinking of are, first, lazy normalization (as described ), which may indeed help here, though I've not thought it through very deeply. Second, I'd like to generally rework how the trait checker is working to make it easier to extend the environment as you go -- the current setup, where the set of assumptions etc is semi-fixed when the inference context is created -- makes it hard to "descend through" a binder like and then do trait resolutions and normalizations within that context.
So, potentially w.r.t. lazy normalization, I've been playing with another bit of code (trying to shrink it a bit): From reading the debug logs, it seems that when checking the well-formed-ness of , upon normalizing to , and registering and ing on the implied , the compiler has no idea that and never normalizes to it either. Is this a situation in which the compiler might have assumed that everything was already normalized the best it could be and thus gave up? An aside: does lazy normalization have something to do with ?
Is this It looks similar, but uncertain.
What's the state of this now? I fairly frequently run into problems with associated types involved with HRTBs not projecting/unifying.
Triage: last two comments asking for clarification, no replies. Given comments earlier in the thread, I imagine this issue is "post-chalk".
This is one of the things that the traits working group is kind of actively working towards. It's blocked to some extent on the universes work, see e.g. which tries to unblock that effort, plus lazy norm. I think we'll be making active progress though over the next few months.
Triage: According to , this should get tagged .
I think this issue is related to an error I encountered when trying to use the trait example . The trait is defined as follow: I implemented it for a vector of booleans: I believe this should compile, but it errors. <details<summarySee full error</summary</detailsIt does not recognize that and are the same.
You example compiles now.
Triage: The original issue seems to have been fixed, the example from the issue description compiles just fine now.

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


Question:
This could've been written with written as and similarly for /. It was written this way only to make explicit the necessity of one blanket impl for satisfying the other. I'm guessing that extensional equality is not judged, even though it is possible to make such a judgment and such a judgment must be made to compile code that compiles today. on line 12 ought to be equated to (which must be detected at some other point in time else line 13 wouldn't be able to compile). EDIT: Playing around a bit, it looks more and more like it's all about the HKL bounds...
HRTBs (I've been using the wrong nomenclature the whole time!) make projections sad. Very likely a dupe of .
cc
Known issue.
(or Still a bit unclear on y'all's role separation) What's the expected overall approach to fixing this issue? Even if you don't expect a newcomer to handle it, I'd like to know anyway. :-D
actually, I'm not entirely sure. There are a serious of refactorings that I have in mind for the type system / trait resolver, and I've been figuring that after those are done, I would come back to revisit some of these issues, if they still occur, but it may be worth digging into this example (or ) in detail. Honestly it's not all fresh in my mind. The refactorings I am thinking of are, first, lazy normalization (as described ), which may indeed help here, though I've not thought it through very deeply. Second, I'd like to generally rework how the trait checker is working to make it easier to extend the environment as you go -- the current setup, where the set of assumptions etc is semi-fixed when the inference context is created -- makes it hard to "descend through" a binder like and then do trait resolutions and normalizations within that context.
So, potentially w.r.t. lazy normalization, I've been playing with another bit of code (trying to shrink it a bit): From reading the debug logs, it seems that when checking the well-formed-ness of , upon normalizing to , and registering and ing on the implied , the compiler has no idea that and never normalizes to it either. Is this a situation in which the compiler might have assumed that everything was already normalized the best it could be and thus gave up? An aside: does lazy normalization have something to do with ?
Is this It looks similar, but uncertain.
What's the state of this now? I fairly frequently run into problems with associated types involved with HRTBs not projecting/unifying.
Triage: last two comments asking for clarification, no replies. Given comments earlier in the thread, I imagine this issue is "post-chalk".
This is one of the things that the traits working group is kind of actively working towards. It's blocked to some extent on the universes work, see e.g. which tries to unblock that effort, plus lazy norm. I think we'll be making active progress though over the next few months.
Triage: According to , this should get tagged .
I think this issue is related to an error I encountered when trying to use the trait example . The trait is defined as follow: I implemented it for a vector of booleans: I believe this should compile, but it errors. <details<summarySee full error</summary</detailsIt does not recognize that and are the same.
You example compiles now.
Triage: The original issue seems to have been fixed, the example from the issue description compiles just fine now.

<ins> //@ check-pass //! Tests that associated type projections normalize properly in the presence of HRTBs. //! Original issue: <https://github.com/rust-lang/rust/issues/30472> pub trait MyFrom<T> {} impl<T> MyFrom<T> for T {} pub trait MyInto<T> {} impl<T, U> MyInto<U> for T where U: MyFrom<T> {} pub trait A<'self_> { type T; } pub trait B: for<'self_> A<'self_> { // Originally caused the `type U = usize` example below to fail with a type mismatch error type U: for<'self_> MyFrom<<Self as A<'self_>>::T>; } pub struct M; impl<'self_> A<'self_> for M { type T = usize; } impl B for M { type U = usize; } fn main() {} </ins>


Question:
This could've been written with written as and similarly for /. It was written this way only to make explicit the necessity of one blanket impl for satisfying the other. I'm guessing that extensional equality is not judged, even though it is possible to make such a judgment and such a judgment must be made to compile code that compiles today. on line 12 ought to be equated to (which must be detected at some other point in time else line 13 wouldn't be able to compile). EDIT: Playing around a bit, it looks more and more like it's all about the HKL bounds...
HRTBs (I've been using the wrong nomenclature the whole time!) make projections sad. Very likely a dupe of .
cc
Known issue.
(or Still a bit unclear on y'all's role separation) What's the expected overall approach to fixing this issue? Even if you don't expect a newcomer to handle it, I'd like to know anyway. :-D
actually, I'm not entirely sure. There are a serious of refactorings that I have in mind for the type system / trait resolver, and I've been figuring that after those are done, I would come back to revisit some of these issues, if they still occur, but it may be worth digging into this example (or ) in detail. Honestly it's not all fresh in my mind. The refactorings I am thinking of are, first, lazy normalization (as described ), which may indeed help here, though I've not thought it through very deeply. Second, I'd like to generally rework how the trait checker is working to make it easier to extend the environment as you go -- the current setup, where the set of assumptions etc is semi-fixed when the inference context is created -- makes it hard to "descend through" a binder like and then do trait resolutions and normalizations within that context.
So, potentially w.r.t. lazy normalization, I've been playing with another bit of code (trying to shrink it a bit): From reading the debug logs, it seems that when checking the well-formed-ness of , upon normalizing to , and registering and ing on the implied , the compiler has no idea that and never normalizes to it either. Is this a situation in which the compiler might have assumed that everything was already normalized the best it could be and thus gave up? An aside: does lazy normalization have something to do with ?
Is this It looks similar, but uncertain.
What's the state of this now? I fairly frequently run into problems with associated types involved with HRTBs not projecting/unifying.
Triage: last two comments asking for clarification, no replies. Given comments earlier in the thread, I imagine this issue is "post-chalk".
This is one of the things that the traits working group is kind of actively working towards. It's blocked to some extent on the universes work, see e.g. which tries to unblock that effort, plus lazy norm. I think we'll be making active progress though over the next few months.
Triage: According to , this should get tagged .
I think this issue is related to an error I encountered when trying to use the trait example . The trait is defined as follow: I implemented it for a vector of booleans: I believe this should compile, but it errors. <details<summarySee full error</summary</detailsIt does not recognize that and are the same.
You example compiles now.
Triage: The original issue seems to have been fixed, the example from the issue description compiles just fine now.

<ins> //@ check-pass //! Tests that a HRTB + FnOnce bound involving an associated type don't prevent //! a function pointer from implementing `Fn` traits. //! Test for <https://github.com/rust-lang/rust/issues/28994> trait LifetimeToType<'a> { type Out; } impl<'a> LifetimeToType<'a> for () { type Out = &'a (); } fn id<'a>(val: &'a ()) -> <() as LifetimeToType<'a>>::Out { val } fn assert_fn<F: for<'a> FnOnce(&'a ()) -> <() as LifetimeToType<'a>>::Out>(_func: F) { } fn main() { assert_fn(id); } </ins>


Question:
This could've been written with written as and similarly for /. It was written this way only to make explicit the necessity of one blanket impl for satisfying the other. I'm guessing that extensional equality is not judged, even though it is possible to make such a judgment and such a judgment must be made to compile code that compiles today. on line 12 ought to be equated to (which must be detected at some other point in time else line 13 wouldn't be able to compile). EDIT: Playing around a bit, it looks more and more like it's all about the HKL bounds...
HRTBs (I've been using the wrong nomenclature the whole time!) make projections sad. Very likely a dupe of .
cc
Known issue.
(or Still a bit unclear on y'all's role separation) What's the expected overall approach to fixing this issue? Even if you don't expect a newcomer to handle it, I'd like to know anyway. :-D
actually, I'm not entirely sure. There are a serious of refactorings that I have in mind for the type system / trait resolver, and I've been figuring that after those are done, I would come back to revisit some of these issues, if they still occur, but it may be worth digging into this example (or ) in detail. Honestly it's not all fresh in my mind. The refactorings I am thinking of are, first, lazy normalization (as described ), which may indeed help here, though I've not thought it through very deeply. Second, I'd like to generally rework how the trait checker is working to make it easier to extend the environment as you go -- the current setup, where the set of assumptions etc is semi-fixed when the inference context is created -- makes it hard to "descend through" a binder like and then do trait resolutions and normalizations within that context.
So, potentially w.r.t. lazy normalization, I've been playing with another bit of code (trying to shrink it a bit): From reading the debug logs, it seems that when checking the well-formed-ness of , upon normalizing to , and registering and ing on the implied , the compiler has no idea that and never normalizes to it either. Is this a situation in which the compiler might have assumed that everything was already normalized the best it could be and thus gave up? An aside: does lazy normalization have something to do with ?
Is this It looks similar, but uncertain.
What's the state of this now? I fairly frequently run into problems with associated types involved with HRTBs not projecting/unifying.
Triage: last two comments asking for clarification, no replies. Given comments earlier in the thread, I imagine this issue is "post-chalk".
This is one of the things that the traits working group is kind of actively working towards. It's blocked to some extent on the universes work, see e.g. which tries to unblock that effort, plus lazy norm. I think we'll be making active progress though over the next few months.
Triage: According to , this should get tagged .
I think this issue is related to an error I encountered when trying to use the trait example . The trait is defined as follow: I implemented it for a vector of booleans: I believe this should compile, but it errors. <details<summarySee full error</summary</detailsIt does not recognize that and are the same.
You example compiles now.
Triage: The original issue seems to have been fixed, the example from the issue description compiles just fine now.

<ins> //@ check-pass //! Tests that HRTB impl selection covers type parameters not directly related //! to the trait. //! Test for <https://github.com/rust-lang/rust/issues/30867> #![crate_type = "lib"] trait Unary<T> {} impl<T, U, F: Fn(T) -> U> Unary<T> for F {} fn unary<F: for<'a> Unary<&'a T>, T>() {} pub fn test<F: for<'a> Fn(&'a i32) -> &'a i32>() { unary::<F, i32>() } </ins>


Question:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

// These items live in the type namespace. ItemTy(..) => { <del> let parent_link = ModuleParentLink(parent, name); </del> let def = Def::TyAlias(self.ast_map.local_def_id(item.id)); <del> let module = self.new_module(parent_link, Some(def), false, is_public); self.define(parent, name, TypeNS, (module, sp)); </del> <ins> self.define(parent, name, TypeNS, (def, sp, modifiers)); </ins> parent }


Question:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

} match def { <del> Def::Mod(_) | Def::ForeignMod(_) | Def::Enum(..) | Def::TyAlias(..) => { </del> <ins> Def::Mod(_) | Def::ForeignMod(_) | Def::Enum(..) => { </ins> debug!("(building reduced graph for external crate) building module {} {}", final_ident, is_public);


Question:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

let module = self.new_module(parent_link, Some(def), true, is_public); self.try_define(new_parent, name, TypeNS, (module, DUMMY_SP)); } <del> Def::AssociatedTy(..) => { </del> <ins> Def::TyAlias(..) | Def::AssociatedTy(..) => { </ins> debug!("(building reduced graph for external crate) building type {}", final_ident); self.try_define(new_parent, name, TypeNS, (def, DUMMY_SP, modifiers));


Question:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

target_module: Module<'b>, directive: &'b ImportDirective) -> ResolveResult<()> { <ins> if let Some(Def::Trait(_)) = target_module.def { self.resolver.session.span_err(directive.span, "items in traits are not importable."); } </ins> if module_.def_id() == target_module.def_id() { // This means we are trying to glob import a module into itself, and it is a no-go let msg = "Cannot glob-import a module into itself.".into();


Question:
Code that compiles fine with rustc is causing an internal compiler error: unexpected panic with rustdoc. I tried this code (): The second line is essentially a typo, which can happen if used to be an Enum for instance. Again, the following works fine (although I'm not sure why, can you even add anything to the namespace?): However, if I run: I get the error: This actually happened on a version of a package already pushed to (hdf5-sys 0.3.0), so anything that depends on the erroneous version and runs will see this error. Run on . Backtrace:
This is easy to fix in rustdoc, but should this even compile?
Whoa kinda crazy... cc (resolve weridness, longstanding though!)

<ins> // Copyright 2016 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. type Alias = (); use Alias::*; //~ ERROR Not a module use std::io::Result::*; //~ ERROR Not a module trait T {} use T::*; //~ ERROR items in traits are not importable fn main() {} </ins>


Question: For example, that the struct being dropped has not been deallocated when is called (it's implied by the existence of and Rust's general reluctance to dangle pointers, but still...), and that the struct members are recursively dropped after finishes, and what happens if panics.

#[stable(feature = "rust1", since = "1.0.0")] pub trait Drop { /// A method called when the value goes out of scope. <ins> /// /// When this method has been called, `self` has not yet been deallocated. /// If it were, `self` would be a dangling reference. /// /// After this function is over, the memory of `self` will be deallocated. /// /// # Panics /// /// Given that a `panic!` will call `drop()` as it unwinds, any `panic!` in /// a `drop()` implementation will likely abort. </ins> #[stable(feature = "rust1", since = "1.0.0")] fn drop(&mut self); }


Question:
It would be nice, if the would mention that the process is detached (and not joined) by default, when a object goes out of scope. Not having a impl is too subtile IMO.
Part of
I'd be happy to take this on. :smile:
Please do! :) On Jan 30, 2016, 11:59 -0500, Dirk , wrote:

/// /// assert!(ecode.success()); /// ``` <ins> /// /// # Note /// /// Take note that there is no implementation of /// [`Drop`](../../core/ops/trait.Drop.html) for child processes, so if you /// do not ensure the `Child` has exited then it will continue to run, even /// after the `Child` handle to the child process has gone out of scope. /// /// Calling `wait` (or other functions that wrap around it) will make the /// parent process wait until the child has actually exited before continuing. </ins> #[stable(feature = "process", since = "1.0.0")] pub struct Child { handle: imp::Process,


Question:
Exemple code: Error is: The compiler should detect that "self" is missing. Note this is an error I do all the time as a beginner.
Even without doing an analysis of what could have likely been intended this error message could mention that paths in are absolute by default, unless they start with or .
Ran into this a few days ago, would love to the messaging here improved :+1:
The linked PR adds the information to the long diagnostics, at least. Note that if you just have an then the error message is markedly different: I wonder if some consolidation would be in order.
Fixed in .

use something::Foo; // error: unresolved import `something::Foo`. ``` <del> Please verify you didn't misspell the import name or the import does exist in the module from where you tried to import it. Example: </del> <ins> Paths in `use` statements are relative to the crate root. To import items relative to the current and parent modules, use the `self::` and `super::` prefixes, respectively. Also verify that you didn't misspell the import name and that the import exists in the module from where you tried to import it. Example: </ins> ```ignore <del> use something::Foo; // ok! </del> <ins> use self::something::Foo; // ok! </ins> mod something { pub struct Foo;


Question:
Exemple code: Error is: The compiler should detect that "self" is missing. Note this is an error I do all the time as a beginner.
Even without doing an analysis of what could have likely been intended this error message could mention that paths in are absolute by default, unless they start with or .
Ran into this a few days ago, would love to the messaging here improved :+1:
The linked PR adds the information to the long diagnostics, at least. Note that if you just have an then the error message is markedly different: I wonder if some consolidation would be in order.
Fixed in .

``` Or, if you tried to use a module from an external crate, you may have missed <del> the `extern crate` declaration: </del> <ins> the `extern crate` declaration (which is usually placed in the crate root): </ins> ```ignore extern crate homura; // Required to use the `homura` crate


Question: rustdoc source links end in as can be seen here at the moment (the [src] link) Source link is: (Which is a dead link) Also reproduced locally using rustc 1.9.0-nightly ( 2016-03-07)

// has anchors for the line numbers that we're linking to. } else if self.item.def_id.is_local() { self.cx.local_sources.get(&PathBuf::from(&self.item.source.filename)).map(|path| { <del> format!("{root}src/{krate}/{path}.html#{href}", </del> <ins> format!("{root}src/{krate}/{path}#{href}", </ins> root = self.cx.root_path, krate = self.cx.layout.krate, path = path,


Question:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

} } <ins> fn increment_outstanding_references(&mut self, is_public: bool) { self.outstanding_references += 1; if is_public { self.pub_outstanding_references += 1; } } fn decrement_outstanding_references(&mut self, is_public: bool) { let decrement_references = |count: &mut _| { assert!(*count > 0); *count -= 1; }; decrement_references(&mut self.outstanding_references); if is_public { decrement_references(&mut self.pub_outstanding_references); } } </ins> fn report_conflicts<F: FnMut(&NameBinding, &NameBinding)>(&self, mut report: F) { let binding = match self.binding { Some(binding) => binding,


Question:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

} pub fn increment_outstanding_references_for(&self, name: Name, ns: Namespace, is_public: bool) { <del> let mut resolutions = self.resolutions.borrow_mut(); let resolution = resolutions.entry((name, ns)).or_insert_with(Default::default); resolution.outstanding_references += 1; if is_public { resolution.pub_outstanding_references += 1; } } fn decrement_outstanding_references_for(&self, name: Name, ns: Namespace, is_public: bool) { let decrement_references = |count: &mut _| { assert!(*count > 0); *count -= 1; }; self.update_resolution(name, ns, |resolution| { decrement_references(&mut resolution.outstanding_references); if is_public { decrement_references(&mut resolution.pub_outstanding_references); } }) </del> <ins> self.resolutions.borrow_mut().entry((name, ns)).or_insert_with(Default::default) .increment_outstanding_references(is_public); </ins> } // Use `update` to mutate the resolution for the name.


Question:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

// Temporarily count the directive as determined so that the resolution fails // (as opposed to being indeterminate) when it can only be defined by the directive. if !determined { <del> module_.decrement_outstanding_references_for(target, ns, directive.is_public) </del> <ins> module_.resolutions.borrow_mut().get_mut(&(target, ns)).unwrap() .decrement_outstanding_references(directive.is_public); </ins> } let result = self.resolver.resolve_name_in_module(target_module, source, ns, false, true);


Question:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

self.report_conflict(target, ns, &directive.import(binding, None), old_binding); } } <del> module_.decrement_outstanding_references_for(target, ns, directive.is_public); </del> <ins> module_.update_resolution(target, ns, |resolution| { resolution.decrement_outstanding_references(directive.is_public); }) </ins> } match (&value_result, &type_result) {


Question:
Unfortunately, I can't reproduce this at a smaller scale. This issue occurs with as of commit . Rust version is Currently the tests (run from the directory with ) pass. However, applying the following patch: causes the following compiler error: which is claiming that an import conflicts with itself. I have pushed up the branch with that change applied for easy reproduction. Again, I'm sorry that I cannot provide a report on a smaller scale, but this appears to be some edge case blowing up. I have no clue why adding a module with a few imports and nothing else would be causing this issue.
Bisecting to find the nightly which caused this
I can confirm that this issue does not occur on . Unfortunately, there was a bug that prevented us from compiling on that wasn't fixed until , so I cannot provide anything more specific than that.
cc
Thanks for the report! This bug was introduced in . I diagnosed the issue and will fix it ASAP.

<ins> // Copyright 2016 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. #![feature(rustc_attrs)] #![allow(warnings)] mod foo { pub fn bar() {} } pub use foo::*; use b::bar; mod foobar { use super::*; } mod a { pub mod bar {} } mod b { pub use a::bar; } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>


Question: Doc comment says that it fails if the character is not a digit. In fact it returns option::none.

* * # Safety note * <del> * This function fails if `c` is not a valid char </del> <ins> * This function returns none if `c` is not a valid char </ins> * * # Return value *


Question:
talks about what it uses to query time on the various platforms, but that is an implementation detail. The API documentation should define minimum precision guarantees for these APIs, so the user can make an informed decision whether using these APIs will provide sufficient precision for their use case on all supported platforms. For example, if a user wanted to use these APIs to limit framerate in a video game, second precision wouldn't cut it, but millisecond precision should be sufficient for most cases, so if these APIs guarantee at least millisecond precision, then they can be used for this purpose.
Should we guarantee precision or document which system APIs these things use?
I definitely agree this should be documented, at least for major platforms. If it's not documented, all you can do is test the precision, but then you have to make assumptions about future systems. If we guarantee a precision, that leaves open the question of what to do for a system that can't support such a precision. Panic?
We already can't guarantee any particular precision. Linux for example runs on processors with a wide variety of timing hardware, with all sorts of different precisions.
Perhaps we need another API to query the precision.
If it's not possible to provide any guarantees, we should at least document the precision for major (tier-1) platforms, and explicitly state that there are no guarantees for other platforms.
Does "tier-1 platform" include guest Linux on VMWare? Its clock is known to be freaky. POSIX has which return the (finest) unit of time supported by the system, but they don't guarantee measurements are that accurate. When OSs don't guarantee anything, what can Rust do? Perhaps we can just add a wrapper of these query APIs if that is convenient to somebody.
Hrrm. If truly nothing else can be done, then at least let's document the platform APIs we use for at least the major platforms, so the user doesn't have to look them up in the RFCs. That's at least more information about the precision than nothing at all.
Do we aim for at least some level of precision where possible? <sWhat is the purpose of ? Does it aim to be suitable for any kind of use? Obviously, if it doesn't aim to be useful for anything, then it's useless.</sWell, the documentation does say it's "often useful for tasks such as measuring benchmarks or timing how long an operation takes". I guess that's something.
We aim for the highest precision available on whatever platform you're running on.
Then we could put that into the documentation. That's useful information.
I tried adding etc to libstd, only to find out the libc crate lacks ...
Triage: no changes I'm aware of.
I see that you mentioned this issue in your PR! You're still interested in picking this up?
Does the Library Team want to establish a minimum guaranteed precision for std::time APIs? Or desires to have platform-specific API calls being mentioned? Otherwise we can close this issue! I personally think that listing platform-specific APIs is not a good idea since they might change over time and are a hassle to maintain for the docs-team. I don't really think a minimum precision is required either, but can be if desired. Ps. Right now I pinged everyone of the libs team (I heard team pings don't work anymore), is there any convention to follow when wanting to get in contact with the libs team on a certain issue?
I think at the bare minimum precision with respect to reading time from the system should probably documented (or rather I don't think anyone would object to that). For example Windows you get something like 10ns precision between taking timing samples whereas on Linux it's 1ns (IIRC). The precision of will always be to the nanosecond. I think one of the main remaining questions is what the precision of is. Currently has a platform-specific representation which means that it has different precisions on different platforms, but this has been considered a bug before by a few issues here and there. I do not think we should document and/or try to guarantee the precision of while we're figuring out these bugs. We don't want the documentation to tie our hands one way or another.
Thanks for your response! So if I understood you correctly the task for this issue is: Figure out the underlying API calls for and documenting the precision for each platform. Do I understand this correctly? I am currently abroad, but I can probably create a PR for this once I get home. I see that the current page already states that it operates on nanosecond precision, so we don't have to change it's documentation.
I believe so, yes. As usual though the documentation needs to be careful to indicate what's captured in this thread about how we call some APIs, but those APIs aren't guaranteed to be called. Additionally system configuration may mean the API calls are less precise. (etc, etc)

///    println!("{}", now.elapsed().as_secs()); /// } /// ``` <ins> /// /// # Underlying System calls /// Currently, the following system calls are being used to get the current time using `now()`: /// /// |  Platform |               System call                                            | /// |:---------:|:--------------------------------------------------------------------:| /// | Cloud ABI | [clock_time_get (Monotonic Clock)]                                   | /// | SGX       | [`insecure_time` usercall]. More information on [timekeeping in SGX] | /// | UNIX      | [clock_time_get (Monotonic Clock)]                                   | /// | Darwin    | [mach_absolute_time]                                                 | /// | VXWorks   | [clock_gettime (Monotonic Clock)]                                    | /// | WASI      | [__wasi_clock_time_get (Monotonic Clock)]                            | /// | Windows   | [QueryPerformanceCounter]                                            | /// /// [QueryPerformanceCounter]: https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter /// [`insecure_time` usercall]: https://edp.fortanix.com/docs/api/fortanix_sgx_abi/struct.Usercalls.html#method.insecure_time /// [timekeeping in SGX]: https://edp.fortanix.com/docs/concepts/rust-std/#codestdtimecode /// [__wasi_clock_time_get (Monotonic Clock)]: https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md#clock_time_get /// [clock_gettime (Monotonic Clock)]: https://linux.die.net/man/3/clock_gettime /// [mach_absolute_time]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/services/services.html /// [clock_time_get (Monotonic Clock)]: https://github.com/NuxiNL/cloudabi/blob/master/cloudabi.txt /// /// **Disclaimer:** These system calls might change over time. /// </ins> #[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)] #[stable(feature = "time2", since = "1.8.0")] pub struct Instant(time::Instant);


Question:
talks about what it uses to query time on the various platforms, but that is an implementation detail. The API documentation should define minimum precision guarantees for these APIs, so the user can make an informed decision whether using these APIs will provide sufficient precision for their use case on all supported platforms. For example, if a user wanted to use these APIs to limit framerate in a video game, second precision wouldn't cut it, but millisecond precision should be sufficient for most cases, so if these APIs guarantee at least millisecond precision, then they can be used for this purpose.
Should we guarantee precision or document which system APIs these things use?
I definitely agree this should be documented, at least for major platforms. If it's not documented, all you can do is test the precision, but then you have to make assumptions about future systems. If we guarantee a precision, that leaves open the question of what to do for a system that can't support such a precision. Panic?
We already can't guarantee any particular precision. Linux for example runs on processors with a wide variety of timing hardware, with all sorts of different precisions.
Perhaps we need another API to query the precision.
If it's not possible to provide any guarantees, we should at least document the precision for major (tier-1) platforms, and explicitly state that there are no guarantees for other platforms.
Does "tier-1 platform" include guest Linux on VMWare? Its clock is known to be freaky. POSIX has which return the (finest) unit of time supported by the system, but they don't guarantee measurements are that accurate. When OSs don't guarantee anything, what can Rust do? Perhaps we can just add a wrapper of these query APIs if that is convenient to somebody.
Hrrm. If truly nothing else can be done, then at least let's document the platform APIs we use for at least the major platforms, so the user doesn't have to look them up in the RFCs. That's at least more information about the precision than nothing at all.
Do we aim for at least some level of precision where possible? <sWhat is the purpose of ? Does it aim to be suitable for any kind of use? Obviously, if it doesn't aim to be useful for anything, then it's useless.</sWell, the documentation does say it's "often useful for tasks such as measuring benchmarks or timing how long an operation takes". I guess that's something.
We aim for the highest precision available on whatever platform you're running on.
Then we could put that into the documentation. That's useful information.
I tried adding etc to libstd, only to find out the libc crate lacks ...
Triage: no changes I'm aware of.
I see that you mentioned this issue in your PR! You're still interested in picking this up?
Does the Library Team want to establish a minimum guaranteed precision for std::time APIs? Or desires to have platform-specific API calls being mentioned? Otherwise we can close this issue! I personally think that listing platform-specific APIs is not a good idea since they might change over time and are a hassle to maintain for the docs-team. I don't really think a minimum precision is required either, but can be if desired. Ps. Right now I pinged everyone of the libs team (I heard team pings don't work anymore), is there any convention to follow when wanting to get in contact with the libs team on a certain issue?
I think at the bare minimum precision with respect to reading time from the system should probably documented (or rather I don't think anyone would object to that). For example Windows you get something like 10ns precision between taking timing samples whereas on Linux it's 1ns (IIRC). The precision of will always be to the nanosecond. I think one of the main remaining questions is what the precision of is. Currently has a platform-specific representation which means that it has different precisions on different platforms, but this has been considered a bug before by a few issues here and there. I do not think we should document and/or try to guarantee the precision of while we're figuring out these bugs. We don't want the documentation to tie our hands one way or another.
Thanks for your response! So if I understood you correctly the task for this issue is: Figure out the underlying API calls for and documenting the precision for each platform. Do I understand this correctly? I am currently abroad, but I can probably create a PR for this once I get home. I see that the current page already states that it operates on nanosecond precision, so we don't have to change it's documentation.
I believe so, yes. As usual though the documentation needs to be careful to indicate what's captured in this thread about how we call some APIs, but those APIs aren't guaranteed to be called. Additionally system configuration may mean the API calls are less precise. (etc, etc)

///    } /// } /// ``` <ins> /// /// # Underlying System calls /// Currently, the following system calls are being used to get the current time using `now()`: /// /// |  Platform |               System call                                            | /// |:---------:|:--------------------------------------------------------------------:| /// | Cloud ABI | [clock_time_get (Realtime Clock)]                                    | /// | SGX       | [`insecure_time` usercall]. More information on [timekeeping in SGX] | /// | UNIX      | [clock_gettime (Realtime Clock)]                                     | /// | DARWIN    | [gettimeofday]                                                       | /// | VXWorks   | [clock_gettime (Realtime Clock)]                                     | /// | WASI      | [__wasi_clock_time_get (Realtime Clock)]                             | /// | Windows   | [GetSystemTimeAsFileTime]                                            | /// /// [clock_time_get (Realtime Clock)]: https://github.com/NuxiNL/cloudabi/blob/master/cloudabi.txt /// [gettimeofday]: http://man7.org/linux/man-pages/man2/gettimeofday.2.html /// [clock_gettime (Realtime Clock)]: https://linux.die.net/man/3/clock_gettime /// [__wasi_clock_time_get (Realtime Clock)]: https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-api.md#clock_time_get /// [GetSystemTimeAsFileTime]: https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimeasfiletime /// /// **Disclaimer:** These system calls might change over time. /// </ins> #[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)] #[stable(feature = "time2", since = "1.8.0")] pub struct SystemTime(time::SystemTime);


Question:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc

ret }); <del> // Needs to go *after* expansion to be able to check the results // of macro expansion.  This runs before #[cfg] to try to catch as // much as possible (e.g. help the programmer avoid platform // specific differences) time(time_passes, "complete gated feature checking 1", || { sess.track_errors(|| { let features = syntax::feature_gate::check_crate(sess.codemap(), &sess.parse_sess.span_diagnostic, &krate, &attributes, sess.opts.unstable_features); *sess.features.borrow_mut() = features; }) })?; </del> // JBC: make CFG processing part of expansion to avoid this problem: // strip again, in case expansion added anything with a #[cfg].


Question:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc

"checking for inline asm in case the target doesn't support it", || no_asm::check_crate(sess, &krate)); <del> // One final feature gating of the true AST that gets compiled // later, to make sure we've got everything (e.g. configuration // can insert new attributes via `cfg_attr`) time(time_passes, "complete gated feature checking 2", || { </del> <ins> // Needs to go *after* expansion to be able to check the results of macro expansion. time(time_passes, "complete gated feature checking", || { </ins> sess.track_errors(|| { let features = syntax::feature_gate::check_crate(sess.codemap(), &sess.parse_sess.span_diagnostic,


Question:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc

// When we enter a module, record it, for the sake of `module!` pub fn expand_item(it: P<ast::Item>, fld: &mut MacroExpander) -> SmallVector<P<ast::Item>> { <del> let it = expand_item_multi_modifier(Annotatable::Item(it), fld); expand_annotatable(it, fld) </del> <ins> expand_annotatable(Annotatable::Item(it), fld) </ins> .into_iter().map(|i| i.expect_item()).collect() }


Question:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc

<ins> // Copyright 2016 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. #![feature(rustc_attrs)] macro_rules! mac { {} => { #[cfg(attr)] mod m { #[lang_item] fn f() {} } } } mac! {} #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>


Question:
The Unix implementation of in boils down to: The branch of the conditional doesn't properly handle the case where fails. For comparison's sake, the Windows implementation says:
Oh dear, seems bad! Out of curiosity, was this discovered from reading or from a bug? We could consider a backport to beta if that's necessary
This was discovered when reading through to write a custom memory allocator for Firefox. I suspect it's hard to make it trigger due to overcommit policies and the general lack of usage of over-aligned types.

libc::realloc(ptr as *mut libc::c_void, size as libc::size_t) as *mut u8 } else { let new_ptr = allocate(size, align); <del> ptr::copy(ptr, new_ptr, cmp::min(size, old_size)); deallocate(ptr, old_size, align); </del> <ins> if !new_ptr.is_null() { ptr::copy(ptr, new_ptr, cmp::min(size, old_size)); deallocate(ptr, old_size, align); } </ins> new_ptr } }


Question:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .

glob_importers: RefCell<Vec<(Module<'a>, &'a ImportDirective<'a>)>>, globs: RefCell<Vec<&'a ImportDirective<'a>>>, <ins> // Used to memoize the traits in this module for faster searches through all traits in scope. traits: RefCell<Option<Box<[&'a NameBinding<'a>]>>>, </ins> // Whether this module is populated. If not populated, any attempt to // access the children must be preceded with a // `populate_module_if_necessary` call.


Question:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .

prelude: RefCell::new(None), glob_importers: RefCell::new(Vec::new()), globs: RefCell::new((Vec::new())), <ins> traits: RefCell::new(None), </ins> populated: Cell::new(!external), arenas: arenas }


Question:
Before (on librustc): After (on same librustc): cc
The extra RAM usage seems to be because of the AST not getting freed after the early lint checks. Not sure if this is intentional.
The AST should definitely still get freed, nobody touched , so it's not intentional (unless something about the command line options has changed?)
The performance regression in looks like it was caused by . I'll work on a fix now. I'm not sure what caused the RAM increase.
Resolution used to take about 1 seconds a few months ago in winapi and now it takes 9 seconds.
I fixed the performance regression in .

let mut search_module = self.current_module; loop { // Look for trait children. <del> let mut search_in_module = |module: Module<'a>| module.for_each_child(|_, ns, binding| { if ns != TypeNS { return } let trait_def_id = match binding.def() { Some(Def::Trait(trait_def_id)) => trait_def_id, Some(..) | None => return, }; if self.trait_item_map.contains_key(&(name, trait_def_id)) { add_trait_info(&mut found_traits, trait_def_id, name); let trait_name = self.get_trait_name(trait_def_id); self.record_use(trait_name, TypeNS, binding); </del> <ins> let mut search_in_module = |module: Module<'a>| { let mut traits = module.traits.borrow_mut(); if traits.is_none() { let mut collected_traits = Vec::new(); module.for_each_child(|_, ns, binding| { if ns != TypeNS { return } if let Some(Def::Trait(_)) = binding.def() { collected_traits.push(binding); } }); *traits = Some(collected_traits.into_boxed_slice()); </ins> } <del> }); </del> <ins> for binding in traits.as_ref().unwrap().iter() { let trait_def_id = binding.def().unwrap().def_id(); if self.trait_item_map.contains_key(&(name, trait_def_id)) { add_trait_info(&mut found_traits, trait_def_id, name); let trait_name = self.get_trait_name(trait_def_id); self.record_use(trait_name, TypeNS, binding); } } }; </ins> search_in_module(search_module); match search_module.parent_link {


Question:
Should it expect a ? Full example code:
It should expect , but it's lost from the expected set. I't not an issue specific for , but a symptom of a more general problem with expected token sets. There's a long weekend ahead, I'll investigate.
Oh wait, this works on nightly, as expected (fixed in , more specifically). It means there are no problems with expected token sets.

<ins> // Copyright 2016 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. use foo.bar; //~ ERROR expected one of `::`, `;`, or `as`, found `.` </ins>


Question: Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.

return os.path.join(self.bin_root(), '.cargo-stamp') def rustc_out_of_date(self): <del> if not os.path.exists(self.rustc_stamp()): </del> <ins> if not os.path.exists(self.rustc_stamp()) or self.clean: </ins> return True with open(self.rustc_stamp(), 'r') as f: return self.stage0_rustc_date() != f.read() def cargo_out_of_date(self): <del> if not os.path.exists(self.cargo_stamp()): </del> <ins> if not os.path.exists(self.cargo_stamp()) or self.clean: </ins> return True with open(self.cargo_stamp(), 'r') as f: return self.stage0_cargo_date() != f.read()


Question: Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.

return '' def build_bootstrap(self): <ins> build_dir = os.path.join(self.build_dir, "bootstrap") if self.clean and os.path.exists(build_dir): shutil.rmtree(build_dir) </ins> env = os.environ.copy() <del> env["CARGO_TARGET_DIR"] = os.path.join(self.build_dir, "bootstrap") </del> <ins> env["CARGO_TARGET_DIR"] = build_dir </ins> env["RUSTC"] = self.rustc() env["LD_LIBRARY_PATH"] = os.path.join(self.bin_root(), "lib") env["DYLD_LIBRARY_PATH"] = os.path.join(self.bin_root(), "lib")


Question: Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.

def main(): parser = argparse.ArgumentParser(description='Build rust') parser.add_argument('--config') <ins> parser.add_argument('--clean', action='store_true') </ins> parser.add_argument('-v', '--verbose', action='store_true') args = [a for a in sys.argv if a != '-h']


Question: Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.

rb.rust_root = os.path.abspath(os.path.join(__file__, '../../..')) rb.build_dir = os.path.join(os.getcwd(), "build") rb.verbose = args.verbose <ins> rb.clean = args.clean </ins> try: with open(args.config or 'config.toml') as config:


Question: The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

asm!("xor %eax, %eax" : : <del> : "{eax}" </del> <ins> : "eax" </ins> ); # } } ```


Question: The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

# #![feature(asm)] # #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] # fn main() { unsafe { <del> asm!("xor %eax, %eax" ::: "{eax}"); </del> <ins> asm!("xor %eax, %eax" ::: "eax"); </ins> # } } ```


Question: The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

# #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] # fn main() { unsafe { // Put the value 0x200 in eax <del> asm!("mov $$0x200, %eax" : /* no outputs */ : /* no inputs */ : "{eax}"); </del> <ins> asm!("mov $$0x200, %eax" : /* no outputs */ : /* no inputs */ : "eax"); </ins> # } } ```


Question: The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

if OPTIONS.iter().any(|&opt| s == opt) { cx.span_warn(p.last_span, "expected a clobber, found an option"); <ins> } else if s.starts_with("{") || s.ends_with("}") { cx.span_err(p.last_span, "clobber should not be surrounded by braces"); </ins> } clobs.push(s); } }


Question: The rust book states that asm! clobbers should be written as "{rdx}" but when you use them as such the clobbers will be silently ignored making for some nasty bugs. output Relevant part of objdump: Relevant LLVM IR: As we can seen in the emitted LLVM IR, the given clobbers are surrounded by {{}}. I'm not sure what effect this has, but it seems like LLVM just silently ignores them. A fix would either be to not send the extra {}'s to LLVM or to edit the documentation to reflect that clobbers should be given without surrounding {}'s. Either way, this should probably not generate invalid code silently.

<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // ignore-android // ignore-arm // ignore-aarch64 #![feature(asm, rustc_attrs)] #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] #[rustc_error] pub fn main() { unsafe { // clobber formatted as register input/output asm!("xor %eax, %eax" : : : "{eax}"); //~^ ERROR clobber should not be surrounded by braces } } </ins>


Question:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

use rustc_infer::infer; use rustc_infer::traits::{self, StatementAsExpression}; use rustc_middle::lint::in_external_macro; <del> use rustc_middle::ty::{self, Binder, DefIdTree, IsSuggestable, Ty}; </del> <ins> use rustc_middle::ty::{ self, suggest_constraining_type_params, Binder, DefIdTree, IsSuggestable, ToPredicate, Ty, }; </ins> use rustc_session::errors::ExprParenthesesNeeded; use rustc_span::symbol::sym; use rustc_span::Span;


Question:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

&& !results.expr_adjustments(callee_expr).iter().any(|adj| matches!(adj.kind, ty::adjustment::Adjust::Deref(..))) // Check that we're in fact trying to clone into the expected type && self.can_coerce(*pointee_ty, expected_ty) <ins> && let trait_ref = ty::Binder::dummy(self.tcx.mk_trait_ref(clone_trait_did, [expected_ty])) </ins> // And the expected type doesn't implement `Clone` && !self.predicate_must_hold_considering_regions(&traits::Obligation::new( self.tcx, traits::ObligationCause::dummy(), self.param_env, <del> ty::Binder::dummy(self.tcx.mk_trait_ref( clone_trait_did, [expected_ty], )), </del> <ins> trait_ref, </ins> )) { diag.span_note(


Question:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

"`{expected_ty}` does not implement `Clone`, so `{found_ty}` was cloned instead" ), ); <ins> let owner = self.tcx.hir().enclosing_body_owner(expr.hir_id); if let ty::Param(param) = expected_ty.kind() && let Some(generics) = self.tcx.hir().get_generics(owner) { suggest_constraining_type_params( self.tcx, generics, diag, vec![(param.name.as_str(), "Clone", Some(clone_trait_did))].into_iter(), ); } else { self.suggest_derive(diag, &[(trait_ref.to_predicate(self.tcx), None, None)]); } </ins> } }


Question:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

self.suggest_derive(err, &preds); } <del> fn suggest_derive( </del> <ins> pub fn suggest_derive( </ins> &self, err: &mut Diagnostic, unsatisfied_predicates: &[(


Question:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

<ins> // run-rustfix fn wat<T: Clone>(t: &T) -> T { t.clone() //~ ERROR E0308 } #[derive(Clone)] struct Foo; fn wut(t: &Foo) -> Foo { t.clone() //~ ERROR E0308 } fn main() { wat(&42); wut(&Foo); } </ins>


Question:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

<ins> // run-rustfix fn wat<T>(t: &T) -> T { t.clone() //~ ERROR E0308 } struct Foo; fn wut(t: &Foo) -> Foo { t.clone() //~ ERROR E0308 } fn main() { wat(&42); wut(&Foo); } </ins>


Question:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

<ins> error[E0308]: mismatched types --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 | LL | fn wat<T>(t: &T) -> T { |        -            - expected `T` because of return type |        | |        this type parameter LL |     t.clone() |     ^^^^^^^^^ expected type parameter `T`, found `&T` | = note: expected type parameter `T` found reference `&T` note: `T` does not implement `Clone`, so `&T` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:3:5 | LL |     t.clone() |     ^ help: consider restricting type parameter `T` | LL | fn wat<T: Clone>(t: &T) -> T { |         +++++++ error[E0308]: mismatched types --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:9:5 | LL | fn wut(t: &Foo) -> Foo { |                    --- expected `Foo` because of return type LL |     t.clone() |     ^^^^^^^^^ expected struct `Foo`, found `&Foo` | note: `Foo` does not implement `Clone`, so `&Foo` was cloned instead --> $DIR/clone-on-unconstrained-borrowed-type-param.rs:9:5 | LL |     t.clone() |     ^ help: consider annotating `Foo` with `#[derive(Clone)]` | LL | #[derive(Clone)] | error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>


Question:
This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"

| LL |     nc.clone() |     ^^ <ins> help: consider annotating `NotClone` with `#[derive(Clone)]` | LL | #[derive(Clone)] | </ins> error: aborting due to previous error


Question:
Was just trying to read through std::fmt to understand how format values to a particular decimal point. I came across this set of examples, which don't do a good job of explaining the output of each, so it's difficult to visually pattern match what I type in to what comes out:
Sorry for the mess :sweat_smile: I guess it is clearer now.

//!    in this case, if one uses the format string `{<arg>:<spec>.*}`, then the `<arg>` part refers //!    to the *value* to print, and the `precision` must come in the input preceding `<arg>`. //! <del> //! For example, these: </del> <ins> //! For example, the following calls all print the same thing `Hello x is 0.01000`: </ins> //! //! ``` <del> //! // Hello {arg 0 (x)} is {arg 1 (0.01) with precision specified inline (5)} </del> <ins> //! // Hello {arg 0 ("x")} is {arg 1 (0.01) with precision specified inline (5)} </ins> //! println!("Hello {0} is {1:.5}", "x", 0.01); //! <del> //! // Hello {arg 1 (x)} is {arg 2 (0.01) with precision specified in arg 0 (5)} </del> <ins> //! // Hello {arg 1 ("x")} is {arg 2 (0.01) with precision specified in arg 0 (5)} </ins> //! println!("Hello {1} is {2:.0$}", 5, "x", 0.01); //! <del> //! // Hello {arg 0 (x)} is {arg 2 (0.01) with precision specified in arg 1 (5)} </del> <ins> //! // Hello {arg 0 ("x")} is {arg 2 (0.01) with precision specified in arg 1 (5)} </ins> //! println!("Hello {0} is {2:.1$}", "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {second of next two args (0.01) with precision </del> <ins> //! // Hello {next arg ("x")} is {second of next two args (0.01) with precision </ins> //! //                          specified in first of next two args (5)} //! println!("Hello {} is {:.*}",    "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {arg 2 (0.01) with precision </del> <ins> //! // Hello {next arg ("x")} is {arg 2 (0.01) with precision </ins> //! //                          specified in its predecessor (5)} //! println!("Hello {} is {2:.*}",   "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {arg "number" (0.01) with precision specified </del> <ins> //! // Hello {next arg ("x")} is {arg "number" (0.01) with precision specified </ins> //! //                          in arg "prec" (5)} //! println!("Hello {} is {number:.prec$}", "x", prec = 5, number = 0.01); //! ``` //! <del> //! All print the same thing: //! //! ```text //! Hello x is 0.01000 //! ``` //! </del> //! While these: //! //! ```


Question:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

/// ``` #[stable(feature = "move_cell", since = "1.17.0")] pub fn into_inner(self) -> T { <del> unsafe { self.value.into_inner() } </del> <ins> self.value.into_inner() </ins> } }


Question:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

// compiler statically verifies that it is not currently borrowed. // Therefore the following assertion is just a `debug_assert!`. debug_assert!(self.borrow.get() == UNUSED); <del> unsafe { self.value.into_inner() } </del> <ins> self.value.into_inner() </ins> } /// Replaces the wrapped value with a new one, returning the old value,