Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that `#[thread_local]` attribute is gated by `thread_local` // feature gate. // // (Note that the `thread_local!` macro is explicitly *not* gated; it // is given permission to expand into this unstable attribute even // when the surrounding context does not have permission to use it.) #[thread_local] //~ ERROR `#[thread_local]` is an experimental feature static FOO: i32 = 3; pub fn main() { FOO.with(|x| { println!("x: {}", x); }); } </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that `#[unsafe_destructor]` attribute is gated by `unsafe_destructor` // feature gate. struct D<'a>(&'a u32); #[unsafe_destructor] impl<'a> Drop for D<'a> { //~^ ERROR `#[unsafe_destructor]` allows too many unsafe patterns fn drop(&mut self) { } } //~^ HELP: add #![feature(unsafe_destructor)] to the crate attributes to enable pub fn main() { } </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that macro reexports item are gated by `macro_reexport` feature gate. // aux-build:macro_reexport_1.rs // ignore-stage1 #![crate_type = "dylib"] #[macro_reexport(reexported)] #[macro_use] #[no_link] extern crate macro_reexport_1; //~^ ERROR macros reexports are experimental and possibly buggy //~| HELP add #![feature(macro_reexport)] to the crate attributes to enable </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that patterns including the box syntax are gated by `box_patterns` feature gate. fn main() { let x = Box::new(1); match x { box 1 => (), //~^ box pattern syntax is experimental //~| add #![feature(box_patterns)] to the crate attributes to enable _     => () }; } </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that the use of the box syntax is gated by `box_syntax` feature gate. fn main() { let x = box 3; //~^ ERROR box expression syntax is experimental; you can call `Box::new` instead. //~| HELP add #![feature(box_syntax)] to the crate attributes to enable } </ins>


Question:
I was sloppy when I implemented and did not include a test. So, surprise, a follow-on commit a few days later broke it. As self-punishment for neglecting to include a regression test, I am assigning myself the task of reviewing our test suite to make sure that every feature-gate has a test. Here is a transcribed list of feature gates, based on , that I have annotated according to whether the feature is Accepted/Removed (and thus needs no tests), Active/Deprecated but has tests already (marked with an , or Active/Deprecated but has no tests that I saw via a cursory grep/skim. - , - , - , [x] - ("asm", "1.0.0", Active), - , [x] - ("nonasciiidents", "1.0.0", Active), [x] - ("threadlocal", "1.0.0", Active), [x] - ("linkargs", "1.0.0", Active), - , [x] - ("pluginregistrar", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate. From the error message it seems like the gate is firing. [x] - ("logsyntax", "1.0.0", Active), [x] - ("tracemacros", "1.0.0", Active), [x] - ("concatidents", "1.0.0", Active), [x] - ("unsafedestructor", "1.0.0", Active), [x] - ("intrinsics", "1.0.0", Active), [x] - ("langitems", "1.0.0", Active), [x] - ("simd", "1.0.0", Active), - , [x] - ("quote", "1.0.0", Active), [x] - ("linkllvmintrinsics", "1.0.0", Active), [x] - ("linkage", "1.0.0", Active), - , - , [ ] - ("rustcdiagnosticmacros", "1.0.0", Active), [ ] - ("unboxedclosures", "1.0.0", Active), - , [ ] - ("advancedslicepatterns", "1.0.0", Active), - , - , [ ] - ("visibleprivatetypes", "1.0.0", Active), - , [x] - ("boxsyntax", "1.0.0", Active), gated-box- [ ] - ("onunimplemented", "1.0.0", Active), [x] - ("simdffi", "1.0.0", Active), gated-simd- - , - , [ ] - ("plugin", "1.0.0", Active), but it is not clear whether this is testing the gate or the gate [ ] - ("start", "1.0.0", Active), [ ] - ("main", "1.0.0", Active), - , - , [ ] - ("oldorphancheck", "1.0.0", Deprecated), [ ] - ("oldimplcheck", "1.0.0", Deprecated), [ ] - ("optinbuiltintraits", "1.0.0", Active), [x] - ("intuint", "1.0.0", Active), [x] - ("macroreexport", "1.0.0", Active), gated-macro- - , - , [x] - ("stagedapi", "1.0.0", Active), [ ] - ("unmarkedapi", "1.0.0", Active), [x] - ("nostd", "1.0.0", Active), [x] - ("boxpatterns", "1.0.0", Active), gated-box- [x] - ("unsafenodropflag", "1.0.0", Active), [x] - ("customattribute", "1.0.0", Active), [x] - ("customderive", "1.0.0", Active), single-derive- [ ] - ("rustcattrs", "1.0.0", Active), [x] - ("staticassert", "1.0.0", Active), [x] - ("allowinternal_unstable", "1.0.0", Active),
(but hey, if other people want to add such missing tests in the meantime, while I am asleep, I will not mind. :)
In case its not clear: If you want to help, just find a case above that does not have a check-mark and also does not have a pull request number attached beneath it. (And I guess write your name so that other people do not waste time adding a test for the same feature gate).
The test for is located in
I am not surprised that I "overlooked" that ... the expected error message prefix does not say anything about a feature gate. Let me just confirm that the whole message does ... Update: Okay, the help output for that test () does mention the feature gate: So I have now checked off that box, though I wonder if I should add this help message to the expected test output there.
I was wondering the same thing about the help message. It is not very clear what that test is doing, the only hint was the filename. From reading some help messages were removed, would there be any concern for adding help messages to the expected test output in this case? It could be worth adding a comment in there similar to the other gated tests: In addition, would it be worth going as far as to rename to (and doing the same for any other gated tests that do not have a prefix in their filename)?
In relation to the feature gate list above I'm going to start off by looking into the following: update: removed items that had tests, and , - - -
ah yes, is (correctly) why the help mag is missing .... hmm .... that complicates things
I've done a pass through of the unchecked feature gates and have found tests for the following: () () () () () () Could these be marked as complete?
thanks!
Ok, so I've had a look through everything, here's my findings: I have some questions below for the three outstanding feature gates (at the very bottom of this comment) and was wondering if you could help confirm the status of those feature gate tests? My previous listed feature gates that had existing tests. I've since found a few more to add to that list. Here is the full list of feature gates with existing tests. New findings are in bold: : : : : : : : : : The following feature gates were removed after this issue was initially created. Since they are no longer around they can be considered complete or crossed out of the task list above: : see : see The following feature gates appear to have duplicate tests introduced in , the initial tests were in and : - The following are not in the above task list as they have been since the issue was initially created: : see : see The following are remaining feature gates needing tests (excluding the feature gates I had questions for, see below). I'm cooking up a PR for these: - - - The following items are ones that I had trouble completing because I have questions and need some feedback: - The was introduced in , and tests for were replaced with tests for missing stability attributes: . In addition, it seems that there is no way to trigger unless there is a bug in a library or the compiler itself. Are the tests in missing- enough to consider complete? These appear to be the we're looking for relating to , could someone confirm this? This appears to be the feature gate test, but was removed in () Should we reinstate the test in this issue or let it be handled by which is in the works?
For visibleprivatetypes, i found src/test/run-pass/visible-private-types-feature- Not sure if item this should be ticked as well.
There appear to be a lot of new unstable features since this was touched. It seems hopeless to ever catch up on this issue without an automatic tidy script verifying the tests exist. do you want this issue to continue? Should we try to augment tidy to check the existence of compile-fail tests mentioning unstable features?
I agree that it seems like we'll never be able to close this without having some sort of automation (e.g. a tidy script, as you say) to verify that the tests exist. I don't have any immediate idea about the best way to write such a script. I guess it could just be based on some naming convention for the test itself; i.e. it would be just a heuristic check, not a true verification of it.
I think it could be written like so: after , search everything in for . If this makes sense I can mentor.
but requiring the test to explicitly deny the feature defeats the point, doesn't it? That is, the goal here is to catch code that makes use of a feature without explicitly opting into that feature. .. Though I suppose you might be thinking that if there is enough infrastructure present to support some kind of deny(feature) attribute, then that is a sign that the necessary gating is in place, regardless of what the default lint settings actually are?
Good point. I think yes, I was considering that just confirming that the compiler has code that correctly can deny the feature is good enough, but there is some room for error by making the deny explicit. The attribute also wouldn't actually confirm that the compile failed for the correct reason. We could also just require tests to annotate in some other way that yes, it is testing that a particular feature is denied. As an extension to my previous suggestion, the test runner could take the test case that is annotated to be a 'deny feature' test, run it once with then run it again with no feature attribute, and compare the results.
Similarly to the above, but to avoid creating another custom test runner. The featureck lint could require that and contain pairs of feature tests that are identical, one with and one without.
With fixed, maybe this issue can be closed as resolved?
Thanks

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that the use of smid types in the ffi is gated by `smid_ffi` feature gate. #![feature(simd)] #[repr(C)] #[derive(Copy)] #[simd] pub struct f32x4(f32, f32, f32, f32); #[allow(dead_code)] extern { fn foo(x: f32x4); //~^ ERROR use of SIMD type `f32x4` in FFI is highly experimental and may result in invalid code //~| HELP add #![feature(simd_ffi)] to the crate attributes to enable } fn main() {} </ins>


Question:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

```rust let captured_var = 10; <del> let closure_no_args = |&:| println!("captured_var={}", captured_var); </del> <ins> let closure_no_args = || println!("captured_var={}", captured_var); </ins> <del> let closure_args = |&: arg: i32| -> i32 { </del> <ins> let closure_args = |arg: i32| -> i32 { </ins> println!("captured_var={}, arg={}", captured_var, arg); arg // Note lack of semicolon after 'arg' };


Question:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

} } (Ok(const_int(a)), Ok(const_int(b))) => { <del> let is_a_min_value = |&:| { </del> <ins> let is_a_min_value = || { </ins> let int_ty = match ty::expr_ty_opt(tcx, e).map(|ty| &ty.sty) { Some(&ty::ty_int(int_ty)) => int_ty, _ => return false


Question:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

scope: region::CodeExtent, depth: uint) { <del> let origin = |&:| infer::SubregionOrigin::SafeDestructor(span); </del> <ins> let origin = || infer::SubregionOrigin::SafeDestructor(span); </ins> let mut walker = ty_root.walk(); let opt_phantom_data_def_id = rcx.tcx().lang_items.phantom_data();


Question:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

// file descriptor. Otherwise, the first file descriptor opened // up in the child would be numbered as one of the stdio file // descriptors, which is likely to wreak havoc. <del> let setup = |&: src: Option<AnonPipe>, dst: c_int| { </del> <ins> let setup = |src: Option<AnonPipe>, dst: c_int| { </ins> let src = match src { None => { let flags = if dst == libc::STDIN_FILENO {


Question:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

// Similarly to unix, we don't actually leave holes for the stdio file // descriptors, but rather open up /dev/null equivalents. These // equivalents are drawn from libuv's windows process spawning. <del> let set_fd = |&: fd: &Option<AnonPipe>, slot: &mut HANDLE, </del> <ins> let set_fd = |fd: &Option<AnonPipe>, slot: &mut HANDLE, </ins> is_stdin: bool| { match *fd { None => {


Question:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

{ self.bump(); self.bump(); <del> return; </del> } else if self.eat(&token::Colon) {


Question:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that we generate obsolete syntax errors around usages of closure kinds: `|:|`, `|&:|` and // `|&mut:|`. fn main() { let a = |:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` let a = |&:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` let a = |&mut:| {};  //~ ERROR obsolete syntax: `:`, `&mut:`, or `&:` } </ins>


Question:
compiles without any error. Notably this isn't a regression from I noticed it because has a public field that has had no stability attribute from far before . However, that PR did pick up some structs with missing stability attributes, I'm unsure of the exact circumstances when fields will get the errors or when they will not.
As points out in this isn't a bug; I didn't realise that stability propagation literally just ignores , meaning is due to the on . Closing.

f: F, /// The current internal state to be passed to the closure next. <ins> #[unstable(feature = "core")] </ins> pub state: St, }


Question:
compiles without any error. Notably this isn't a regression from I noticed it because has a public field that has had no stability attribute from far before . However, that PR did pick up some structs with missing stability attributes, I'm unsure of the exact circumstances when fields will get the errors or when they will not.
As points out in this isn't a bug; I didn't realise that stability propagation literally just ignores , meaning is due to the on . Closing.

pub struct Unfold<St, F> { f: F, /// Internal state that will be passed to the closure on the next iteration <ins> #[unstable(feature = "core")] </ins> pub state: St, }


Question:
Here's a minimal example which results in a runtime error: I'd expect that format string to work (precision=0, so no digits after the decimal point), but here's what I get with RUSTBACKTRACE=1: Ubuntu 14.10 / 64-bit rustc 1.0.0-nightly ( 2015-03-05) (built 2015-03-06) binary: rustc commit-hash: commit-date: 2015-03-05 build-date: 2015-03-06 host: x8664-unknown-linux-gnu release: 1.0.0-nightly
It also happens with 9.5 but not with 9.499. The formatting routine tries to round, but fails to handle the case that rounding extends the digits.
Just to clarify: this is not actually an ICE because the program is panicking, not the compiler. So, compilation is fine, but the program fails at runtime
This issue should be closed as it's now fixed.
Yay!

if i < 0 || buf[i as usize] == b'-' || buf[i as usize] == b'+' { <del> for j in (i as usize + 1..end).rev() { </del> <ins> for j in ((i + 1) as usize..end).rev() { </ins> buf[j + 1] = buf[j]; } buf[(i + 1) as usize] = value2ascii(1);


Question:
Here's a minimal example which results in a runtime error: I'd expect that format string to work (precision=0, so no digits after the decimal point), but here's what I get with RUSTBACKTRACE=1: Ubuntu 14.10 / 64-bit rustc 1.0.0-nightly ( 2015-03-05) (built 2015-03-06) binary: rustc commit-hash: commit-date: 2015-03-05 build-date: 2015-03-06 host: x8664-unknown-linux-gnu release: 1.0.0-nightly
It also happens with 9.5 but not with 9.499. The formatting routine tries to round, but fails to handle the case that rounding extends the digits.
Just to clarify: this is not actually an ICE because the program is panicking, not the compiler. So, compilation is fine, but the program fails at runtime
This issue should be closed as it's now fixed.
Yay!

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #[test] fn test_format_float() { assert!("1" == format!("{:.0}", 1.0f64)); assert!("9" == format!("{:.0}", 9.4f64)); assert!("10" == format!("{:.0}", 9.9f64)); assert!("9.9" == format!("{:.1}", 9.85f64)); } </ins>


Question:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

// empty. } <ins> unsafe impl Send for .. { } </ins> impl<T> !Send for *const T { } impl<T> !Send for *mut T { } impl !Send for Managed { }


Question:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

// Empty } <ins> unsafe impl Sync for .. { } </ins> impl<T> !Sync for *const T { } impl<T> !Sync for *mut T { } impl !Sync for Managed { }


Question:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

pub fn trait_has_default_impl(tcx: &ctxt, trait_def_id: DefId) -> bool { populate_implementations_for_trait_if_necessary(tcx, trait_def_id); <del> match tcx.lang_items.to_builtin_kind(trait_def_id) { Some(BoundSend) | Some(BoundSync) => true, _ => tcx.traits_with_default_impls.borrow().contains_key(&trait_def_id), } </del> <ins> tcx.traits_with_default_impls.borrow().contains_key(&trait_def_id) </ins> } /// Records a trait-to-implementation mapping.


Question:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

tcx: &'cx ty::ctxt<'tcx> } <del> impl<'cx, 'tcx,'v> visit::Visitor<'v> for UnsafetyChecker<'cx, 'tcx> { fn visit_item(&mut self, item: &'v ast::Item) { match item.node { ast::ItemImpl(unsafety, polarity, _, _, _, _) => { match ty::impl_trait_ref(self.tcx, ast_util::local_def(item.id)) { None => { // Inherent impl. match unsafety { ast::Unsafety::Normal => { /* OK */ } ast::Unsafety::Unsafe => { span_err!(self.tcx.sess, item.span, E0197, "inherent impls cannot be declared as unsafe"); } } </del> <ins> impl<'cx, 'tcx, 'v> UnsafetyChecker<'cx, 'tcx> { fn check_unsafety_coherence(&mut self, item: &'v ast::Item, unsafety: ast::Unsafety, polarity: ast::ImplPolarity) { match ty::impl_trait_ref(self.tcx, ast_util::local_def(item.id)) { None => { // Inherent impl. match unsafety { ast::Unsafety::Normal => { /* OK */ } ast::Unsafety::Unsafe => { span_err!(self.tcx.sess, item.span, E0197, "inherent impls cannot be declared as unsafe"); </ins> } <ins> } } </ins> <del> Some(trait_ref) => { let trait_def = ty::lookup_trait_def(self.tcx, trait_ref.def_id); match (trait_def.unsafety, unsafety, polarity) { (ast::Unsafety::Unsafe, ast::Unsafety::Unsafe, ast::ImplPolarity::Negative) => { span_err!(self.tcx.sess, item.span, E0198, "negative implementations are not unsafe"); } </del> <ins> Some(trait_ref) => { let trait_def = ty::lookup_trait_def(self.tcx, trait_ref.def_id); match (trait_def.unsafety, unsafety, polarity) { (ast::Unsafety::Unsafe, ast::Unsafety::Unsafe, ast::ImplPolarity::Negative) => { span_err!(self.tcx.sess, item.span, E0198, "negative implementations are not unsafe"); } </ins> <del> (ast::Unsafety::Normal, ast::Unsafety::Unsafe, _) => { span_err!(self.tcx.sess, item.span, E0199, "implementing the trait `{}` is not unsafe", trait_ref.user_string(self.tcx)); } </del> <ins> (ast::Unsafety::Normal, ast::Unsafety::Unsafe, _) => { span_err!(self.tcx.sess, item.span, E0199, "implementing the trait `{}` is not unsafe", trait_ref.user_string(self.tcx)); } </ins> <del> (ast::Unsafety::Unsafe, ast::Unsafety::Normal, ast::ImplPolarity::Positive) => { span_err!(self.tcx.sess, item.span, E0200, "the trait `{}` requires an `unsafe impl` declaration", trait_ref.user_string(self.tcx)); } </del> <ins> (ast::Unsafety::Unsafe, ast::Unsafety::Normal, ast::ImplPolarity::Positive) => { span_err!(self.tcx.sess, item.span, E0200, "the trait `{}` requires an `unsafe impl` declaration", trait_ref.user_string(self.tcx)); } </ins> <del> (ast::Unsafety::Unsafe, ast::Unsafety::Normal, ast::ImplPolarity::Negative) | (ast::Unsafety::Unsafe, ast::Unsafety::Unsafe, ast::ImplPolarity::Positive) | (ast::Unsafety::Normal, ast::Unsafety::Normal, _) => { /* OK */ } } </del> <ins> (ast::Unsafety::Unsafe, ast::Unsafety::Normal, ast::ImplPolarity::Negative) | (ast::Unsafety::Unsafe, ast::Unsafety::Unsafe, ast::ImplPolarity::Positive) | (ast::Unsafety::Normal, ast::Unsafety::Normal, _) => { /* OK */ </ins> } } } <ins> } } } impl<'cx, 'tcx,'v> visit::Visitor<'v> for UnsafetyChecker<'cx, 'tcx> { fn visit_item(&mut self, item: &'v ast::Item) { match item.node { ast::ItemDefaultImpl(unsafety, _) => { self.check_unsafety_coherence(item, unsafety, ast::ImplPolarity::Positive); } ast::ItemImpl(unsafety, polarity, _, _, _, _) => { self.check_unsafety_coherence(item, unsafety, polarity); } </ins> _ => { } }


Question:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

} } <ins> ast::ItemDefaultImpl(..) => { self.gate_feature("optin_builtin_traits", i.span, "default trait implementations are experimental  and possibly buggy"); } </ins> ast::ItemImpl(_, polarity, _, _, _, _) => { match polarity { ast::ImplPolarity::Negative => {


Question:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

impl MyTrait for .. {} //~^ ERROR conflicting implementations for trait `MyTrait` <ins> trait MySafeTrait: MarkerTrait {} unsafe impl MySafeTrait for .. {} //~^ ERROR implementing the trait `MySafeTrait` is not unsafe unsafe trait MyUnsafeTrait: MarkerTrait {} impl MyUnsafeTrait for .. {} //~^ ERROR the trait `MyUnsafeTrait` requires an `unsafe impl` declaration </ins> fn main() {}


Question:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.

// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(optin_builtin_traits)] </ins> pub mod bar { use std::marker;


Question:
The references states that is a logical right shift, however it seems that it behaves like an arithmetic right shift for signed integers. For instance the following snippet prints : A logical right shift should produce (assuming 2's complement representation which I think rust guarantees?). In the same spirit the reference does not say if shifting outside the range of an integer is defined. From my quick test it doesn't appear to be: This prints garbage on my computer and on the playpen, so I assume it's UB or at least UV (it doesn't trigger the overflow check in debug builds though, maybe it should?) On a similar topic the reference also states that the following behaviours are safe: Unsigned integer overflow (well-defined as wrapping) Signed integer overflow (well-defined as two's complement representation wrapping) I believe that's not true anymore.
I see that checking for bitshift overflows is going to be implemented in so it seems to confirm that it's UB (UV?) for now.
see PR for the checks. We can go either way on the issue of whether overflow is UB or UV or neither. (That is, it is easy to adapt the PR accordingly; just a matter of deciding, and perhaps measuring the impact on code size, maybe.)
what's the process by which we decide that? I'd like to knock this issue out.
heh, I already made an "executive decision" (though admittedly it was one that was already in favor of), of making overflow panic when checks are on, and when the checks are off, we forcibly mask the RHS to ensure that we do not encounter weirdness such as that documented in and . (Though I still need to put in tests for that fallback behavior.)
That sounds very reasonable, thanks. Right shifts of signed values will remain arithmetic though, right? It's probably what most people will expect since that's how it's done in C/C++ and we'd have to simple way of doing arithmetic shifting otherwise.
right-shift of signed values are still arithmetic shifts, but that is independent of the overflow checking (which is based solely on the value of the right-hand-side compared to the bitwidth of the type of the left-hand-side)
Okay, that makes sense. I wanted to make sure that was the intended behaviour since the reference seems to say otherwise. Thank you!
oh I see; yes that part of the reference has probably been incorrect for a long time.

* Sending signals * Accessing/modifying the file system * Unsigned integer overflow (well-defined as wrapping) <del> * Signed integer overflow (well-defined as two's complement representation </del> <ins> * Signed integer overflow (well-defined as two’s complement representation </ins> wrapping) #### Diverging functions


Question:
The references states that is a logical right shift, however it seems that it behaves like an arithmetic right shift for signed integers. For instance the following snippet prints : A logical right shift should produce (assuming 2's complement representation which I think rust guarantees?). In the same spirit the reference does not say if shifting outside the range of an integer is defined. From my quick test it doesn't appear to be: This prints garbage on my computer and on the playpen, so I assume it's UB or at least UV (it doesn't trigger the overflow check in debug builds though, maybe it should?) On a similar topic the reference also states that the following behaviours are safe: Unsigned integer overflow (well-defined as wrapping) Signed integer overflow (well-defined as two's complement representation wrapping) I believe that's not true anymore.
I see that checking for bitshift overflows is going to be implemented in so it seems to confirm that it's UB (UV?) for now.
see PR for the checks. We can go either way on the issue of whether overflow is UB or UV or neither. (That is, it is easy to adapt the PR accordingly; just a matter of deciding, and perhaps measuring the impact on code size, maybe.)
what's the process by which we decide that? I'd like to knock this issue out.
heh, I already made an "executive decision" (though admittedly it was one that was already in favor of), of making overflow panic when checks are on, and when the checks are off, we forcibly mask the RHS to ensure that we do not encounter weirdness such as that documented in and . (Though I still need to put in tests for that fallback behavior.)
That sounds very reasonable, thanks. Right shifts of signed values will remain arithmetic though, right? It's probably what most people will expect since that's how it's done in C/C++ and we'd have to simple way of doing arithmetic shifting otherwise.
right-shift of signed values are still arithmetic shifts, but that is independent of the overflow checking (which is based solely on the value of the right-hand-side compared to the bitwidth of the type of the left-hand-side)
Okay, that makes sense. I wanted to make sure that was the intended behaviour since the reference seems to say otherwise. Thank you!
oh I see; yes that part of the reference has probably been incorrect for a long time.

: Exclusive or. Calls the `bitxor` method of the `std::ops::BitXor` trait. * `<<` <del> : Logical left shift. </del> <ins> : Left shift. </ins> Calls the `shl` method of the `std::ops::Shl` trait. * `>>` <del> : Logical right shift. </del> <ins> : Right shift. </ins> Calls the `shr` method of the `std::ops::Shr` trait. #### Lazy boolean operators


Question:
The following panics: The following works: Apologies in advance if this is intended behavior.
I have found that it also works when using:
This will be fixed by

#[stable(feature = "rust1", since = "1.0.0")] pub fn create_dir_all<P: AsPath + ?Sized>(path: &P) -> io::Result<()> { let path = path.as_path(); <del> if path.is_dir() { return Ok(()) } </del> <ins> if path == Path::new("") || path.is_dir() { return Ok(()) } </ins> if let Some(p) = path.parent() { try!(create_dir_all(p)) } create_dir(path) }


Question:
The following panics: The following works: Apologies in advance if this is intended behavior.
I have found that it also works when using:
This will be fixed by

<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::env; use std::fs::{self, TempDir}; fn main() { let td = TempDir::new("create-dir-all-bare").unwrap(); env::set_current_dir(td.path()).unwrap(); fs::create_dir_all("create-dir-all-bare").unwrap(); } </ins>


Question:
For clarity, the second call to ends up using the impl on . cc I had concerns about this kind of thing when these impls were being introduced but I thought I convinced myself that this kind of thing couldn't happen. Did something change in the way we designed these impls since then?
Possible solutions are to either remove the impl for or update to prevent it from invoking . Seems to me like the second is the better approach.
I believe the reason for the was because it was considered a good thing to require callers to explicitly pass references. I think we've actually gone back and forth on that a few times. Are we committed now to allowing callers to just say ?

/// ``` #[macro_export] macro_rules! write { <del> ($dst:expr, $($arg:tt)*) => ((&mut *$dst).write_fmt(format_args!($($arg)*))) </del> <ins> ($dst:expr, $($arg:tt)*) => ($dst.write_fmt(format_args!($($arg)*))) </ins> } /// Equivalent to the `write!` macro, except that a newline is appended after


Question:
See as an example, goes nowhere
Another example: The type is public in this case, but it's explicitly hidden.
Yeah, there's a lot of these.
For , it could be related to re-exported signatures. The same method in doesn't have this issue: Also, is it a bug that you can have private items in a public signature's ? Or private items in an impl for a public type? cc
I wonder if rustdoc should be resolving qualified paths that it encounters.
Is there still some unresolved issue here?
Still a thing; for example, tries to link to types in rand, but the doc link is broken. (That link goes to 1.19.0, but it's still there in today's nightly docs.) If i were to guess, it probably has to do with rustdoc seeing types that are in dependencies of std, but aren't being documented alongside it.
Wrote a fix for it. Will make the PR tomorrow or after tomorrow.
This issue was actually fixed by The issue i actually referenced in that PR was apparently a duplicate of this one.

<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_name = "foo"] #[doc(hidden)] pub trait Foo {} trait Dark {} pub trait Bam {} pub struct Bar; struct Hidden; // @!has foo/struct.Bar.html '//*[@id="impl-Foo"]' 'impl Foo for Bar' impl Foo for Bar {} // @!has foo/struct.Bar.html '//*[@id="impl-Dark"]' 'impl Dark for Bar' impl Dark for Bar {} // @has foo/struct.Bar.html '//*[@id="impl-Bam"]' 'impl Bam for Bar' // @has foo/trait.Bam.html '//*[@id="implementors-list"]' 'impl Bam for Bar' impl Bam for Bar {} // @!has foo/trait.Bam.html '//*[@id="implementors-list"]' 'impl Bam for Hidden' impl Bam for Hidden {} </ins>


Question:
The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.

- name: install WIX run: src/ci/scripts/install-wix.sh if: success() && !env.SKIP_JOB <del> - name: install InnoSetup run: src/ci/scripts/install-innosetup.sh if: success() && !env.SKIP_JOB </del> - name: ensure the build happens on a partition with enough space run: src/ci/scripts/symlink-build-dir.sh if: success() && !env.SKIP_JOB


Question:
The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.

prepare("rust-mingw"); } <del> builder.install(&xform(&etc.join("exe/rust.iss")), &exe, 0o644); builder.install(&etc.join("exe/modpath.iss"), &exe, 0o644); builder.install(&etc.join("exe/upgrade.iss"), &exe, 0o644); </del> builder.install(&etc.join("gfx/rust-logo.ico"), &exe, 0o644); <del> builder.create(&exe.join("LICENSE.txt"), &license); // Generate exe installer builder.info("building `exe` installer with `iscc`"); let mut cmd = Command::new("iscc"); cmd.arg("rust.iss").arg("/Q").current_dir(&exe); if target.contains("windows-gnu") { cmd.arg("/dMINGW"); } add_env(builder, &mut cmd, target); let time = timeit(builder); builder.run(&mut cmd); drop(time); builder.install( &exe.join(format!("{}-{}.exe", pkgname(builder, "rust"), target)), &distdir(builder), 0o755, ); </del> // Generate msi installer let wix = PathBuf::from(env::var_os("WIX").unwrap());


Question:
The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.

displayName: Install wix condition: and(succeeded(), not(variables.SKIP_JOB)) <del> - bash: src/ci/scripts/install-innosetup.sh displayName: Install InnoSetup condition: and(succeeded(), not(variables.SKIP_JOB)) </del> - bash: src/ci/scripts/symlink-build-dir.sh displayName: Ensure the build happens on a partition with enough space condition: and(succeeded(), not(variables.SKIP_JOB))


Question:
The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.

run: src/ci/scripts/install-wix.sh <<: *step <del> - name: install InnoSetup run: src/ci/scripts/install-innosetup.sh <<: *step </del> - name: ensure the build happens on a partition with enough space run: src/ci/scripts/symlink-build-dir.sh <<: *step


Question:
The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.

<del> #!/bin/bash # We use InnoSetup and its `iscc` program to also create combined installers. # Honestly at this point WIX above and `iscc` are just holdovers from # oh-so-long-ago and are required for creating installers on Windows. I think # one is MSI installers and one is EXE, but they're not used so frequently at # this point anyway so perhaps it's a wash! set -euo pipefail IFS=$'nt' source "$(cd "$(dirname "$0")" && pwd)/../shared.sh" if isWindows; then curl.exe -o is-install.exe "${MIRRORS_BASE}/2017-08-22-is.exe" cmd.exe //c "is-install.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-" ciCommandAddPath "C:Program Files (x86)Inno Setup 5" fi </del>