Question: { // The dereferenced place must have type `&_`. let ty = Place::ty_from(local, proj_base, self.body, self.tcx).ty; <del> if let ty::Ref(_, _, mtbl) = ty.kind { self.optimizations.and_stars.insert(location, mtbl); </del> <ins> if let ty::Ref(_, _, Mutability::Not) = ty.kind { self.optimizations.and_stars.insert(location); </ins> } } }

Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.


Question: <del> // no-prefer-dynamic </del> // pretty-expanded FIXME #23616 #![feature(rustc_private)]

Right now on our bots we're basically in a state where if valgrind rpass tests are compiled dynamically they will all fail, but when compiled statically they will pass. I'm not really sure what's going on unfortunately, but this is either a bug in valgrind or a bug with us, and we should know precisely what it is to ensure something more sinister isn't lurking. Some links: - first pass at linking tests statically, fixed - another pass at linking all tests statically
All the failures seem to be within platform’s dynamic loader. Here’s a few things to try: updating kernel+glibc to the most recent versions (4.4-ish and 2.23-ish, respectively) help? downgrading kernel+glibc to some older version help? non-linux/non-glibc work correctly?
Any news/changes on this one ?


Question: <del> { "message": "unnecessary parentheses around `if` condition", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 521, "byte_end": 525, "line_start": 18, "line_end": 18, "column_start": 8, "column_end": 12, "is_primary": true, "text": [ { "text": "    if (_b) {", "highlight_start": 8, "highlight_end": 12 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "lint level defined here", "code": null, "level": "note", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 435, "byte_end": 448, "line_start": 11, "line_end": 11, "column_start": 9, "column_end": 22, "is_primary": true, "text": [ { "text": "#![warn(unused_parens)]", "highlight_start": 9, "highlight_end": 22 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [], "rendered": null }, { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 521, "byte_end": 525, "line_start": 18, "line_end": 18, "column_start": 8, "column_end": 12, "is_primary": true, "text": [ { "text": "    if (_b) {", "highlight_start": 8, "highlight_end": 12 } ], "label": null, "suggested_replacement": "_b", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `if` condition --> $DIR/unused_parens_remove_json_suggestion.rs:18:8 </del> <ins> {"message":"unnecessary parentheses around `if` condition","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":500,"byte_end":504,"line_start":17,"line_end":17,"column_start":8,"column_end":12,"is_primary":true,"text":[{"text":"    if (_b) { --> $DIR/unused_parens_remove_json_suggestion.rs:17:8 </ins> | LL |     if (_b) { |        ^^^^ help: remove these parentheses | note: lint level defined here <del> --> $DIR/unused_parens_remove_json_suggestion.rs:11:9 </del> <ins> --> $DIR/unused_parens_remove_json_suggestion.rs:10:9 </ins> | <del> LL | #![warn(unused_parens)] </del> <ins> LL | #![deny(unused_parens)] </ins> |         ^^^^^^^^^^^^^ <del> " } { "message": "unnecessary parentheses around `if` condition", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 618, "byte_end": 621, "line_start": 29, "line_end": 29, "column_start": 7, "column_end": 10, "is_primary": true, "text": [ { "text": "    if(c) {", "highlight_start": 7, "highlight_end": 10 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 618, "byte_end": 621, "line_start": 29, "line_end": 29, "column_start": 7, "column_end": 10, "is_primary": true, "text": [ { "text": "    if(c) {", "highlight_start": 7, "highlight_end": 10 } ], "label": null, "suggested_replacement": " c", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `if` condition --> $DIR/unused_parens_remove_json_suggestion.rs:29:7 </del> <ins> "} {"message":"unnecessary parentheses around `if` condition","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":631,"byte_end":634,"line_start":28,"line_end":28,"column_start":7,"column_end":10,"is_primary":true,"text":[{"text":"    if(c) { --> $DIR/unused_parens_remove_json_suggestion.rs:28:7 </ins> | LL |     if(c) { |       ^^^ help: remove these parentheses <del> " } { "message": "unnecessary parentheses around `if` condition", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 664, "byte_end": 667, "line_start": 33, "line_end": 33, "column_start": 8, "column_end": 11, "is_primary": true, "text": [ { "text": "    if (c){", "highlight_start": 8, "highlight_end": 11 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 664, "byte_end": 667, "line_start": 33, "line_end": 33, "column_start": 8, "column_end": 11, "is_primary": true, "text": [ { "text": "    if (c){", "highlight_start": 8, "highlight_end": 11 } ], "label": null, "suggested_replacement": "c ", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `if` condition --> $DIR/unused_parens_remove_json_suggestion.rs:33:8 </del> <ins> "} {"message":"unnecessary parentheses around `if` condition","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":711,"byte_end":714,"line_start":32,"line_end":32,"column_start":8,"column_end":11,"is_primary":true,"text":[{"text":"    if (c){ --> $DIR/unused_parens_remove_json_suggestion.rs:32:8 </ins> | LL |     if (c){ |        ^^^ help: remove these parentheses <del> " } { "message": "unnecessary parentheses around `while` condition", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 712, "byte_end": 727, "line_start": 37, "line_end": 37, "column_start": 11, "column_end": 26, "is_primary": true, "text": [ { "text": "    while (false && true){", "highlight_start": 11, "highlight_end": 26 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 712, "byte_end": 727, "line_start": 37, "line_end": 37, "column_start": 11, "column_end": 26, "is_primary": true, "text": [ { "text": "    while (false && true){", "highlight_start": 11, "highlight_end": 26 } ], "label": null, "suggested_replacement": "false && true ", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `while` condition --> $DIR/unused_parens_remove_json_suggestion.rs:37:11 </del> <ins> "} {"message":"unnecessary parentheses around `while` condition","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":793,"byte_end":808,"line_start":36,"line_end":36,"column_start":11,"column_end":26,"is_primary":true,"text":[{"text":"    while (false && true){","highlight_start":11,"highlight_end":26}],"label":null,"suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"remove these parentheses","code":null,"level":"help","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":793,"byte_end":808,"line_start":36,"line_end":36,"column_start":11,"column_end":26,"is_primary":true,"text":[{"text":"    while (false && true){","highlight_start":11,"highlight_end":26}],"label":null,"suggested_replacement":"false && true ","suggestion_applicability":"MachineApplicable","expansion":null}],"children":[],"rendered":null}],"rendered":"error: unnecessary parentheses around `while` condition --> $DIR/unused_parens_remove_json_suggestion.rs:36:11 </ins> | LL |     while (false && true){ |           ^^^^^^^^^^^^^^^ help: remove these parentheses <del> " } { "message": "unnecessary parentheses around `if` condition", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 740, "byte_end": 743, "line_start": 38, "line_end": 38, "column_start": 12, "column_end": 15, "is_primary": true, "text": [ { "text": "        if (c) {", "highlight_start": 12, "highlight_end": 15 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 740, "byte_end": 743, "line_start": 38, "line_end": 38, "column_start": 12, "column_end": 15, "is_primary": true, "text": [ { "text": "        if (c) {", "highlight_start": 12, "highlight_end": 15 } ], "label": null, "suggested_replacement": "c", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `if` condition --> $DIR/unused_parens_remove_json_suggestion.rs:38:12 </del> <ins> "} {"message":"unnecessary parentheses around `if` condition","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":821,"byte_end":824,"line_start":37,"line_end":37,"column_start":12,"column_end":15,"is_primary":true,"text":[{"text":"        if (c) { --> $DIR/unused_parens_remove_json_suggestion.rs:37:12 </ins> | LL |         if (c) { |            ^^^ help: remove these parentheses <del> " } { "message": "unnecessary parentheses around `while` condition", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 803, "byte_end": 818, "line_start": 44, "line_end": 44, "column_start": 10, "column_end": 25, "is_primary": true, "text": [ { "text": "    while(true && false) {", "highlight_start": 10, "highlight_end": 25 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 803, "byte_end": 818, "line_start": 44, "line_end": 44, "column_start": 10, "column_end": 25, "is_primary": true, "text": [ { "text": "    while(true && false) {", "highlight_start": 10, "highlight_end": 25 } ], "label": null, "suggested_replacement": " true && false", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `while` condition --> $DIR/unused_parens_remove_json_suggestion.rs:44:10 </del> <ins> "} {"message":"unnecessary parentheses around `while` condition","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":918,"byte_end":933,"line_start":43,"line_end":43,"column_start":10,"column_end":25,"is_primary":true,"text":[{"text":"    while(true && false) { --> $DIR/unused_parens_remove_json_suggestion.rs:43:10 </ins> | LL |     while(true && false) { |          ^^^^^^^^^^^^^^^ help: remove these parentheses <del> " } { "message": "unnecessary parentheses around `for` head expression", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 838, "byte_end": 846, "line_start": 45, "line_end": 45, "column_start": 18, "column_end": 26, "is_primary": true, "text": [ { "text": "        for _ in (0 .. 3){", "highlight_start": 18, "highlight_end": 26 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 838, "byte_end": 846, "line_start": 45, "line_end": 45, "column_start": 18, "column_end": 26, "is_primary": true, "text": [ { "text": "        for _ in (0 .. 3){", "highlight_start": 18, "highlight_end": 26 } ], "label": null, "suggested_replacement": "0 .. 3 ", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `for` head expression --> $DIR/unused_parens_remove_json_suggestion.rs:45:18 </del> <ins> "} {"message":"unnecessary parentheses around `for` head expression","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":987,"byte_end":995,"line_start":44,"line_end":44,"column_start":18,"column_end":26,"is_primary":true,"text":[{"text":"        for _ in (0 .. 3){ --> $DIR/unused_parens_remove_json_suggestion.rs:44:18 </ins> | LL |         for _ in (0 .. 3){ |                  ^^^^^^^^ help: remove these parentheses <del> " } { "message": "unnecessary parentheses around `for` head expression", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 905, "byte_end": 913, "line_start": 50, "line_end": 50, "column_start": 14, "column_end": 22, "is_primary": true, "text": [ { "text": "    for _ in (0 .. 3) {", "highlight_start": 14, "highlight_end": 22 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 905, "byte_end": 913, "line_start": 50, "line_end": 50, "column_start": 14, "column_end": 22, "is_primary": true, "text": [ { "text": "    for _ in (0 .. 3) {", "highlight_start": 14, "highlight_end": 22 } ], "label": null, "suggested_replacement": "0 .. 3", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `for` head expression --> $DIR/unused_parens_remove_json_suggestion.rs:50:14 </del> <ins> "} {"message":"unnecessary parentheses around `for` head expression","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":1088,"byte_end":1096,"line_start":49,"line_end":49,"column_start":14,"column_end":22,"is_primary":true,"text":[{"text":"    for _ in (0 .. 3) { --> $DIR/unused_parens_remove_json_suggestion.rs:49:14 </ins> | LL |     for _ in (0 .. 3) { |              ^^^^^^^^ help: remove these parentheses <del> " } { "message": "unnecessary parentheses around `while` condition", "code": { "code": "unused_parens", "explanation": null }, "level": "warning", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 930, "byte_end": 945, "line_start": 51, "line_end": 51, "column_start": 15, "column_end": 30, "is_primary": true, "text": [ { "text": "        while (true && false) {", "highlight_start": 15, "highlight_end": 30 } ], "label": null, "suggested_replacement": null, "suggestion_applicability": null, "expansion": null } ], "children": [ { "message": "remove these parentheses", "code": null, "level": "help", "spans": [ { "file_name": "$DIR/unused_parens_remove_json_suggestion.rs", "byte_start": 930, "byte_end": 945, "line_start": 51, "line_end": 51, "column_start": 15, "column_end": 30, "is_primary": true, "text": [ { "text": "        while (true && false) {", "highlight_start": 15, "highlight_end": 30 } ], "label": null, "suggested_replacement": "true && false", "suggestion_applicability": "MachineApplicable", "expansion": null } ], "children": [], "rendered": null } ], "rendered": "warning: unnecessary parentheses around `while` condition --> $DIR/unused_parens_remove_json_suggestion.rs:51:15 </del> <ins> "} {"message":"unnecessary parentheses around `while` condition","code":{"code":"unused_parens","explanation":null},"level":"error","spans":[{"file_name":"$DIR/unused_parens_remove_json_suggestion.rs","byte_start":1147,"byte_end":1162,"line_start":50,"line_end":50,"column_start":15,"column_end":30,"is_primary":true,"text":[{"text":"        while (true && false) { --> $DIR/unused_parens_remove_json_suggestion.rs:50:15 </ins> | LL |         while (true && false) { |               ^^^^^^^^^^^^^^^ help: remove these parentheses <del> " } </del> <ins> "} {"message":"aborting due to 9 previous errors","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to 9 previous errors "} </ins>

Update test file to use + annotations instead of (see https://rust-) The files need to update are: - <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
is the correct file name , not ? And what about this comment?
Is the problem fixed ? If not, I would like to work on it !
WIP PR has been closed due to inactivity so you can work on this.
I would like to be assigned to this issue. Am I supposed to do a new pull request ?
claim Go ahead!
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
claim
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
Hmm, it's odd, anyway, you can assign the issue to yourself by comment Ah, I mistaken the command, the collect one is , sorry.
claim
If I understood well the problem: I must replace all the by just , even if comment exist ? Because the output changes, I should modify the .stderr version I must change with in , and as should raise an error we add why add in the version ?


Question: <del> // Copyright 2013-2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. </del> <ins> // The Computer Language Benchmarks Game // http://benchmarksgame.alioth.debian.org/ </ins> // <del> // 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. </del> <ins> // contributed by the Rust Project Developers // Copyright (c) 2013-2014 The Rust Project Developers // // All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions // are met: // // - Redistributions of source code must retain the above copyright //   notice, this list of conditions and the following disclaimer. // // - Redistributions in binary form must reproduce the above copyright //   notice, this list of conditions and the following disclaimer in //   the documentation and/or other materials provided with the //   distribution. // // - Neither the name of "The Computer Language Benchmarks Game" nor //   the name of "The Computer Language Shootout Benchmarks" nor the //   names of its contributors may be used to endorse or promote //   products derived from this software without specific prior //   written permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR // SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED // OF THE POSSIBILITY OF SUCH DAMAGE. </ins> // ignore-pretty very bad with line comments // ignore-android doesn't terminate?

See I propose to change the license of Non trivial contributors: OK OK Contributors appearing in git blame that are trivial: OK OK OK OK OK Contributors with removed and trivial contributions are not considered. For the persons that are not in "OK" state, please respond to this issue saying: Then, I'll propose the corresponding PR. Thanks.
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license () Cheers
I agree to relicense any previous contributions to according to the term of the Computer Language Benchmarks Game license ()


Question: } } <ins> fn rustc_sysroot() -> str { alt os::get_exe_path() { some(_path) { let path = [_path, "..", "bin", "rustc"]; check vec::is_not_empty(path); let rustc = fs::normalize(fs::connect_many(path)); #debug("  rustc: %s", rustc); rustc } none { "rustc" } } } </ins> fn install_source(c: cargo, path: str) { #debug("source: %s", path); fs::change_dir(path);

cargo is relying on the to find rustc, but if one runs cargo with , cargo will error out with the unhelpful: cargo should detect this and return a proper error message for this. A proper workaround for this is to make sure that has an absolute path to the binaries set, as in: It needs to be absolute because cargo does a chdir to the build directory, which would break a relative path.
We have a function, that cargo can use to determine the path to itself, then use to launch the corresponding rustc.


Question: } } <ins> fn rustc_sysroot() -> str { alt os::get_exe_path() { some(_path) { let path = [_path, "..", "bin", "rustc"]; check vec::is_not_empty(path); let rustc = fs::normalize(fs::connect_many(path)); #debug("  rustc: %s", rustc); rustc } none { "rustc" } } } </ins> fn install_source(c: cargo, path: str) { #debug("source: %s", path); fs::change_dir(path);

Instead of just saying the key can't be verified, explain why.
Yeah, it should also not fail! Missing gpg is a warning condition, not an error condition.


Question: } struct SelectionCandidateSet<'tcx> { <del> // A list of candidates that definitely apply to the current // obligation (meaning: types unify). </del> <ins> /// A list of candidates that definitely apply to the current /// obligation (meaning: types unify). </ins> vec: Vec<SelectionCandidate<'tcx>>, <del> // If `true`, then there were candidates that might or might // not have applied, but we couldn't tell. This occurs when some // of the input types are type variables, in which case there are // various "builtin" rules that might or might not trigger. </del> <ins> /// If `true`, then there were candidates that might or might /// not have applied, but we couldn't tell. This occurs when some /// of the input types are type variables, in which case there are /// various "builtin" rules that might or might not trigger. </ins> ambiguous: bool, }

Note: the below reduction originally came from a + in the wild. I haven't found a way to demonstrate this outside of the "float inference vars + method" combo, but: works on stable () and beta (), and errors on nightly with: Even though it doesn't show the source for candidate , I'm almost certain it's this: from (cc On the original PR I left comments like , trying to rectify the issues with the original approach, but they didn't go anywhere and the version that one in the end is the (arguably) more fragile original one, that uses blanket s and works around their unwanted interactions. It's possible in this case all it takes is checking for "float inference vars" and making sure they can never be considered to implement , but I'm worried there might be other edge cases lurking in the shadows. Also, did both of those PRs skip crater? I feel like this shouldn't be that hard to hit in the wild.
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: # FIXME: we should probe the default azure image and see if we can use the MSYS2 # toolchain there. (if there's even one there). For now though this gets the job # done. <del> - script: | set MSYS_PATH=%CD%citoolsmsys64 choco install msys2 --params="/InstallDir:%MSYS_PATH% /NoPath" -y set PATH=%MSYS_PATH%usrbin;%PATH% pacman -S --noconfirm --needed base-devel ca-certificates make diffutils tar IF "%MINGW_URL%"=="" ( IF "%MSYS_BITS%"=="32" pacman -S --noconfirm --needed mingw-w64-i686-toolchain mingw-w64-i686-cmake mingw-w64-i686-gcc mingw-w64-i686-python2 IF "%MSYS_BITS%"=="64" pacman -S --noconfirm --needed mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc mingw-w64-x86_64-python2 ) where rev rev --help where make echo ##vso[task.setvariable variable=MSYS_PATH]%MSYS_PATH% echo ##vso[task.prependpath]%MSYS_PATH%usrbin </del> <ins> - bash: | set -e choco install msys2 --params="/InstallDir:$(System.Workfolder)/msys2 /NoPath" -y --no-progress echo "##vso[task.prependpath]$(System.Workfolder)/msys2/usr/bin" mkdir -p "$(System.Workfolder)/msys2/home/$USERNAME" </ins> displayName: Install msys2 condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT')) <ins> - bash: pacman -S --noconfirm --needed base-devel ca-certificates make diffutils tar displayName: Install msys2 base deps condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT')) </ins> # If we need to download a custom MinGW, do so here and set the path # appropriately. #

The "Install MSYS2" step of failed, but the build kept going and failed later with obscure errors. We should fix this so that if msys2 installation fails the build fails immediately!


Question: --> $DIR/rustc-macro-transparency.rs:26:5 | LL |     Opaque; <del> |     ^^^^^^ help: a local variable with a similar name exists (notice the capitalization): `opaque` </del> <ins> |     ^^^^^^ not found in this scope </ins> error[E0423]: expected value, found macro `semitransparent` --> $DIR/rustc-macro-transparency.rs:29:5 | <ins> LL |     struct SemiTransparent; |     ----------------------- similarly named unit struct `SemiTransparent` defined here ... </ins> LL |     semitransparent; |     ^^^^^^^^^^^^^^^ not a value |

Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should include a note suggesting the variant with the same name (but different case):
label +C-enhancement +D-newcomer-roadblock
This only doesn't Just Work because the Levenshtein thing is case sensitive, right? There is some special-casing for case-insensitive suggestions but afaict it only applies if the case-sensitive Levenshtein distance is also already low, which seems wrong at first glance.
im working on this Edit: I'm not working on this anymore because I ran out of time getting past incremental compilation / llvm errors after a rebase.
Okay, judging by , this is explicitly not supposed to work. shrug emoji Edit: Okay, maybe that test case didn't really care. The use of case-insensitive match as tie breaker for equal levenshtein distance only was introduced with afaict.


Question: } } <del> let sp = span_of_attrs(attrs).from_inner(InnerSpan::new( </del> <ins> Some(span_of_attrs(attrs)?.from_inner(InnerSpan::new( </ins> md_range.start + start_bytes, md_range.end + start_bytes + end_bytes, <del> )); Some(sp) </del> <ins> ))) </ins> }

crashes on nightly () and also on stable () with "nightly" features turned on via . It does not trigger on stable without flag. Here is the output I'm getting: I created a small repro case + here: (it only happens when there is a certain combination of procedural macros, so I cannot make it a single file).
The source code is: with crate being a procedural macro crate with:
Couple of things that are important here: only happens with two procedural macros. macro has to do that . attribute has to be , does not reproduce with anything else.
Just a heads-up: AFAIK if a bug only occurs on stable with (I understand that it is not the case here), then it should probably be disregarded, because isn't supposed to be used when not bootstrapping the compiler.
The bug itself reminds me of
it happens on nightly as well. That detail was included to give context that evidently the ICE has been present for longer than 12 weeks, I believe.
With the following patch in the linked repo, the output is not ideal, but preferable to the ICE: I'll take a look to see if we can somehow keep the span for the entire attr doc, or at worst pointing at the correct macro.
Changing the patch to be gives us which makes more sense but is missing a primary span. Edit: I see no way to recover the original span after its has been modified. I guess we already rely on proc macro writers to be nice when it comes to spans, so this is acceptable as well.


Question: <ins> // Regression test for #80468. #![crate_type = "lib"] pub trait Trait {} #[repr(transparent)] pub struct Wrapper<T: Trait>(T); #[repr(transparent)] pub struct Ref<'a>(&'a u8); impl Trait for Ref {} //~ ERROR:  implicit elided lifetime not allowed here extern "C" { pub fn repro(_: Wrapper<Ref>); //~ ERROR: mismatched types } </ins>

Repro: As of current nightly: This is the unreachable line: The same crash reproduces back to 1.47.0. Older stable compilers do not crash:
Bisect: searched nightlies: from nightly-2020-07-10 to nightly-2020-08-27 regressed nightly: nightly-2020-07-22 searched commits: from to regressed commit: () Mentioning because appears the most relevant.
Assigning .


Question: #[expect(invalid_nan_comparisons)] //~^ WARNING this lint expectation is unfulfilled [unfulfilled_lint_expectations] <ins> //~| WARNING this lint expectation is unfulfilled [unfulfilled_lint_expectations] //~| NOTE duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` </ins> let _b = x == 5; } }

I tried this code: I expected to catch lint and suppress it, as it should. Instead, compiler issues a diagnostic both about unused value and unfulfilled lint expectation: It does work as expected though if is applied to function. I used the latest stable (Rust 1.81), but it is reproducible both on latest beta (2024-09-04 ) and latest nightly (2024-09-05 ). labels: +F-lintreasons, +A-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This issue is not limited to just . Others attrs like or don't work either. For instance, the following variant of the reproducer with replaced with emits the warning even though it shouldn't: Playground: This broken behaviour goes as far back as at least 2021 (couldn't build and test earlier rustc) We emit the lint on the HIR node corresponding to . However, the or levels, which are supposed to override the default level of the lint, are associated with or bound to the node underlying the as shown in the figure below: The end result is that the lint's level is never knocked down to or since when searching for levels we start from the node on which the lint is triggered and go up the chain of parents. So in this case we look for the level on and then on the and so on. We never look for it on the where the levels actually exist. As it happens in the lowered HIR does have the / attrs for both the node and its child node. However when adding the levels in the we do not add anything for the node as shown here (note the comment): If were to add the level for as well the issue will go away. However, if we do that we will still have one problem in the case of which is that we will end up with two expectations and the one on the will not be fullfilled and hence we will still see a warning about unfulfilled expectation. To prevent that I think we should take the following approach: when an attr like or etc.


Question: #[expect(invalid_nan_comparisons)] //~^ WARNING this lint expectation is unfulfilled [unfulfilled_lint_expectations] <ins> //~| WARNING this lint expectation is unfulfilled [unfulfilled_lint_expectations] //~| NOTE duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` </ins> let _b = x == 5; } }

are present for more than one HIR node in the and if one node is the (direct or indirect) parent of the other node, then add the level only_ for parent node. This will take care of any lints on the child (since we always walk up the HIR hierachy as mentioned earlier) as well as the parent and it will not cause any warnings about missed expectations. I am new to this area so if someone can review this idea or suggest alternatives that will be great. since you seemed to have worked in this area recently, can you please weigh in?
Your investigation is accurate, and the fix is simple: visit the statement node when building lint levels. Do you mind making such a pr ? I don't think we need any special adjustment for cases, duplicated attributes are already taken into account, but a test won't hurt.
Thanks . Yes, I'll put together a PR. My only concern is if all we do is add the level at , although it will work perfectly for , etc., in the case of we will end up with an unfulfilled expectation on the node which will appear to the user as a warning. But anyway let me have a go and see what happens.
Opened draft PR that adds the lint on . It does suffer from the extra warning problem.


Question: <del> # `macro_literal_matcher` The tracking issue for this feature is: [#35625] The RFC is: [rfc#1576]. With this feature gate enabled, the [list of designators] gains one more entry: * `literal`: a literal. Examples: 2, "string", 'c' A `literal` may be followed by anything, similarly to the `ident` specifier. [rfc#1576]: http://rust-lang.github.io/rfcs/1576-macros-literal-matcher.html [#35625]: https://github.com/rust-lang/rust/issues/35625 [list of designators]: ../reference/macros-by-example.html ------------------------ </del>

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


Question: <del> # `macro_literal_matcher` The tracking issue for this feature is: [#35625] The RFC is: [rfc#1576]. With this feature gate enabled, the [list of designators] gains one more entry: * `literal`: a literal. Examples: 2, "string", 'c' A `literal` may be followed by anything, similarly to the `ident` specifier. [rfc#1576]: http://rust-lang.github.io/rfcs/1576-macros-literal-matcher.html [#35625]: https://github.com/rust-lang/rust/issues/35625 [list of designators]: ../reference/macros-by-example.html ------------------------ </del>

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


Question: <del> # `macro_literal_matcher` The tracking issue for this feature is: [#35625] The RFC is: [rfc#1576]. With this feature gate enabled, the [list of designators] gains one more entry: * `literal`: a literal. Examples: 2, "string", 'c' A `literal` may be followed by anything, similarly to the `ident` specifier. [rfc#1576]: http://rust-lang.github.io/rfcs/1576-macros-literal-matcher.html [#35625]: https://github.com/rust-lang/rust/issues/35625 [list of designators]: ../reference/macros-by-example.html ------------------------ </del>

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


Question: <del> # `macro_literal_matcher` The tracking issue for this feature is: [#35625] The RFC is: [rfc#1576]. With this feature gate enabled, the [list of designators] gains one more entry: * `literal`: a literal. Examples: 2, "string", 'c' A `literal` may be followed by anything, similarly to the `ident` specifier. [rfc#1576]: http://rust-lang.github.io/rfcs/1576-macros-literal-matcher.html [#35625]: https://github.com/rust-lang/rust/issues/35625 [list of designators]: ../reference/macros-by-example.html ------------------------ </del>

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


Question: /// A specific scope in which a name can be looked up. /// This enum is currently used only for early resolution (imports and macros), /// but not for late resolution yet. <del> #[derive(Clone, Copy)] </del> <ins> #[derive(Clone, Copy, Debug)] </ins> enum Scope<'a> { DeriveHelpers(LocalExpnId), DeriveHelpersCompat,

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +S-bug-has-mcve
I'm having trouble understanding this ICE. Could someone point me in the right direction? Thanks for your help!
release-assignment I'm finding this quite hard. For anyone else: I suspect is responsible.


Question: pub use crate::sys_common::fs::remove_dir_all; } <del> // Dynamically choose implementation Macos x86-64: modern for 10.10+, fallback for older versions #[cfg(all(target_os = "macos", target_arch = "x86_64"))] </del> <ins> // Modern implementation using openat(), unlinkat() and fdopendir() #[cfg(not(any(target_os = "redox", target_os = "espidf")))] </ins> mod remove_dir_impl { <del> use super::{cstr, lstat, Dir, InnerReadDir, ReadDir}; </del> <ins> use super::{cstr, lstat, Dir, DirEntry, InnerReadDir, ReadDir}; </ins> use crate::ffi::CStr; use crate::io; use crate::os::unix::io::{AsRawFd, FromRawFd, IntoRawFd}; use crate::os::unix::prelude::{OwnedFd, RawFd}; use crate::path::{Path, PathBuf}; use crate::sync::Arc; <del> use crate::sys::weak::weak; </del> use crate::sys::{cvt, cvt_r}; <del> use libc::{c_char, c_int, DIR}; pub fn openat_nofollow_dironly(parent_fd: Option<RawFd>, p: &CStr) -> io::Result<OwnedFd> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); let fd = cvt_r(|| unsafe { openat.get().unwrap()( parent_fd.unwrap_or(libc::AT_FDCWD), p.as_ptr(), libc::O_CLOEXEC | libc::O_RDONLY | libc::O_NOFOLLOW | libc::O_DIRECTORY, ) })?; Ok(unsafe { OwnedFd::from_raw_fd(fd) }) } fn fdreaddir(dir_fd: OwnedFd) -> io::Result<(ReadDir, RawFd)> { weak!(fn fdopendir(c_int) -> *mut DIR, "fdopendir$INODE64"); let ptr = unsafe { fdopendir.get().unwrap()(dir_fd.as_raw_fd()) }; if ptr.is_null() { return Err(io::Error::last_os_error()); } let dirp = Dir(ptr); // file descriptor is automatically closed by libc::closedir() now, so give up ownership let new_parent_fd = dir_fd.into_raw_fd(); // a valid root is not needed because we do not call any functions involving the full path // of the DirEntrys. let dummy_root = PathBuf::new(); Ok(( ReadDir { inner: Arc::new(InnerReadDir { dirp, root: dummy_root }), end_of_stream: false, }, new_parent_fd, )) } fn remove_dir_all_recursive(parent_fd: Option<RawFd>, p: &Path) -> io::Result<()> { weak!(fn unlinkat(c_int, *const c_char, c_int) -> c_int); </del> <ins> #[cfg(not(all(target_os = "macos", target_arch = "x86_64"),))] use libc::{fdopendir, openat, unlinkat}; #[cfg(all(target_os = "macos", target_arch = "x86_64"))] use macos_weak::{fdopendir, openat, unlinkat}; </ins> <del> let pcstr = cstr(p)?; </del> <ins> #[cfg(all(target_os = "macos", target_arch = "x86_64"))] mod macos_weak { use crate::sys::weak::weak; use libc::{c_char, c_int, DIR}; </ins> <del> // entry is expected to be a directory, open as such let fd = openat_nofollow_dironly(parent_fd, &pcstr)?; </del> <ins> fn get_openat_fn() -> Option<unsafe extern "C" fn(c_int, *const c_char, c_int) -> c_int> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); openat.get() } </ins> <del> // open the directory passing ownership of the fd let (dir, fd) = fdreaddir(fd)?; for child in dir { let child = child?; match child.entry.d_type { libc::DT_DIR => { remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } libc::DT_UNKNOWN => { match cvt(unsafe { unlinkat.get().unwrap()(fd, child.name_cstr().as_ptr(), 0) }) { // type unknown - try to unlink Err(err) if err.raw_os_error() == Some(libc::EPERM) => { // if the file is a directory unlink fails with EPERM remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } result => { result?; } } } _ => { // not a directory -> unlink cvt(unsafe { unlinkat.get().unwrap()(fd, child.name_cstr().as_ptr(), 0) })?; } } </del> <ins> pub fn has_openat() -> bool { get_openat_fn().is_some() </ins> } <del> // unlink the directory after removing its contents cvt(unsafe { unlinkat.get().unwrap()( parent_fd.unwrap_or(libc::AT_FDCWD), pcstr.as_ptr(), libc::AT_REMOVEDIR, ) })?; Ok(()) } </del> <ins> pub unsafe fn openat(dirfd: c_int, pathname: *const c_char, flags: c_int) -> c_int { get_openat_fn().map(|openat| openat(dirfd, pathname, flags)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); -1 }) } </ins> <del> fn remove_dir_all_modern(p: &Path) -> io::Result<()> { // We cannot just call remove_dir_all_recursive() here because that would not delete a passed // symlink. No need to worry about races, because remove_dir_all_recursive() does not recurse // into symlinks. let attr = lstat(p)?; if attr.file_type().is_symlink() { crate::fs::remove_file(p) } else { remove_dir_all_recursive(None, p) </del> <ins> pub unsafe fn fdopendir(fd: c_int) -> *mut DIR { weak!(fn fdopendir(c_int) -> *mut DIR, "fdopendir$INODE64"); fdopendir.get().map(|fdopendir| fdopendir(fd)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); crate::ptr::null_mut() }) </ins> } <del> } pub fn remove_dir_all(p: &Path) -> io::Result<()> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); if openat.get().is_some() { // openat() is available with macOS 10.10+, just like unlinkat() and fdopendir() remove_dir_all_modern(p) } else { // fall back to classic implementation crate::sys_common::fs::remove_dir_all(p) </del> <ins> pub unsafe fn unlinkat(dirfd: c_int, pathname: *const c_char, flags: c_int) -> c_int { weak!(fn unlinkat(c_int, *const c_char, c_int) -> c_int); unlinkat.get().map(|unlinkat| unlinkat(dirfd, pathname, flags)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); -1 }) </ins> } } <del> } // Modern implementation using openat(), unlinkat() and fdopendir() #[cfg(not(any( all(target_os = "macos", target_arch = "x86_64"), target_os = "redox", target_os = "espidf" )))] mod remove_dir_impl { use super::{cstr, lstat, Dir, DirEntry, InnerReadDir, ReadDir}; use crate::ffi::CStr; use crate::io; use crate::os::unix::io::{AsRawFd, FromRawFd, IntoRawFd}; use crate::os::unix::prelude::{OwnedFd, RawFd}; use crate::path::{Path, PathBuf}; use crate::sync::Arc; use crate::sys::{cvt, cvt_r}; use libc::{fdopendir, openat, unlinkat}; </del> pub fn openat_nofollow_dironly(parent_fd: Option<RawFd>, p: &CStr) -> io::Result<OwnedFd> { let fd = cvt_r(|| unsafe {

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


Question: pub use crate::sys_common::fs::remove_dir_all; } <del> // Dynamically choose implementation Macos x86-64: modern for 10.10+, fallback for older versions #[cfg(all(target_os = "macos", target_arch = "x86_64"))] </del> <ins> // Modern implementation using openat(), unlinkat() and fdopendir() #[cfg(not(any(target_os = "redox", target_os = "espidf")))] </ins> mod remove_dir_impl { <del> use super::{cstr, lstat, Dir, InnerReadDir, ReadDir}; </del> <ins> use super::{cstr, lstat, Dir, DirEntry, InnerReadDir, ReadDir}; </ins> use crate::ffi::CStr; use crate::io; use crate::os::unix::io::{AsRawFd, FromRawFd, IntoRawFd}; use crate::os::unix::prelude::{OwnedFd, RawFd}; use crate::path::{Path, PathBuf}; use crate::sync::Arc; <del> use crate::sys::weak::weak; </del> use crate::sys::{cvt, cvt_r}; <del> use libc::{c_char, c_int, DIR}; pub fn openat_nofollow_dironly(parent_fd: Option<RawFd>, p: &CStr) -> io::Result<OwnedFd> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); let fd = cvt_r(|| unsafe { openat.get().unwrap()( parent_fd.unwrap_or(libc::AT_FDCWD), p.as_ptr(), libc::O_CLOEXEC | libc::O_RDONLY | libc::O_NOFOLLOW | libc::O_DIRECTORY, ) })?; Ok(unsafe { OwnedFd::from_raw_fd(fd) }) } fn fdreaddir(dir_fd: OwnedFd) -> io::Result<(ReadDir, RawFd)> { weak!(fn fdopendir(c_int) -> *mut DIR, "fdopendir$INODE64"); let ptr = unsafe { fdopendir.get().unwrap()(dir_fd.as_raw_fd()) }; if ptr.is_null() { return Err(io::Error::last_os_error()); } let dirp = Dir(ptr); // file descriptor is automatically closed by libc::closedir() now, so give up ownership let new_parent_fd = dir_fd.into_raw_fd(); // a valid root is not needed because we do not call any functions involving the full path // of the DirEntrys. let dummy_root = PathBuf::new(); Ok(( ReadDir { inner: Arc::new(InnerReadDir { dirp, root: dummy_root }), end_of_stream: false, }, new_parent_fd, )) } fn remove_dir_all_recursive(parent_fd: Option<RawFd>, p: &Path) -> io::Result<()> { weak!(fn unlinkat(c_int, *const c_char, c_int) -> c_int); </del> <ins> #[cfg(not(all(target_os = "macos", target_arch = "x86_64"),))] use libc::{fdopendir, openat, unlinkat}; #[cfg(all(target_os = "macos", target_arch = "x86_64"))] use macos_weak::{fdopendir, openat, unlinkat}; </ins> <del> let pcstr = cstr(p)?; </del> <ins> #[cfg(all(target_os = "macos", target_arch = "x86_64"))] mod macos_weak { use crate::sys::weak::weak; use libc::{c_char, c_int, DIR}; </ins> <del> // entry is expected to be a directory, open as such let fd = openat_nofollow_dironly(parent_fd, &pcstr)?; </del> <ins> fn get_openat_fn() -> Option<unsafe extern "C" fn(c_int, *const c_char, c_int) -> c_int> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); openat.get() } </ins> <del> // open the directory passing ownership of the fd let (dir, fd) = fdreaddir(fd)?; for child in dir { let child = child?; match child.entry.d_type { libc::DT_DIR => { remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } libc::DT_UNKNOWN => { match cvt(unsafe { unlinkat.get().unwrap()(fd, child.name_cstr().as_ptr(), 0) }) { // type unknown - try to unlink Err(err) if err.raw_os_error() == Some(libc::EPERM) => { // if the file is a directory unlink fails with EPERM remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } result => { result?; } } } _ => { // not a directory -> unlink cvt(unsafe { unlinkat.get().unwrap()(fd, child.name_cstr().as_ptr(), 0) })?; } } </del> <ins> pub fn has_openat() -> bool { get_openat_fn().is_some() </ins> } <del> // unlink the directory after removing its contents cvt(unsafe { unlinkat.get().unwrap()( parent_fd.unwrap_or(libc::AT_FDCWD), pcstr.as_ptr(), libc::AT_REMOVEDIR, ) })?; Ok(()) } </del> <ins> pub unsafe fn openat(dirfd: c_int, pathname: *const c_char, flags: c_int) -> c_int { get_openat_fn().map(|openat| openat(dirfd, pathname, flags)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); -1 }) } </ins> <del> fn remove_dir_all_modern(p: &Path) -> io::Result<()> { // We cannot just call remove_dir_all_recursive() here because that would not delete a passed // symlink. No need to worry about races, because remove_dir_all_recursive() does not recurse // into symlinks. let attr = lstat(p)?; if attr.file_type().is_symlink() { crate::fs::remove_file(p) } else { remove_dir_all_recursive(None, p) </del> <ins> pub unsafe fn fdopendir(fd: c_int) -> *mut DIR { weak!(fn fdopendir(c_int) -> *mut DIR, "fdopendir$INODE64"); fdopendir.get().map(|fdopendir| fdopendir(fd)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); crate::ptr::null_mut() }) </ins> } <del> } pub fn remove_dir_all(p: &Path) -> io::Result<()> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); if openat.get().is_some() { // openat() is available with macOS 10.10+, just like unlinkat() and fdopendir() remove_dir_all_modern(p) } else { // fall back to classic implementation crate::sys_common::fs::remove_dir_all(p) </del> <ins> pub unsafe fn unlinkat(dirfd: c_int, pathname: *const c_char, flags: c_int) -> c_int { weak!(fn unlinkat(c_int, *const c_char, c_int) -> c_int); unlinkat.get().map(|unlinkat| unlinkat(dirfd, pathname, flags)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); -1 }) </ins> } } <del> } // Modern implementation using openat(), unlinkat() and fdopendir() #[cfg(not(any( all(target_os = "macos", target_arch = "x86_64"), target_os = "redox", target_os = "espidf" )))] mod remove_dir_impl { use super::{cstr, lstat, Dir, DirEntry, InnerReadDir, ReadDir}; use crate::ffi::CStr; use crate::io; use crate::os::unix::io::{AsRawFd, FromRawFd, IntoRawFd}; use crate::os::unix::prelude::{OwnedFd, RawFd}; use crate::path::{Path, PathBuf}; use crate::sync::Arc; use crate::sys::{cvt, cvt_r}; use libc::{fdopendir, openat, unlinkat}; </del> pub fn openat_nofollow_dironly(parent_fd: Option<RawFd>, p: &CStr) -> io::Result<OwnedFd> { let fd = cvt_r(|| unsafe {

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


Question: pub use crate::sys_common::fs::remove_dir_all; } <del> // Dynamically choose implementation Macos x86-64: modern for 10.10+, fallback for older versions #[cfg(all(target_os = "macos", target_arch = "x86_64"))] </del> <ins> // Modern implementation using openat(), unlinkat() and fdopendir() #[cfg(not(any(target_os = "redox", target_os = "espidf")))] </ins> mod remove_dir_impl { <del> use super::{cstr, lstat, Dir, InnerReadDir, ReadDir}; </del> <ins> use super::{cstr, lstat, Dir, DirEntry, InnerReadDir, ReadDir}; </ins> use crate::ffi::CStr; use crate::io; use crate::os::unix::io::{AsRawFd, FromRawFd, IntoRawFd}; use crate::os::unix::prelude::{OwnedFd, RawFd}; use crate::path::{Path, PathBuf}; use crate::sync::Arc; <del> use crate::sys::weak::weak; </del> use crate::sys::{cvt, cvt_r}; <del> use libc::{c_char, c_int, DIR}; pub fn openat_nofollow_dironly(parent_fd: Option<RawFd>, p: &CStr) -> io::Result<OwnedFd> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); let fd = cvt_r(|| unsafe { openat.get().unwrap()( parent_fd.unwrap_or(libc::AT_FDCWD), p.as_ptr(), libc::O_CLOEXEC | libc::O_RDONLY | libc::O_NOFOLLOW | libc::O_DIRECTORY, ) })?; Ok(unsafe { OwnedFd::from_raw_fd(fd) }) } fn fdreaddir(dir_fd: OwnedFd) -> io::Result<(ReadDir, RawFd)> { weak!(fn fdopendir(c_int) -> *mut DIR, "fdopendir$INODE64"); let ptr = unsafe { fdopendir.get().unwrap()(dir_fd.as_raw_fd()) }; if ptr.is_null() { return Err(io::Error::last_os_error()); } let dirp = Dir(ptr); // file descriptor is automatically closed by libc::closedir() now, so give up ownership let new_parent_fd = dir_fd.into_raw_fd(); // a valid root is not needed because we do not call any functions involving the full path // of the DirEntrys. let dummy_root = PathBuf::new(); Ok(( ReadDir { inner: Arc::new(InnerReadDir { dirp, root: dummy_root }), end_of_stream: false, }, new_parent_fd, )) } fn remove_dir_all_recursive(parent_fd: Option<RawFd>, p: &Path) -> io::Result<()> { weak!(fn unlinkat(c_int, *const c_char, c_int) -> c_int); </del> <ins> #[cfg(not(all(target_os = "macos", target_arch = "x86_64"),))] use libc::{fdopendir, openat, unlinkat}; #[cfg(all(target_os = "macos", target_arch = "x86_64"))] use macos_weak::{fdopendir, openat, unlinkat}; </ins> <del> let pcstr = cstr(p)?; </del> <ins> #[cfg(all(target_os = "macos", target_arch = "x86_64"))] mod macos_weak { use crate::sys::weak::weak; use libc::{c_char, c_int, DIR}; </ins> <del> // entry is expected to be a directory, open as such let fd = openat_nofollow_dironly(parent_fd, &pcstr)?; </del> <ins> fn get_openat_fn() -> Option<unsafe extern "C" fn(c_int, *const c_char, c_int) -> c_int> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); openat.get() } </ins> <del> // open the directory passing ownership of the fd let (dir, fd) = fdreaddir(fd)?; for child in dir { let child = child?; match child.entry.d_type { libc::DT_DIR => { remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } libc::DT_UNKNOWN => { match cvt(unsafe { unlinkat.get().unwrap()(fd, child.name_cstr().as_ptr(), 0) }) { // type unknown - try to unlink Err(err) if err.raw_os_error() == Some(libc::EPERM) => { // if the file is a directory unlink fails with EPERM remove_dir_all_recursive(Some(fd), Path::new(&child.file_name()))?; } result => { result?; } } } _ => { // not a directory -> unlink cvt(unsafe { unlinkat.get().unwrap()(fd, child.name_cstr().as_ptr(), 0) })?; } } </del> <ins> pub fn has_openat() -> bool { get_openat_fn().is_some() </ins> } <del> // unlink the directory after removing its contents cvt(unsafe { unlinkat.get().unwrap()( parent_fd.unwrap_or(libc::AT_FDCWD), pcstr.as_ptr(), libc::AT_REMOVEDIR, ) })?; Ok(()) } </del> <ins> pub unsafe fn openat(dirfd: c_int, pathname: *const c_char, flags: c_int) -> c_int { get_openat_fn().map(|openat| openat(dirfd, pathname, flags)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); -1 }) } </ins> <del> fn remove_dir_all_modern(p: &Path) -> io::Result<()> { // We cannot just call remove_dir_all_recursive() here because that would not delete a passed // symlink. No need to worry about races, because remove_dir_all_recursive() does not recurse // into symlinks. let attr = lstat(p)?; if attr.file_type().is_symlink() { crate::fs::remove_file(p) } else { remove_dir_all_recursive(None, p) </del> <ins> pub unsafe fn fdopendir(fd: c_int) -> *mut DIR { weak!(fn fdopendir(c_int) -> *mut DIR, "fdopendir$INODE64"); fdopendir.get().map(|fdopendir| fdopendir(fd)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); crate::ptr::null_mut() }) </ins> } <del> } pub fn remove_dir_all(p: &Path) -> io::Result<()> { weak!(fn openat(c_int, *const c_char, c_int) -> c_int); if openat.get().is_some() { // openat() is available with macOS 10.10+, just like unlinkat() and fdopendir() remove_dir_all_modern(p) } else { // fall back to classic implementation crate::sys_common::fs::remove_dir_all(p) </del> <ins> pub unsafe fn unlinkat(dirfd: c_int, pathname: *const c_char, flags: c_int) -> c_int { weak!(fn unlinkat(c_int, *const c_char, c_int) -> c_int); unlinkat.get().map(|unlinkat| unlinkat(dirfd, pathname, flags)).unwrap_or_else(|| { crate::sys::unix::os::set_errno(libc::ENOSYS); -1 }) </ins> } } <del> } // Modern implementation using openat(), unlinkat() and fdopendir() #[cfg(not(any( all(target_os = "macos", target_arch = "x86_64"), target_os = "redox", target_os = "espidf" )))] mod remove_dir_impl { use super::{cstr, lstat, Dir, DirEntry, InnerReadDir, ReadDir}; use crate::ffi::CStr; use crate::io; use crate::os::unix::io::{AsRawFd, FromRawFd, IntoRawFd}; use crate::os::unix::prelude::{OwnedFd, RawFd}; use crate::path::{Path, PathBuf}; use crate::sync::Arc; use crate::sys::{cvt, cvt_r}; use libc::{fdopendir, openat, unlinkat}; </del> pub fn openat_nofollow_dironly(parent_fd: Option<RawFd>, p: &CStr) -> io::Result<OwnedFd> { let fd = cvt_r(|| unsafe {

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


Question: BufWriter { inner: Some(inner), buf: Vec::with_capacity(cap), <ins> panicked: false, </ins> } }

There is a panic safety issue in : after a call panics, the impl of calls again, which means the buffer contents are potentially written twice. This may cause an application to overwrite parts of a file that it did not mean to overwrite (in a DB engine written in Rust, this could cause unrecoverable data corruption!). Demonstration: The expected output of the demo program is , the actual output is: More generally, we need a story for panic safety in Rust. My takeaway from the related discussions (e.g. , , the trait) was that only code and impls should have to worry about panic safety. The demo app contains none of these, so I'd consider this a bug in . (otherwise all implementations would need to provide the strong exception safety guarantee?) Solution: could use temporarily mark the buffer as empty during the calls; so that the impl doesn't do anything after a panic. However, this doesn't help if the panic occurs during a call...
Note that Rust is normally referring to "memory safety" when talking about safety, so the issue here isn't in conflict with the related discussions. It's definitely a bug in , but I want to point out how specific it is here: the only reason you have odd behaviour is because you have a implementation that will panic after successfully writing the data it is given. I'm all for making more robust, but it's not just "if the call panics", it's "if the call panics after successfully writing data". Panicking before a successful write (or if the write fails), would not have the same issue.
If your impl is panicking in the middle of a write, it seems to me like you're in data corruption land with or without a second write. This is not quite the case - and thread locals expand that surface area. What's specifically the expected behavior here? Is the implementation specifically the thing that needs tweaking, or should the totally poison itself? For reference, Java's class has no special handling for exceptions thrown from the inner : , so adjusting alone seems like a reasonable route to take.
Without the , a panic in the middle of a write (without ) only corrupts the part of the file that the application meant to overwrite. In a DB engine context, that means the resulting corruption can be repaired when the transaction is rolled back.


Question: BufWriter { inner: Some(inner), buf: Vec::with_capacity(cap), <ins> panicked: false, </ins> } }

But with , a panic after some data was written might corrupt parts of the file that are not saved in the rollback journal, so recovery not possible. I think we need some guideline like: If a method call panics, it's a bug to call any additional methods on the same object. Thus, the bug is in . may need something similar to a poison-flag so that the impl can detect whether a previous call panicked, but it doesn't need to protect against it's own methods being called after a panic (that would be considered a bug in the caller). The Java has the same problem, but the expectation in the Java world is different: it's trivially possible to catch an exception and continue using the potentially-invalid state; so in Java's case I would argue that all implementations should provide the strong exception safety guarantee to avoid this kind of issue. Essentially, the Rust world needs to decide between a Java/C++-style "strong exception safety guarantee" (=failing method call should not have any side effects) or a new "no-use-after-panic guarantee" (=after a failing method call, no additional method calls should occur). Some types (like BufWriter) can be compatible with at most one of the guarantees -- strong exception safety requires that a panicking call has no side effects; no-use-after-panic requires that a panicking call has the side effect of suppressing the buffer flush in the impl. The trait seems to be roughly equivalent to basic exception safety. Types that do not implement instead live in the world. Generic types implementing need to be careful not to call any functions on the type parameter from within the implementation if a previous call panicked (unless they use a bound).
triage: P-medium is fixing the data corruption in


Question: <del> error[E0658]: trait upcasting coercion is experimental </del> <ins> error[E0658]: cannot cast `dyn Fn()` to `dyn FnMut()`, trait upcasting coercion is experimental </ins> --> $DIR/issue-11515.rs:9:33 | LL |     let test = box Test { func: closure };

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --It should name the traits are attempted to be coerced, maybe tell me why that's not allowed (yet), etc. Right now it just highlights the entire line. The original example I had that made me run into this issue had an even longer expression there (multiple chained iterator methods) which just got all highlighted as one big block saying "somewhere here trait coercion is used and it's not allowed". Note that I understand why it's not allowed, I was just disappointed by the error message. I already talked to about this, and they also thought this output may be problematic. Even though the feature may be unstable, it's quite easy to arrive at a situation where you may get this error. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: <ins> error[E0433]: failed to resolve: there are too many leading `super` keywords --> $DIR/issue-117920.rs:3:5 | LL | use super::A; |     ^^^^^ there are too many leading `super` keywords error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0433`. </ins>

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


Question: <ins> // Copyright 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. // ignore-pretty #27582 // Check that when a `let`-binding occurs in a loop, its associated // drop-flag is reinitialized (to indicate "needs-drop" at the end of // the owning variable's scope). struct A<'a>(&'a mut i32); impl<'a> Drop for A<'a> { fn drop(&mut self) { *self.0 += 1; } } fn main() { let mut cnt = 0; for i in 0..2 { let a = A(&mut cnt); if i == 1 { // Note that break;  //  both this break }           //   and also drop(a);    //    this move of `a` // are necessary to expose the bug } assert_eq!(cnt, 2); } </ins>

It looks like that when a local variable is initialized in a loop and dropped in the same loop, the stack local drop flag for that local isn't reinitialized to "not dropped" when the loop runs after the first time. Concretely, this test passes on stable and fails on nightly right now: cc
Interestingly this slight variation on the above code does drop twice as expected:


Question: // except according to those terms. // run-pass <del> #![feature(macro_literal_matcher)] </del> macro_rules! mtester { ($l:literal) => {


Question: // except according to those terms. // run-pass <del> #![feature(macro_literal_matcher)] </del> macro_rules! mtester { ($l:literal) => {


Question: // except according to those terms. // run-pass <del> #![feature(macro_literal_matcher)] </del> macro_rules! mtester { ($l:literal) => {


Question: // except according to those terms. // run-pass <del> #![feature(macro_literal_matcher)] </del> macro_rules! mtester { ($l:literal) => {


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

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.


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

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.


Question: // `PathSegment`, for which there is no associated `'_` or `&T` with no explicit // lifetime. Instead, we simply create an implicit lifetime, which will be checked // later, at which point a suitable error will be emitted. <del> LifetimeRibKind::AnonymousPassThrough(..) | LifetimeRibKind::AnonymousReportError | LifetimeRibKind::Item => break, </del> <ins> LifetimeRibKind::AnonymousPassThrough(binder) => { res = LifetimeRes::Anonymous { binder, elided: true }; break; } LifetimeRibKind::AnonymousReportError | LifetimeRibKind::Item => { // FIXME(cjgillot) This resolution is wrong, but this does not matter // since these cases are erroneous anyway.  Lifetime resolution should // emit a "missing lifetime specifier" diagnostic. res = LifetimeRes::Anonymous { binder: DUMMY_NODE_ID, elided: true }; break; } </ins> _ => {} } } <del> let res = if error { LifetimeRes::Error } else { LifetimeRes::Anonymous { binder: segment_id, elided: true } }; </del> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id,

I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.


Question: assert_eq!(ys, [1, 2, 3]); } <ins> #[test] fn test_box_slice_clone() { let data = vec![vec![0, 1], vec![0], vec![1]]; let data2 = data.clone().into_boxed_slice().clone().to_vec(); assert_eq!(data, data2); } #[test] fn test_box_slice_clone_panics() { use std::sync::Arc; use std::sync::atomic::{AtomicUsize, Ordering}; use std::thread::spawn; struct Canary { count: Arc<AtomicUsize>, panics: bool } impl Drop for Canary { fn drop(&mut self) { self.count.fetch_add(1, Ordering::SeqCst); } } impl Clone for Canary { fn clone(&self) -> Self { if self.panics { panic!() } Canary { count: self.count.clone(), panics: self.panics } } } let drop_count = Arc::new(AtomicUsize::new(0)); let canary = Canary { count: drop_count.clone(), panics: false }; let panic = Canary { count: drop_count.clone(), panics: true }; spawn(move || { // When xs is dropped, +5. let xs = vec![canary.clone(), canary.clone(), canary.clone(), panic, canary].into_boxed_slice(); // When panic is cloned, +3. xs.clone(); }).join().unwrap_err(); // Total = 8 assert_eq!(drop_count.load(Ordering::SeqCst), 8); } </ins> mod bench { use std::iter::repeat; use std::{mem, ptr};

We need to find a way to implement Clone for where . In user code, "cloning" such a box manually is simple: will do it with a short roundtrip through which should be unproblematic. In the rust distribution, we can't impl Clone easily since the tools to do so are in libcollections but the Box type lives in liballoc.
You do not need vec for the implementation. Something like the following would work: Note that because can panic it is required to keep track of the partial result so the correct stuff is dropped.
Yes, that's nice that it can be carefully solved by essentially extracting the needed parts from what Vec does. But the Box code is otherwise so clean, it doesn't feel like the right way to do it.
You're welcome to suggest an alternative but I doubt it can be done in a manner that is both correct and significantly cleaner :)
Your fundamental analysis is great: just isn't an exception safe representation while filling it with elements. It needs to keep track of the fill level, so a representation like Vec or BoxBuild is needed...
Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple memcpy of the data.


Question: = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> <del> error: aborting due to 47 previous errors </del> <ins> error: any use of this value will cause an error --> $DIR/const-int-unchecked.rs:191:25 | LL | const _: u32 = unsafe { std::intrinsics::ctlz_nonzero(0) }; | ------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--- |                         | |                         `ctlz_nonzero` called on 0 | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: any use of this value will cause an error --> $DIR/const-int-unchecked.rs:194:25 | LL | const _: u32 = unsafe { std::intrinsics::cttz_nonzero(0) }; | ------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--- |                         | |                         `cttz_nonzero` called on 0 | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> error: aborting due to 49 previous errors </ins>

Tracking issue for trailingzeros and leadingzeros for non zero types as introduced by . The feature gate for the issue is . On many architectures, this functions can perform better than trailingzeros/leading_zeros on the underlying integer type, as special handling of zero can be avoided.
It seems on my (common) architecture it doesn't give an advantage: : : So the question is: is this NonZero method worth keeping? Are the architectures where it gives a performance advantage common enough?
but as you show in your example if you want to make a distributable binary and due to this not set the target-cpu there is a big difference
The architecture I'm using is quite standard. A distributable binary could probably use it as "universal target". I don't know much common is going to be an instruction like tzcnt in the future. If you think a similar instruction will be sufficiently uncommon then please ignore my comments here :-)
merge cc
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
started to make the stabilization PR but hit a problem I think that constcttz needs to be stabilized for this to be stabilized from //! If an intrinsic is supposed to be used from a with a attribute, //! the intrinsic's attribute must be , too. Such a change should not be done //! without T-lang consulation, because it bakes a feature into the language that cannot be //! replicated in user code without compiler support.


Question: assert_eq!(vec![1; 2], vec![1, 1]); assert_eq!(vec![1; 1], vec![1]); assert_eq!(vec![1; 0], vec![]); <ins> // from_elem syntax (see RFC 832) let el = Box::new(1); let n = 3; assert_eq!(vec![el; n], vec![Box::new(1), Box::new(1), Box::new(1)]); </ins> }

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


Question: use rustc_hir::def::{self, DefKind, NonMacroAttrKind}; use rustc_hir::def_id; use rustc_middle::middle::stability; <del> use rustc_middle::{span_bug, ty}; </del> <ins> use rustc_middle::ty; </ins> use rustc_session::lint::builtin::UNUSED_MACROS; use rustc_session::Session; use rustc_span::edition::Edition;

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Seems to have regressed in Rust 1.33 based on testing in Godbolt.
With only the errors relevant to the ICE:
I'll fix this.
Fixed in


Question: <ins> error: requires `generator` lang_item error: aborting due to previous error </ins>

This somehow doesn't occur when putting the function in a non crate, yet I can't find any difference between the version of and this one. () Errors:
Seems like it panic when the trait is not found: Maybe it can use  instead.


Question: <ins> // In rustc_typeck::check::expr::no_such_field_err we recursively // look in subfields for the field. This recursive search is limited // in depth for compile-time reasons and to avoid infinite recursion // in case of cycles. This file tests that the limit in the recursion // depth is enforced. struct Foo { first: Bar, second: u32, third: u32, } struct Bar { bar: C, } struct C { c: D, } struct D { test: E, } struct E { e: F, } struct F { f: u32, } fn main() { let f = F { f: 6 }; let e = E { e: f }; let d = D { test: e }; let c = C { c: d }; let bar = Bar { bar: c }; let fooer = Foo { first: bar, second: 4, third: 5 }; let test = fooer.f; //~^ ERROR no field } </ins>

I just encountered this output: We currently mention available fields when the field used isn't found. It would be nice if we peeked at the types for the available fields to see if any of them has any fields (including through deref) of the name we originally wanted. In this case, I would love to see the following output: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll work on this. claim
I was just about to open a PR when I saw that you claimed the issue. It's my fault for not claiming this issue myself obviously, so if you've already been investing time into this the issue its still yours, but if you haven't can I open a PR for this?
I've done nothing yet as I planned to work on this tomorrow morning, so this is yours :)
release-assignment
if you're still interested in contributing, it seems to me that might be similar in scope and section of the codebase you could work in.
Thank you.


Question: <ins> // run-rustfix fn main() { let a: usize = 123; let b: &usize = &a; if true { a } else { b //~ ERROR `if` and `else` have incompatible types [E0308] }; if true { 1 } else { &1 //~ ERROR `if` and `else` have incompatible types [E0308] }; if true { 1 } else { &mut 1 //~ ERROR `if` and `else` have incompatible types [E0308] }; } </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: I expected that the help text would give syntactically correct code, or that there would be no help text. Instead, this happened: The provided code snippet is not valid - it tries to deference the else-block, which is impossible. Better would be to put the inside the else-block. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Also occurs on stable, 1.50.0. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I have a fix for this bug + an improvement. Gotta got for now but will submit the PR later today.


Question: <ins> // rust-lang/rust#60654: Do not ICE on an attempt to use GATs that is // missing the feature gate. struct Foo; impl Iterator for Foo { type Item<'b> = &'b Foo; //~ ERROR generic associated types are unstable [E0658] fn next(&mut self) -> Option<Self::Item> { None } } fn main() { } </ins>

The following minimal example causes an internal compiler error. Error in question: rustc version: This error was encountered on stable, but I can confirm that it also occurs on the latest nightly ().
Hasn't the feature gate issue been fixed? :|
I've removed the nomination and this to the tracking issue for GATs . The current impl is highly incomplete and ICEs are, sadly, expected. Also, I verified that a feature gate is indeed required.
triage: P-medium
I don't know if I get you wrong, but the example above ICEs on stable, beta and nightly without feature gate
oops, looks like I accidentally left the feature gate in there when I tried it out, but it produces the same ICE when it is omitted as well.
No, niko edited your question. ping I think you got something wrong there. Can you please clarify that?
Oh, I guess I was indeed incorreect. I tried it on play but didn't notice that, after the "correct" error, it goes on to print an ICE.
What about adding the I-nominated tag again?
I'm not sure why we would nominate this for discussion. Yes, it is an ICE (and an ICE that occurs without the user adding a feature gate), but the message pretty clearly states that you're using an unstable feature. It would be great to fix it so that it issues the error diagnostic without ICEing, but I wouldn't re-prioritize that work above P-medium.
assigning to self since its a clear annoyance
triage: P-medium. (dupe of )
(the remaining bug, when the feature gate is enabled, is tracked in issue )