Question: - [You can now use `#[repr(transparent)]` on univariant `enum`s.][68122] Meaning that you can create an enum that has the exact layout and ABI of the type it contains. <del> - [You can now use outer attribute procedural macros on inline modules.][64273] </del> <ins> - [You can now use outer attribute procedural macros on inline modules.][64273] </ins> - [There are some *syntax-only* changes:][67131] - `default` is syntactically allowed before items in `trait` definitions. - Items in `impl`s (i.e. `const`s, `type`s, and `fn`s) may syntactically

edit end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master# name=issue-
:rotatinglight: Error: failed to parse the command :sos: If you have any trouble with Crater please ping ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
name=issue- end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master#
:rotatinglight: Error: it's only possible to edit queued experiments :sos: If you have any trouble with Crater please ping ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
retry
:hammerandwrench: Experiment queued again. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
name=issue- end=masterc1ac408d93bb7adaa3a51dabab9266e82eee8 start=master#
:memo: Configuration of the experiment changed. :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:construction: Experiment is now running :information_source: Crater is a tool to run experiments across parts of the Rust ecosystem.
:tada: Experiment is completed! :barchart: 56 regressed and 14 fixed ( total) :newspaper: . :warning: If you notice any spurious failure ! :informationsource: Crater is a tool to run experiments across parts of the Rust ecosystem.
All of the new failures that weren't in the previous report seem to come from , which is already fixed.
And it seems it's only 2 new crates that depend on this version of . So while post-monomorphization errors are tough errors to trigger and find consistently, the results are at least encouraging. It can also be noted that the rough "evaluation of constant failed" error in the OP, has since improved on nightly, to somewhat acceptable levels. <details<summaryHere's how it looks now</summary</detailsAnd could be improved still if we, for example, specialized in the handful of actually used widths.


Question: - [You can now use `#[repr(transparent)]` on univariant `enum`s.][68122] Meaning that you can create an enum that has the exact layout and ABI of the type it contains. <del> - [You can now use outer attribute procedural macros on inline modules.][64273] </del> <ins> - [You can now use outer attribute procedural macros on inline modules.][64273] </ins> - [There are some *syntax-only* changes:][67131] - `default` is syntactically allowed before items in `trait` definitions. - Items in `impl`s (i.e. `const`s, `type`s, and `fn`s) may syntactically

It would allow mentioning the range bounds in the error message (or we could do some of the const fn string formatting hacks here of course).
Closing as working as intended. The error message has been improved, and a description of the potential breakage will be included in the 1.54 release notes ().


Question: }, ) }); <ins> // Priority of matches: // 1. Exact case insensitive match // 2. Levenshtein distance match // 3. Sorted word match </ins> if let Some(candidate) = case_insensitive_match { <del> Some(candidate) // exact case insensitive match has a higher priority </del> <ins> Some(*candidate) } else if levenshtein_match.is_some() { levenshtein_match.map(|(candidate, _)| *candidate) </ins> } else { <del> levenstein_match.map(|(candidate, _)| candidate) </del> <ins> find_match_by_sorted_words(name_vec, lookup) </ins> } } <ins> fn find_match_by_sorted_words<'a>(iter_names: Vec<&'a Symbol>, lookup: &str) -> Option<Symbol> { iter_names.iter().fold(None, |result, candidate| { if sort_by_words(&candidate.as_str()) == sort_by_words(lookup) { Some(**candidate) } else { result } }) } fn sort_by_words(name: &str) -> String { let mut split_words: Vec<&str> = name.split('_').collect(); split_words.sort(); split_words.join("_") } </ins>

On identifiers that have more than one word, it is relatively common to write them in the wrong order ( → ). These are normally not found by Levenshtein distance checks, but we could do a basic "split on ``, sort and join before comparison" so that we could suggest the right identifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to try to work on this. As is short enough to be caught by the Levenstein distance, I wrote for testing: claim
I'm thinking about the priority of the different possible matches. I tend to think that a match found by levenstein distance should have a greater priority, but what do you think?
it's tricky. I feel that your instinct might be right but we'd only know when looking at real world usage. The nice thing is that the lev distance check by its very nature it is limited, so doing the swapped words check as a fallback should work out ok in practice.
Releasing my assignment, as I am not sure to be able to commit. In case someone want to take on this, here is the function that should be modified. release-assignment
(I think this is appropriate, please tell me if it isn't) modify labels to +E-Easy
I can take a stab at this, seems reasonable with previous comments. claim


Question: #![feature(unboxed_closures)] #![feature(unwrap_infallible)] #![feature(vec_into_raw_parts)] <del> #![feature(vec_spare_capacity)] </del> // NB: the above list is sorted to minimize merge conflicts. #![default_lib_allocator]

The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- Initial implementation ()
FWIW, here is a full-featured API provided by an external crate:
I wonder how this API relates to . It would be great if there was some safe API that wrapped around the use of to access a 's spare capacity, then updated based on the s .
Maybe we should follow that example and generalize to return ?
has implemented that, albeit as a private function. Sounds like a good idea to me.
Since exists now I think is redundant.
That's not actually true due to pointer invalidation, see and
I think it would be better to have this feature sooner rather than later. I'm starting to notice instances where people are doing things that are probably or definitely UB because they want this functionality. So I think this API falls squarely into the standard library's mission to provide pre-built and correct implementations of things that are subtle or difficult to get right.   (originally posted on but per Ralf's comments there, it is probably better to have this method for the above use cases)
I agree. I've been using this in my code and found it to be very useful. Even though is more general, I've never had a need for it and I feel that is useful on its own. The API being stabilized is: merge
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!


Question: #![feature(unboxed_closures)] #![feature(unwrap_infallible)] #![feature(vec_into_raw_parts)] <del> #![feature(vec_spare_capacity)] </del> // NB: the above list is sorted to minimize merge conflicts. #![default_lib_allocator]

See for info about what commands tagged team members can give me.
while waiting for this feature to be stabilized, you should suggest that and use one of the convenience methods in:
:bell: This is now entering its final comment period, as per the . :bell:
Ralf mentioned this on , mostly rewording with my own opinion: I would prefer not to recommend that function, because even if you just want access to the spare region, under SB, these interfaces invalidate all pointers to the initialized region. I think that's too much of a footgun for codebases where people are already writing code that is rejected by Miri.
I wonder how many people do keep outstanding pointers to the initialized part while toying with the extra part 's implementation is already better than their 0-elems slices that get -ly converted into non-empty slices (and currently better than the stdlib one since it doesn't involve a 12-week delay for stable Rust). Anyhow, I've just released a new version () with a dedicated adapter: , for extra good measure.
To be clear, my concern is that the splitting interfaces are adding a landmine for the future. If I'm sending someone a PR I'll make sure it passes Miri at the time, but that's a hard condition to maintain. Especially because the two aforementioned codebases have dependencies that do int-ptr casts, an operation that Miri just doesn't understand at the moment, so it would be hard to advocate Miri in CI.
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. This will be merged soon.


Question: <ins> error: expected `{`, found `;` --> $DIR/semi-in-let-chain.rs:7:23 | LL |         && let () = (); |                       ^ expected `{` | note: you likely meant to continue parsing the let-chain starting here --> $DIR/semi-in-let-chain.rs:8:9 | LL |         && let () = () |         ^^^^^^ help: consider removing this semicolon to parse the `let` as part of the same chain | LL -         && let () = (); LL +         && let () = () | error: expected `{`, found `;` --> $DIR/semi-in-let-chain.rs:15:20 | LL |         && () == (); |                    ^ expected `{` | note: the `if` expression is missing a block after this condition --> $DIR/semi-in-let-chain.rs:14:8 | LL |       if let () = () |  ________^ LL | |         && () == (); | |___________________^ error: expected `{`, found `;` --> $DIR/semi-in-let-chain.rs:23:20 | LL |         && () == (); |                    ^ expected `{` | note: you likely meant to continue parsing the let-chain starting here --> $DIR/semi-in-let-chain.rs:24:9 | LL |         && let () = () |         ^^^^^^ help: consider removing this semicolon to parse the `let` as part of the same chain | LL -         && () == (); LL +         && () == () | error: aborting due to 3 previous errors </ins>

This is a common typo I make when hoisting an inconditional let binding into the let chain to merge two let-chains that could be one. The parser only needs to do look-ahead 1 and 2 to detect the case and recover. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: try!(self.flush_buf()); } if buf.len() >= self.buf.capacity() { <del> self.inner.as_mut().unwrap().write(buf) </del> <ins> self.panicked = true; let r = self.inner.as_mut().unwrap().write(buf); self.panicked = false; r </ins> } else { let amt = cmp::min(buf.len(), self.buf.capacity()); Write::write(&mut self.buf, &buf[..amt])

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: try!(self.flush_buf()); } if buf.len() >= self.buf.capacity() { <del> self.inner.as_mut().unwrap().write(buf) </del> <ins> self.panicked = true; let r = self.inner.as_mut().unwrap().write(buf); self.panicked = false; r </ins> } else { let amt = cmp::min(buf.len(), self.buf.capacity()); Write::write(&mut self.buf, &buf[..amt])

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: use rustc::hir; use syntax::attr; <del> declare_lint!(CRATE_NOT_OKAY, Warn, "crate not marked with #![crate_okay]"); </del> <ins> macro_rules! fake_lint_pass { ($struct:ident, $lints:expr, $($attr:expr),*) => { struct $struct; impl LintPass for $struct { fn get_lints(&self) -> LintArray { $lints } } </ins> <del> struct Pass; </del> <ins> impl<'a, 'tcx> LateLintPass<'a, 'tcx> for $struct { fn check_crate(&mut self, cx: &LateContext, krate: &hir::Crate) { $( if !attr::contains_name(&krate.attrs, $attr) { cx.span_lint(CRATE_NOT_OKAY, krate.span, &format!("crate is not marked with #![{}]", $attr)); } )* } } </ins> <del> impl LintPass for Pass { fn get_lints(&self) -> LintArray { lint_array!(CRATE_NOT_OKAY) </del> } } <del> impl<'a, 'tcx> LateLintPass<'a, 'tcx> for Pass { fn check_crate(&mut self, cx: &LateContext, krate: &hir::Crate) { if !attr::contains_name(&krate.attrs, "crate_okay") { cx.span_lint(CRATE_NOT_OKAY, krate.span, "crate is not marked with #![crate_okay]"); } } </del> <ins> declare_lint!(CRATE_NOT_OKAY, Warn, "crate not marked with #![crate_okay]"); declare_lint!(CRATE_NOT_RED, Warn, "crate not marked with #![crate_red]"); declare_lint!(CRATE_NOT_BLUE, Warn, "crate not marked with #![crate_blue]"); declare_lint!(CRATE_NOT_GREY, Warn, "crate not marked with #![crate_grey]"); declare_lint!(CRATE_NOT_GREEN, Warn, "crate not marked with #![crate_green]"); fake_lint_pass! { PassOkay, lint_array!(CRATE_NOT_OKAY), // Single lint "crate_okay" } fake_lint_pass! { PassRedBlue, lint_array!(CRATE_NOT_RED, CRATE_NOT_BLUE), // Multiple lints "crate_red", "crate_blue" } fake_lint_pass! { PassGreyGreen, lint_array!(CRATE_NOT_GREY, CRATE_NOT_GREEN, ), // Trailing comma "crate_grey", "crate_green" </ins> } #[plugin_registrar] pub fn plugin_registrar(reg: &mut Registry) { <del> reg.register_late_lint_pass(box Pass); </del> <ins> reg.register_late_lint_pass(box PassOkay); reg.register_late_lint_pass(box PassRedBlue); reg.register_late_lint_pass(box PassGreyGreen); </ins> }

Basically just change this macro to recognize and discard the trailing comma.
That macro declaration is formatted in a weird way. But anyway it should be enough to add to the rule (unless accepting multiple trailing commas is undesired). I could mentor.
How about this:
Out of curiosity, why doesn't rust allow trailing commas after automatically? Does it make it hard to write some macros? Alternately, why isn't there a (optional) repetition specification (e.g. would be 0 or 1 times)?
The extra rule is fine too. It's just more annoying (extra repetition). And there's no technical reason not to support one-or-none patterns as far as I'm aware.
Made a PR :)


Question: <ins> error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:4:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     dbg!(a); |     ------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(&a); |          + error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:10:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     dbg!(1, 2, a, 1, 2); |     ------------------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(1, 2, &a, 1, 2); |                + error[E0382]: use of moved value: `b` --> $DIR/dbg-issue-120327.rs:16:12 | LL |     let b: String = "".to_string(); |         - move occurs because `b` has type `String`, which does not implement the `Copy` trait LL |     dbg!(a, b); |     ---------- value moved here LL |     return b; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(a, &b); |             + error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:22:12 | LL | fn x(a: String) -> String { |      - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let b: String = "".to_string(); LL |     dbg!(a, b); |     ---------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(&a, b); |          + error[E0382]: use of moved value: `b` --> $DIR/dbg-issue-120327.rs:46:12 | LL |             tmp => { |             --- value moved here ... LL |     let b: String = "".to_string(); |         - move occurs because `b` has type `String`, which does not implement the `Copy` trait LL |     my_dbg!(b, 1); LL |     return b; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     my_dbg!(&b, 1); |             + help: borrow this binding in the pattern to avoid moving the value | LL |             ref tmp => { |             +++ error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:57:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let _b = match a { LL |         tmp => { |         --- value moved here ... LL |     return a; |            ^ value used here after move | help: borrow this binding in the pattern to avoid moving the value | LL |         ref tmp => { |         +++ error[E0382]: borrow of moved value: `a` --> $DIR/dbg-issue-120327.rs:65:14 | LL |     let a: String = "".to_string(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let _res = get_expr(dbg!(a)); |                         ------- value moved here LL |     let _l = a.len(); |              ^ value borrowed here after move | help: consider borrowing instead of transferring ownership | LL |     let _res = get_expr(dbg!(&a)); |                              + error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0382`. </ins>

No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.


Question: <ins> // Verify that the entry point injected by the test harness doesn't cause // weird artifacts in the coverage report (e.g. issue #10749). // compile-flags: --test #[allow(dead_code)] fn unused() {} #[test] fn my_test() {} </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. --Take this simple crate: If I try to gather code coverage for , I end up with the first line mysteriously duplicated as a covered region: (I'm using for convenience, but the same thing happens when I use and process the coverage data manually with and .) Note that in the report produced by , the first line of the file appears twice. It is marked as having executed once, even though it is a comment. Instead, the line should only appear once, and its execution count (if any) should be the execution count of the actual code on that line. <!-- 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<summaryBacktrace</summary<p</p</details--
I did some initial investigation, and discovered a few things: The coverage mapping that embeds in the test binary contains entries for two different functions named . One is the actual that appears in the file, and the other is the that is injected by the test harness. The mapping for the injected function spans from (1,0) to (1,1). Coverage mapping regions use 1-based line numbers and column numbers, so a column number of 0 should be impossible. This unexpected column number confuses the processing code in , and results in line 1 being duplicated in the output. : There are special circumstances where it's legal for a region to have 0 for its start column and its end column, but that isn't what's happening here.
The origin of the bogus (1,0) to (1,1) region seems to be: The test harness entry point is created with a dummy span: When that dummy span is converted into a region, its 0-based start is decremented in an attempt to make the region non-empty. This decrement overflows to , and a subsequent increment (to make it 1-based) overflows back to 0.
My first thought was to sidestep the whole issue by adding to the test harness's injected .


Question: <ins> // Verify that the entry point injected by the test harness doesn't cause // weird artifacts in the coverage report (e.g. issue #10749). // compile-flags: --test #[allow(dead_code)] fn unused() {} #[test] fn my_test() {} </ins>

However, I couldn’t get that to work, because is unstable and can't necessarily be used by the crate it is being injected into. So I think the fix will involve having the instrumentor detect and skip code with dummy spans.
label +A-code-coverage
fixes the overflow, which gets rid of the duplicate line. However, the instrumentor still ends up emitting an empty region from (1,1) to (1,1) for the test harness's , so I'd still like to find a way to avoid instrumenting that function.
I think the empty region now confusing the reporter in more subtle ways, because now I see weird stuff like this: It makes sense that line 1 is “covered” (via the injected ), but it's strange that lines 2 and 3 also have non-zero counts.
It looks like does have special handling for empty regions, but it doesn't properly anticipate the first region being empty, and ends up in a slightly confused state.


Question: } fn run(self, builder: &Builder<'_>) -> Option<GeneratedTarball> { <ins> // This prevents rust-analyzer from being built for "dist" or "install" // on the stable/beta channels. It is a nightly-only tool and should // not be included. if !builder.build.unstable_features() { return None; } </ins> let compiler = self.compiler; let target = self.target; assert!(builder.config.extended);

According to , the standalone tarball installer of stable Rust releases includes Miri. That's a bug, Miri is a nightly-only tool and should not be shipped on stable. Cc
Posted a fix at .


Question: <ins> // Test to check that the "warning blocks" are displayed as expected. go-to: "file://" + |DOC_PATH| + "/test_docs/struct.Foo.html" show-text: true define-function: ( "check-warning", (theme, color, border_color, background_color), block { set-local-storage: {"rustdoc-theme": |theme|, "rustdoc-use-system-theme": "false"} reload: // The IDs are added directly into the DOM to make writing this test easier. assert-css: ("#doc-warning-1", { "margin-bottom": "12px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) assert-css: ("#doc-warning-2", { "margin-bottom": "0px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) }, ) call-function: ("check-warning", { "theme": "ayu", "color": "rgb(197, 197, 197)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "dark", "color": "rgb(221, 221, 221)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "light", "color": "rgb(0, 0, 0)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) </ins>

Following , we realized that rustdoc users would prefer to have a syntax extension rather than using plain HTML to have warning blocks. suggested the following: suggested: What do you think? cc
Personal Opinions: The first style will look fine for short forms, but I'm not sure for longer text. A possible syntax: Which to me pushes the text too far right. Not having any spacing, but just separating with newlines, seems hard to parse at a glance what is part of the WARNING, and prevents multiple line breaks inside the warning. Also, it's not as extensible. INFO can be , but if we ever want more extensions, they would increasingly possibly conflict with other things. The second style makes it immediately clear what is part of the block, and is unlikely to accidentally conflict if we ever want to add more block styles. It also supports multiple lines or inner blocks trivially. A final advantage is that it may support nested blocks, in case those ever come to be useful. Overall: I prefer the second form, both aesthetically and for future-proofing
I think I agree with in preferring the second form. I like the first form's simplicity, but it also seems surprising that is treated as a 'keyword' and will change the formatting of the docs.
That's why we have this debate. :stuckouttongue:
I personally actually prefer stabilizing a CSS class, I think we should do more of that, just because parsing can get annoying. But this is not that hard to parse anyway. The problem with is precisely that you can't scope it easily: what if you want to add code blocks? bullet points?
The problem with this is it ties rustdoc to the HTML backend; like I said nothing rustdoc currently does guarentees that it will generate HTML from the markdown. Changing that means that to make the JSON backend have the same info, we'd have to add a full HTML parser to rustdoc just to read the HTML in the markdown, because pulldown does not parse HTML for us. I really think we should avoid making the JSON backend a second-class citizen.
Also there's not much point to this if it's just a little CSS IMO, you can add that yourself with and it will look just as good and be more flexible since you can control the styles yourself.


Question: <ins> // Test to check that the "warning blocks" are displayed as expected. go-to: "file://" + |DOC_PATH| + "/test_docs/struct.Foo.html" show-text: true define-function: ( "check-warning", (theme, color, border_color, background_color), block { set-local-storage: {"rustdoc-theme": |theme|, "rustdoc-use-system-theme": "false"} reload: // The IDs are added directly into the DOM to make writing this test easier. assert-css: ("#doc-warning-1", { "margin-bottom": "12px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) assert-css: ("#doc-warning-2", { "margin-bottom": "0px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) }, ) call-function: ("check-warning", { "theme": "ayu", "color": "rgb(197, 197, 197)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "dark", "color": "rgb(221, 221, 221)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "light", "color": "rgb(0, 0, 0)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) </ins>

I'm not a giant fan of the syntax because it looks odd when rendered by anything other than rustdoc, which I'd rather avoid, one of the major design concerns for intra-doc links was compatibility with other markdown parsers:
So, I agree, but I'm not convinced that the warning class is something that needs to be surfaced in the JSON backend as anything special. Also, bear in mind, HTML is a part of markdown: valid HTML (well a subset of HTML) is valid markdown. Users already can , and they do that in many cases. Markdown parsers already need to be able to handle HTML. There's nothing new there. Whatever consumes the JSON backend will need to be able to handle that too. I mean, yes, in theory, in practice people don't do this because of the barrier to entry (you have to get your tools to use that, including )
Also, this is incorrect, pulldown absolutely parses HTML. It has to, like I said valid HTML is valid Markdown. It doesn't parse it thoroughly, I believe you can mess it up with sufficiently complex HTML, but it parses HTML. What this changes is subtler: up till now you did not need any particular stylesheet to acceptably render rustdoc markdown from the JSON backend on your own (just use your favorite markdown renderer's stylesheet), but now you will need other css classes to handle rendering warnings as warnings.
I do not agree that this is a problem. I've used Phabricator's implementation of this approach happily and it is by design that warning banners are one paragraph. It is not the intention that you would put entire sections of documentation into a warning banner. They are for a brief callout. It's fine to refer to a subsequent section of the documentation from the callout if needed. I suppose this is a matter of taste but it's one where I believe the opinionatedness of the syntax is a positive thing.
So I discussed this a bit with on the side, we agree that the effect on the JSON backend isn't major since HTML is already a subset of markdown and docs use HTML already (especially for images and tables). My position is as follows: I strictly prefer HTML over some other scoped syntax with nuances people have to learn. I don't think there's as much value in unscoped syntax which makes my position "HTML or nothing", basically.


Question: <ins> // Test to check that the "warning blocks" are displayed as expected. go-to: "file://" + |DOC_PATH| + "/test_docs/struct.Foo.html" show-text: true define-function: ( "check-warning", (theme, color, border_color, background_color), block { set-local-storage: {"rustdoc-theme": |theme|, "rustdoc-use-system-theme": "false"} reload: // The IDs are added directly into the DOM to make writing this test easier. assert-css: ("#doc-warning-1", { "margin-bottom": "12px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) assert-css: ("#doc-warning-2", { "margin-bottom": "0px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) }, ) call-function: ("check-warning", { "theme": "ayu", "color": "rgb(197, 197, 197)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "dark", "color": "rgb(221, 221, 221)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "light", "color": "rgb(0, 0, 0)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) </ins>

I'm not wholly against unscoped single-line syntax. We and syntax in W3C specs and you invariably need to add more stuff to it (there's an HTML class in these specs for this reason). Furthermore, Rust has a strong culture of wrapping text, so this means we need to work well while wrapped, and that means we're again introducing some form of scoping mechanism (e.g. indenting the text), which editors will have to learn, as well.
I don't know about admonitions specifically but there seems to be something of a community habit to use "magic tags" on fenced code blocks for this sort of features (e.g. github has a tag), maybe that could be an option? I don't know if pulldown_cmark has a hook for manipulating code blocks but… So a warning would be or maybe the tag would be to leave room for things like note/todo/danger/… Alternatively, take a gander at how other markdown implementations extend the language for this sort of features? e.g. seems to be using for admonitions.
Hmm, but is still for code, even if it has some extra behavior. Aside from the design concerns, this would be feasible to implement: we just extract the language string from the code block with pulldown.
Could you use something that's already built into markdown? For example, rustdoc could take and render it as an admonition.
That's what suggested: to use markdown and make some changes on rustdoc side. I think the codeblock approach is the best personally.
My bad, I didn't see that.
I wonder if it makes more sense to add this as a proc-macro. Rustdoc can still provide the CSS classes and things, and you could use them with HTML directly, but you could use or something and it would expand to the correct HTML tags and classes.
Might be better to have a then, no?
Is that going to be a special header similar to the "unsafe"/"experimental"/etc ones, or is that going to also be used within docs in an order-sensitive way? If the latter we should probably just use a CSS class; mixing and is ugly
Agreed.


Question: <ins> // Test to check that the "warning blocks" are displayed as expected. go-to: "file://" + |DOC_PATH| + "/test_docs/struct.Foo.html" show-text: true define-function: ( "check-warning", (theme, color, border_color, background_color), block { set-local-storage: {"rustdoc-theme": |theme|, "rustdoc-use-system-theme": "false"} reload: // The IDs are added directly into the DOM to make writing this test easier. assert-css: ("#doc-warning-1", { "margin-bottom": "12px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) assert-css: ("#doc-warning-2", { "margin-bottom": "0px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) }, ) call-function: ("check-warning", { "theme": "ayu", "color": "rgb(197, 197, 197)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "dark", "color": "rgb(221, 221, 221)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "light", "color": "rgb(0, 0, 0)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) </ins>

Among the suggested ideas, my favourite one remains the code block with "warning" as tag:
Yeah, but triple backticks is also for preformatted text without further markup, so you won't be able to e.g. use text formatting (or other code) in there
True... Finding the right syntax is much more complicated than expected...
That's the issue of using markdown, for all that it has a pretty nice baseline syntax it really was not designed for extensibility.
We can always use : it'd allow to have text formatting inside it.
I would use , it's not quite kosher to invent arbitrary HTML tags (though you can use Custom Elements, which is more heavyweight)
Sounds good to me. It's funny because we kinda came back to the . :rofl:
I just thought: we could use tag in the markdown and then transform it into in the generated HTML?
My main objection to all of these is that rustdoc shouldn't be adding custom markdown syntax that no one else supports. Any new syntax we use should look reasonable even if rendered with the default renderer.
Well, it remains valid markdown since it's HTML (even though it's custom tag). I'm completely fine with , but it might be simpler/better for users to simply write .
Coming back to this (because of ), it seems like the conversation kinda agreed on adding a CSS class directly and then it would look like this in the docs: . I'll send a PR in the next days and then we can open an FCP to see if everyone is ok with it (and if not, we'll have code to help the debate).
This indeed seems like a better solution than the HTML block. It also plays better with something said about not linking it too much too HTML. This will look like a proper warning or note, mostly independent of the HTML generation.
They also seemed to not be too favourable to anything that needs some extra parsing from rustdoc iuc. I'm fine with bot the github solution and the CSS class.
Maybe one more comment to make here. The note-taking app, which uses Markdown also has a similar syntax to create these blocks. It is called . It uses a syntax similar to the syntax that is used for doc intra-links currently, and it is fully compatible with them.


Question: <ins> // Test to check that the "warning blocks" are displayed as expected. go-to: "file://" + |DOC_PATH| + "/test_docs/struct.Foo.html" show-text: true define-function: ( "check-warning", (theme, color, border_color, background_color), block { set-local-storage: {"rustdoc-theme": |theme|, "rustdoc-use-system-theme": "false"} reload: // The IDs are added directly into the DOM to make writing this test easier. assert-css: ("#doc-warning-1", { "margin-bottom": "12px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) assert-css: ("#doc-warning-2", { "margin-bottom": "0px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) }, ) call-function: ("check-warning", { "theme": "ayu", "color": "rgb(197, 197, 197)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "dark", "color": "rgb(221, 221, 221)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "light", "color": "rgb(0, 0, 0)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) </ins>

I am uncertain if this is any better than what suggested from the GitHub syntax, but because of the similarity to the doc intra-link syntax. I do feel like this might be interesting because it should go well with backwards compatibility. However, this may look worse than the GitHub syntax solution when not going through cargo doc.
I thought I'd already left this comment, but I'd really like to avoid adding more markdown syntax where possible. This feature works fine without special syntax, I don't think we need it. edit: copying over the reasoning from the :
Although, I might not agree fully, I can fully appreciate and understand the reasoning you left in the corresponding PR. Still, I do think it might be worth to standardize some kind of syntax for some kind of warning block. This does not actually require customized markdown. Alternatively, I can suggest adding the GitHub flavor with emojis to the . This may help in standardizing short form warnings and notes within documentation. We could for example propose to standardize: which should look like the following I do value people's opinion on this. Is this a possible compromise?
That's a valid alternative, I think the yellow color is pretty important though, and it's useful for themes to be able to make styling decisions about warnings so I do think that having some way of marking it is important. I just don't think the way of marking it should be some magic invocation as opposed to CSS classes. (And I think that the bar for a feature that is adding new semantics to the Rustdoc markdown parser is much, much higher than that of one stabilizing a CSS class)
100% agree. I will look at the Rust API guidelines issue and possibly an RFC to rust to track the adoption in GitHub and possibly eventually merge. Thank you :smile:
Beyond all this discussion of third-party tools, I'd really like to make sure that whatever new syntax and presentation we add to rustdoc can also be to [mdBook]. That way, when the standard library starts using callouts, we can make sure the same style also gets used in The Book. Mostly, The Book seems to just use blockquotes, often with headings like [this one about ownership]. mdBook doesn't do anything special with it: it's [just a block quote with a header].


Question: <ins> // Test to check that the "warning blocks" are displayed as expected. go-to: "file://" + |DOC_PATH| + "/test_docs/struct.Foo.html" show-text: true define-function: ( "check-warning", (theme, color, border_color, background_color), block { set-local-storage: {"rustdoc-theme": |theme|, "rustdoc-use-system-theme": "false"} reload: // The IDs are added directly into the DOM to make writing this test easier. assert-css: ("#doc-warning-1", { "margin-bottom": "12px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) assert-css: ("#doc-warning-2", { "margin-bottom": "0px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) }, ) call-function: ("check-warning", { "theme": "ayu", "color": "rgb(197, 197, 197)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "dark", "color": "rgb(221, 221, 221)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "light", "color": "rgb(0, 0, 0)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) </ins>

[mdBook]: [this one about ownership]: [just a block quote with a header]:
This is a good point. Once we have something merged here, I'll send a PR there to have an equivalent.
CC
I'd be happy to add some CSS rules to mdbook if that is what you are proposing.
Yeah, it is.
FYI, using a is not semantic and Microsoft GitHub is setting a bad precedence. — CommonMark Spec v0.30, denotes a in Markdown and is rendered as such. — W3C HTML spec, Unless you are quoting a source, this is not the correct element to use. While I disagree with even using altogether, at least some tools out there are at least translating the blockquote in admonition context into a (div has no semantic meaning which is unfortunately the best HTML option for admonitions). It would be ill-advised to follow Microsoft GitHub’s Markdown syntax fork—especially with their disregard for semantics. Similarly using a block would also be breaking semantics as an admonition is not preformatted text. CommonMark does have that could be used if the solution was preferred. There’s also other reasonable options noted here that don’t break semantics.
I agree that block quotes for callouts are bad, and would like to work with mdBook to roll out a common syntax (probably ) that will replace the ad-hoc, unsemantic markup that they use right now.
Using is what we agreed upon in The debate now is on the look itself.
Unfortunately isn't great because markdown has a "boundary" when HTML tags are used. I wanted to add a warning indicating that users probably wanted another trait, but intra-doc links don't work (which is the correct behavior per markdown spec).
Works perfectly fine though (well, minus the UI bug I just discovered haha): ! I used this code: I'll send a PR to improve documentation.
Ah. Well I suppose the issue wasn't with intra-doc links, but with inline code blocks. What I tried was that but with bar`, and it failed.
Works too: !
I opened which adds extra explanation on how to use markdown inside html tags. That should solve your issue.
That note is exactly what I was just looking in to. I had it inline, given my familiarity with HTML. TIL that matters.


Question: <ins> // Test to check that the "warning blocks" are displayed as expected. go-to: "file://" + |DOC_PATH| + "/test_docs/struct.Foo.html" show-text: true define-function: ( "check-warning", (theme, color, border_color, background_color), block { set-local-storage: {"rustdoc-theme": |theme|, "rustdoc-use-system-theme": "false"} reload: // The IDs are added directly into the DOM to make writing this test easier. assert-css: ("#doc-warning-1", { "margin-bottom": "12px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) assert-css: ("#doc-warning-2", { "margin-bottom": "0px", "color": |color|, "border-left": "2px solid " + |border_color|, "background-color": |background_color|, }) }, ) call-function: ("check-warning", { "theme": "ayu", "color": "rgb(197, 197, 197)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "dark", "color": "rgb(221, 221, 221)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) call-function: ("check-warning", { "theme": "light", "color": "rgb(0, 0, 0)", "border_color": "rgb(255, 142, 0)", "background_color": "rgba(0, 0, 0, 0)", }) </ins>

It doesn't hurt to have it and if it can helps users, well, why not doing it. :)


Question: .label = invalid stability version .item = the stability attribute annotates this item <ins> passes_lang_item_fn_with_target_feature = `{$name}` language item function is not allowed to have `#[target_feature]` .label = `{$name}` language item function is not allowed to have `#[target_feature]` </ins> passes_lang_item_on_incorrect_target = `{$name}` language item must be applied to a {$expected_target} .label = attribute should be applied to a {$expected_target}, not a {$actual_target}

This works (but it shouldn't): similar to , cc (tracking issue) label T-lang T-compiler C-bug I-unsound F-targetfeature11
cc , author of Note that this is about the nostd panic handler, not about the function. This fails as it should: gives
ugh we really need a way to make sure that every single "this is called by rust" function gets a check... I assume that these functions can't be unsafe, so I guess those checks are a food way to start looking and make sure to deduplicate the logic there?
Yeah sadly we do need to make sure, not just for the constructs that we have now but also it needs to be kept in mind for the future constructs we add or stabilize. A lot thankfully goes through either the trait system (operators or the GlobalAlloc trait used by ) or function pointers (alloc error hook, std panic hook). Functions that you can make callable solely by setting an attribute, those are rare. The best list of lang items I could find was in the , so that would be a great start for such an exhaustive search. Thankfully most of them are unstable, but still it needs to be addressed for each of them before stabilization (if that is a target).
WG-prioritization assigning priority (). label -I-prioritize +P-medium
label +requires-nightly
There is also another table of lang items in the source code, .


Question: if builder.config.llvm_thin_lto { cfg.define("LLVM_ENABLE_LTO", "Thin"); if !target.contains("apple") { <del> cfg.define("LLVM_USE_LINKER", "lld"); </del> <ins> cfg.define("LLVM_ENABLE_LLD", "ON"); </ins> } }

When I install the latest master toolchains via and try to build with them, linking fails: I did some bisection, and it looks like the problem started happening with Cc
The error is actually already mentioned in However, I am building Miri with cargo, so I don't know how I'd "use LLD instead".
Hm, we probably need to revert that PR. I did not realize we'd need lld downstream too, I thought that was only on our builder. cc
Yes, a revert seems appropriate. We're going to have to figure out where that's actually coming from. The only change I saw between 10 and 11 by grepping was the removal of llgo, but maybe there's some bad remnant.
Yeah, I thought this issue would be limited to the rustc build, but it makes sense that it can also affect project linking against rustc shared objects. I've looked a bit into what the root cause is, and what I have so far as that the symbol comes from and is present as a weak symbol both when compiling with clang-10 and clang-11. The only difference I see from is this: So apparently was treated as a symbol of the library, while now it's treated as a symbol of -- I'm not sure what that actually means, but presumably that refers to the compiler runtime libraries. My guess is that previously it just ended up being nulled out as a missing weak symbol, but now it's actually being found and linking fails because ... reasons. I'm not good at linkers :) Edit: shows these as:
can you prepare a revert PR?
Done in . If nobody has an idea on how to avoid the linker error, two more options would be to comment out the symbol in our llvm-project fork, or to avoid upgrading clang altogether and just build both Python 2 and Python 3 for that image.
The issue is probably going to be in how exactly the objects that comprise are compiled, not linked. I suspect just ends up ignoring the malformed object or otherwise not reporting the issue, but the object and the relevant symbols ultimately end up in the anyway. Alas, reasons these obscure failures can occur are many – I've seen them occur from things as trivial as forgetting to . The question is: is there perhaps a way to disable ExecutionEngine entirely? Intuitively nothing we do should depend on that code.


Question: if builder.config.llvm_thin_lto { cfg.define("LLVM_ENABLE_LTO", "Thin"); if !target.contains("apple") { <del> cfg.define("LLVM_USE_LINKER", "lld"); </del> <ins> cfg.define("LLVM_ENABLE_LLD", "ON"); </ins> } }

And if not, I'm comfortable patching out in our fork as we get closer to Feb 11 and continue having trouble pinpointing exact cause of this problem.
We normally don't link ExecutionEngine, but dist-x8664-linux in particular builds LLVM with ThinLTO, in which case we link as shared, instead of statically linking individual components into rustcllvm.
It seems to be possible to configure the components in using , but I'm not sure to what degree we can restrict those (not sure if this job also ships LLVM tools).
So, I think we could have used to exclude unnecessary parts from , as LLVM tools can still statically link the parts not in the dylib. But in the end, we can't use the option anyway due to
Looks like I'm getting this locally when trying to bootstrap rustc (while building ), might happen since the llvm upgrade but I'm not 100% sure. Are there some workarounds I can put into my for this? I'm using lld to link. <details<summaryBacktrace</summary<p</p</details
which commit are you trying to build?
latest git master
Probably best to open a new issue then; this one has been closed and the steps to reproduce it still work without error -- you might be having a different problem.
Opened
Did anyone file an upstream bug report about this? I'm observing it outside of Rust, but with a similar setup ( with lld+ThinLTO, then linking it into a binary with ). If not, I'd try to build a reproducer.
I've opened for this.
The bug has been fixed, the fix will be in LLVM 12.0.1.
Thanks! We can try updating clang again once the 12.0.1 tag is there.


Question: } ``` <ins> ### Error example 3 Suppose we have a struct `Foo` and we would like to define some methods for it. The following code example has a definition which leads to a compiler error: ```compile_fail,E0207 struct Foo; impl<const T: i32> Foo { // error: the const parameter `T` is not constrained by the impl trait, self // type, or predicates [E0207] fn get(&self) -> i32 { i32::default() } } ``` The problem is that the const parameter `T` does not appear in the implementing type (`Foo`) of the impl. In this case, we can fix the error by moving the type parameter from the `impl` to the method `get`: ``` struct Foo; // Move the const parameter from the impl to the method impl Foo { fn get<const T: i32>(&self) -> i32 { i32::default() } } ``` ### Error example 4 Suppose we have a struct `Foo` and a struct `Bar` that uses lifetime `'a`. We would like to implement trait `Contains` for `Foo`. The trait `Contains` have the associated type `B`. The following code example has a definition which leads to a compiler error: ```compile_fail,E0207 struct Foo; struct Bar<'a>; trait Contains { type B; fn get(&self) -> i32; } impl<'a> Contains for Foo { type B = Bar<'a>; // error: the lifetime parameter `'a` is not constrained by the impl trait, // self type, or predicates [E0207] fn get(&self) -> i32 { i32::default() } } ``` Please note that unconstrained lifetime parameters are not supported if they are being used by an associated type. </ins> ### Additional information For more information, please see [RFC 447].

As it is currently written, E0207 talks entirely about type parameters. Now that const parameters also need to constrain implementations (under the same rules described for types), they also need to be mentioned in the error explanation. Since other items don't require const parameters to be used at all, we might also want to specifically call out this difference here. Furthermore, E0207 triggers if you use an unconstrained lifetime in an associated type, and this is completely unspecified by the error as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: <ins> error[E0204]: the trait `ConstParamTy` cannot be implemented for this type --> $DIR/nested_bad_const_param_ty.rs:6:10 | LL | #[derive(ConstParamTy)] |          ^^^^^^^^^^^^ LL | LL | struct Foo([*const u8; 1]); |            -------------- this field does not implement `ConstParamTy` | note: the `ConstParamTy` impl for `[*const u8; 1]` requires that `*const u8: ConstParamTy` --> $DIR/nested_bad_const_param_ty.rs:8:12 | LL | struct Foo([*const u8; 1]); |            ^^^^^^^^^^^^^^ = note: this error originates in the derive macro `ConstParamTy` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0204]: the trait `ConstParamTy` cannot be implemented for this type --> $DIR/nested_bad_const_param_ty.rs:10:10 | LL | #[derive(ConstParamTy)] |          ^^^^^^^^^^^^ LL | LL | struct Foo2([*mut u8; 1]); |             ------------ this field does not implement `ConstParamTy` | note: the `ConstParamTy` impl for `[*mut u8; 1]` requires that `*mut u8: ConstParamTy` --> $DIR/nested_bad_const_param_ty.rs:12:13 | LL | struct Foo2([*mut u8; 1]); |             ^^^^^^^^^^^^ = note: this error originates in the derive macro `ConstParamTy` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0204]: the trait `ConstParamTy` cannot be implemented for this type --> $DIR/nested_bad_const_param_ty.rs:14:10 | LL | #[derive(ConstParamTy)] |          ^^^^^^^^^^^^ LL | LL | struct Foo3([fn(); 1]); |             --------- this field does not implement `ConstParamTy` | note: the `ConstParamTy` impl for `[fn(); 1]` requires that `fn(): ConstParamTy` --> $DIR/nested_bad_const_param_ty.rs:16:13 | LL | struct Foo3([fn(); 1]); |             ^^^^^^^^^ = note: this error originates in the derive macro `ConstParamTy` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0204`. </ins>

The following code fails to compile, because using function pointers as const generics is forbidden: However, if the function pointer is inside an array, it suddenly compiles: Is this intentional, or should it also be forbidden? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The first is definitely intentional. have an unstable notion of equality, in particular if they point to instances of generic functions: two entirely independent functions might have "equal" function pointers if they happen to compile to the same assembly code, and two identical instances of the same generic function in different crates (or even just different codegen units) might compare "inequal".
The second is a bug, good catch! I misread the issue description at first. This should not work in arrays -- I assume this would be fixed by properly moving to valtrees. Cc
still compiles, the issue is that function pointers are currently considered to be structural match. I intend to work on structural equality in the near (not that near) future, going to assign this to myself. claim
Same issue with raw pointers (both and ):
This no longer works: Looks like the issue got fixed? We should make sure we have a test though.
this happens as const generics now relies on instead of simply using structural match.


Question: use rustc_hir::definitions::Definitions; use rustc_hir::intravisit::Visitor; use rustc_hir::lang_items::LangItem; <del> use rustc_hir::{ Constness, ExprKind, HirId, ImplItemKind, ItemKind, Node, TraitCandidate, TraitItemKind, }; </del> <ins> use rustc_hir::{Constness, HirId, Node, TraitCandidate}; </ins> use rustc_index::IndexVec; use rustc_macros::HashStable; use rustc_query_system::dep_graph::DepNodeIndex;

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


Question: Ok(lhs) } <ins> fn should_continue_as_assoc_expr(&mut self, lhs: &Expr) -> bool { match (self.expr_is_complete(lhs), self.check_assoc_op()) { // Semi-statement forms are odd: // See https://github.com/rust-lang/rust/issues/29071 (true, None) => false, (false, _) => true, // Continue parsing the expression. // An exhaustive check is done in the following block, but these are checked first // because they *are* ambiguous but also reasonable looking incorrect syntax, so we // want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` if !self.look_ahead(1, |t| t.is_reserved_ident()) => { // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span); false } (true, Some(ref op)) if !op.can_continue_expr_unambiguously() => false, (true, Some(_)) => { self.error_found_expr_would_be_stmt(lhs); true } } } /// We've found an expression that would be parsed as a statement, /// but the next token implies this should be parsed as an expression. /// For example: `if let Some(x) = x { x } else { 0 } / 2`. fn error_found_expr_would_be_stmt(&self, lhs: &Expr) { let mut err = self.struct_span_err(self.token.span, &format!( "expected expression, found `{}`", pprust::token_to_string(&self.token), )); err.span_label(self.token.span, "expected expression"); self.sess.expr_parentheses_needed(&mut err, lhs.span, Some(pprust::expr_to_string(&lhs))); err.emit(); } /// Possibly translate the current token to an associative operator. /// The method does not advance the current token. /// /// Also performs recovery for `and` / `or` which are mistaken for `&&` and `||` respectively. fn check_assoc_op(&self) -> Option<AssocOp> { AssocOp::from_token(&self.token) } </ins> /// Checks if this expression is a successfully parsed statement. fn expr_is_complete(&self, e: &Expr) -> bool { self.restrictions.contains(Restrictions::STMT_EXPR) &&

The idea of shortening to has been discussed many times before, and the general consensus always ends up being that it is not a good idea. I would like to propose something a bit different, so please hear me out. I propose that instead of aliasing to , we instead just make expand into when in the context of a variable declaration. For example: This solves the problems (readability, more concise) that people have with , whilst not causing the issues that people have (pattern matching and consistancy). The most common issue people have with aliasing to is that it doesn't fit well with patterns, like . However, gets rid of this problem, because you wouldn't write if you were trying to pattern match, so why would someone want to write ? You wouldn't do that, and it wouldn't compile. This would be optional, of course. would still work fine, and people would just have to option of removing the to let it be implied. There are a lot of other abbreviations used in rust (, , ) that all serve the purpose of writing less. It just doesn't feel right that one of the most commonly used keywords is so long. :heart::crab: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Rust wants to make to make you think when you try and use mutation, even if only a little bit, because mutation can be difficult to reason about. Shortening to doesn't fit this philosophy. Also, this makes mutation just as easy as no mutation. This will lead people to choose mutation because it will give them less compiler errors in the short term, and in doing so open themselves up to some weird bugs that could have been prevented with the syntactic salt that is . tldr: wasn't rejected because of the name , but because it allowed easy mutation, which runs counter to Rust's philosophy.
I politely disagree. In fact, it is actually the other way around. Using unnecessarily will cause compiler warnings, discouraging the use of unneeded mutability. The compiler doesn't warn when the use of is actually needed.
The fact that people will choose in the face of compiler warnings has been shown in practice, across many projects.


Question: Ok(lhs) } <ins> fn should_continue_as_assoc_expr(&mut self, lhs: &Expr) -> bool { match (self.expr_is_complete(lhs), self.check_assoc_op()) { // Semi-statement forms are odd: // See https://github.com/rust-lang/rust/issues/29071 (true, None) => false, (false, _) => true, // Continue parsing the expression. // An exhaustive check is done in the following block, but these are checked first // because they *are* ambiguous but also reasonable looking incorrect syntax, so we // want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` if !self.look_ahead(1, |t| t.is_reserved_ident()) => { // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span); false } (true, Some(ref op)) if !op.can_continue_expr_unambiguously() => false, (true, Some(_)) => { self.error_found_expr_would_be_stmt(lhs); true } } } /// We've found an expression that would be parsed as a statement, /// but the next token implies this should be parsed as an expression. /// For example: `if let Some(x) = x { x } else { 0 } / 2`. fn error_found_expr_would_be_stmt(&self, lhs: &Expr) { let mut err = self.struct_span_err(self.token.span, &format!( "expected expression, found `{}`", pprust::token_to_string(&self.token), )); err.span_label(self.token.span, "expected expression"); self.sess.expr_parentheses_needed(&mut err, lhs.span, Some(pprust::expr_to_string(&lhs))); err.emit(); } /// Possibly translate the current token to an associative operator. /// The method does not advance the current token. /// /// Also performs recovery for `and` / `or` which are mistaken for `&&` and `||` respectively. fn check_assoc_op(&self) -> Option<AssocOp> { AssocOp::from_token(&self.token) } </ins> /// Checks if this expression is a successfully parsed statement. fn expr_is_complete(&self, e: &Expr) -> bool { self.restrictions.contains(Restrictions::STMT_EXPR) &&

Also, the problem isn't that people may choose to put just for the heck of it, but that they will unintentionally mutate something that was supposed to be immutable. And because it is being mutated, there is no warning, and they used because it is their default, it is their default because it gets rid of compiler errors that say they were trying to mutate things that are immutable even though they weren't supposed to mutate them in the first place. They will use because it is just as easy as making it immutable. So the problem is a bit more subtle than you seem to think.
Incorrect. Extreme brevity harms readability. See Perl. lol Readers would ignore the vs distinction far more often that vs , partially due to length difference, but works even better than say . It's true boilerplate often harms readability, but boilerplate requires some complexity be repeated, not merely the in . It harms readability even further if also works for , especially when you consider code readers need not actually know Rust. Rust syntax was designed largely to reduce cognitive load, not to reduce typing. We use , , and , not any shorter alternatives. And delegation RFCs have kinda given up the short syntaxes. I think Rust's omission of is now considered a mistake, but presumably helps C programmers. Rust has short keywords only really for fundamental "items" used repeatedly by basically every module. It's similar cognitive load if you write , , or , but actually just writing the shorter bare increases cognitive load. I think invokes the minor linguistic subtlety that variable means mutable binding, while acts like a common term for binding, which makes very slightly clearer.
The statement would be orthogonal to the current language in some sense though. is not a special syntax, but is composed of statement + pattern. It is in line with other places expects a pattern, where you can write , , or .
It seems unlikely to me that we would support as a short-hand. I'm personally opposed to it both because it adds unnecessary compiler complexity, stylistic schisms, and for the reasons outlined by However, I've taken the liberty of reusing this issue towards improved diagnostics: The idea here is to check . The idea here is to check: The relevant code is here: cc
claim
Error: Parsing assign command in failed: claim :)... Please let know if you're having trouble with this bot.


Question: Ok(lhs) } <ins> fn should_continue_as_assoc_expr(&mut self, lhs: &Expr) -> bool { match (self.expr_is_complete(lhs), self.check_assoc_op()) { // Semi-statement forms are odd: // See https://github.com/rust-lang/rust/issues/29071 (true, None) => false, (false, _) => true, // Continue parsing the expression. // An exhaustive check is done in the following block, but these are checked first // because they *are* ambiguous but also reasonable looking incorrect syntax, so we // want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` if !self.look_ahead(1, |t| t.is_reserved_ident()) => { // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span); false } (true, Some(ref op)) if !op.can_continue_expr_unambiguously() => false, (true, Some(_)) => { self.error_found_expr_would_be_stmt(lhs); true } } } /// We've found an expression that would be parsed as a statement, /// but the next token implies this should be parsed as an expression. /// For example: `if let Some(x) = x { x } else { 0 } / 2`. fn error_found_expr_would_be_stmt(&self, lhs: &Expr) { let mut err = self.struct_span_err(self.token.span, &format!( "expected expression, found `{}`", pprust::token_to_string(&self.token), )); err.span_label(self.token.span, "expected expression"); self.sess.expr_parentheses_needed(&mut err, lhs.span, Some(pprust::expr_to_string(&lhs))); err.emit(); } /// Possibly translate the current token to an associative operator. /// The method does not advance the current token. /// /// Also performs recovery for `and` / `or` which are mistaken for `&&` and `||` respectively. fn check_assoc_op(&self) -> Option<AssocOp> { AssocOp::from_token(&self.token) } </ins> /// Checks if this expression is a successfully parsed statement. fn expr_is_complete(&self, e: &Expr) -> bool { self.restrictions.contains(Restrictions::STMT_EXPR) &&

Although I would also guess that the initial idea is very unlikely to end up accepted, it feels premature to unilaterally hijack the thread in your very first comment and make it have a different (and in a way opposite) purpose. Teams of the Rust project are designed to make decisions collectively. Improving diagnostics sounds good, but issue numbers are cheap.
Implementing something as a diagnostic actually brings you closer to a working implementation -- I think more proposals should start out as diagnostics. I will not bother the other language team members with not-fully-formed proposals that we will not accept in either case. I converted the issue into the most actionable and productive thing it could be. The place for ephemeral discussions is either on Discord or on internals. If you want to discuss this further, I'm available at Discord (but will not respond to it further here). wasting everyone's time with things that will go nowhere (because it won't be accepted and because it is not important enough to be raised at the team) is not.
IMHO, the original thing this issue was opened for should be an RFC, not an issue. I'd have closed this, pointed the OP to the RFCs repo, and opened a new issue for the diagnostic issue.
This issue was literally in the RFCs repo initially, transferred it from there.
Language bashing is not welcome here
Wait, so should I unassign here, and assign to the new issue?
Nah, just use this one.
Yeah, thats fine. You can just change this issue to be for diagnostics instead.
I'm sorry, I've been pretty busy with coursework, and I'm still fighting my Python installation to even build the compiler, let alone make progress on this. Sorry :(
I'll assign this to myself to work on when I have time. If you want to work on it however, feel free to work-steal it from me!
I would like to help with this
Sorry; should have updated this issue...! There's a PR at the moment. Feel free to leave suggestions on it if you like. :)


Question: Ok(lhs) } <ins> fn should_continue_as_assoc_expr(&mut self, lhs: &Expr) -> bool { match (self.expr_is_complete(lhs), self.check_assoc_op()) { // Semi-statement forms are odd: // See https://github.com/rust-lang/rust/issues/29071 (true, None) => false, (false, _) => true, // Continue parsing the expression. // An exhaustive check is done in the following block, but these are checked first // because they *are* ambiguous but also reasonable looking incorrect syntax, so we // want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` if !self.look_ahead(1, |t| t.is_reserved_ident()) => { // These cases are ambiguous and can't be identified in the parser alone. let sp = self.sess.source_map().start_point(self.token.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span); false } (true, Some(ref op)) if !op.can_continue_expr_unambiguously() => false, (true, Some(_)) => { self.error_found_expr_would_be_stmt(lhs); true } } } /// We've found an expression that would be parsed as a statement, /// but the next token implies this should be parsed as an expression. /// For example: `if let Some(x) = x { x } else { 0 } / 2`. fn error_found_expr_would_be_stmt(&self, lhs: &Expr) { let mut err = self.struct_span_err(self.token.span, &format!( "expected expression, found `{}`", pprust::token_to_string(&self.token), )); err.span_label(self.token.span, "expected expression"); self.sess.expr_parentheses_needed(&mut err, lhs.span, Some(pprust::expr_to_string(&lhs))); err.emit(); } /// Possibly translate the current token to an associative operator. /// The method does not advance the current token. /// /// Also performs recovery for `and` / `or` which are mistaken for `&&` and `||` respectively. fn check_assoc_op(&self) -> Option<AssocOp> { AssocOp::from_token(&self.token) } </ins> /// Checks if this expression is a successfully parsed statement. fn expr_is_complete(&self, e: &Expr) -> bool { self.restrictions.contains(Restrictions::STMT_EXPR) &&

From The following code should be using the common list parsing utilities: CC
What/where are the common list parsing utilties? Edit: never mind, I've got it. , , etc. for anyone who's wondering.


Question: use util::fs::fix_windows_verbatim_for_gcc; use rustc_back::tempdir::TempDir; <ins> use std::ascii; use std::char; </ins> use std::env; use std::ffi::OsString; use std::fs::{self, PathExt};

Compiler crashes while compiling using Cargo. Cargo version: cargo 0.6.0-nightly ( 2015-10-17) rustc version: 1.3.0
It looks like this comes from the linker producing output (normal or error) that is not valid UTF-8. Fixing this in any other way than just using a lossy conversion is going to be really painful because it goes through the error logging infrastructure, which all works with s. That's certainly not ideal, because it would be best to relay other programs' messages to the user unchanged, but it's probably the only realistic way to handle this in the near future.
Just dump the bytes as hexadecimal? I am not sure what is going on here.
My first thought was that the path was probably not UTF-8, but because of the way cargo invokes it that crashes rustc long before it tries to link anything, so that can't be it. I'm not sure why else the message would be non-UTF-8. (I can't reproduce the ICE on that crate (I just get a normal link error), but I can reproduce the ICE by constructing a situation where the linker prints non-UTF-8 messages.) But yeah, some kind of lossy conversion with hex escapes is probably the way to go. I'm not aware of an existing function to do that.
Actually, mapping with is probably good enough.
foo'ncollect2: error: ld returned 1 exit statusn` Not great, but not an ICE and probably good enough until we have a dedicated function to do this sort of thing since this should be a very rare error.


Question: Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages. <ins> GitHub allows [closing issues using keywords][closing-keywords]. This feature should be used to keep the issue tracker tidy. However, it is generally preferred to put the "closes #123" text in the PR description rather than the issue commit; particularly during rebasing, citing the issue number in the commit can "spam" the issue in question. [closing-keywords]: https://help.github.com/en/articles/closing-issues-using-keywords </ins> Please make sure your pull request is in compliance with Rust's style guidelines by running

We expect everyone to rebase instead of merge and we also try to have fixup commits squashed into previous related commits. I think we should document this policy, since it keeps suprising newcomers.
I can take care of this one as it's quite a fresh experience :).
I think we should only rebase when resolving merge conflict, or the review process has completed and reviewer request a rebasing. Otherwise I prefer adding new commits for easier reviewing.
I agree with that this policy is sound for actually merging the PR, but it might cause confusion for reviews. I've had a PR lying around for awhile, and when there is merge conflicts the 'waiting-on-author' label gets so noone reviews it, but when I do the rebasing to get back my 'waiting-on-review' it seems as if Github sometimes loses context of previous reviews, which can be quite confusing...
for the record: I personally want no rebasing and just merging, I'm just stating what the policy is.
Before we close this issue. Could we talk a bit about ? I think we should encourage contributors close issues by keywords in PR descriptions only. Because otherwise the commit could be rebased many times, and each time it creates a reference to the want-to-close issue. Also in the referenced issue, the commit number of the new commit that could close that issue is not really informative. The PR number itself appeared in the issue is more informative and concise. In short, we create another policy for closing issue.


Question: #[derive(Default)] struct OptimizationList<'tcx> { <del> and_stars: FxHashMap<Location, Mutability>, </del> <ins> and_stars: FxHashSet<Location>, </ins> arrays_lengths: FxHashMap<Location, Constant<'tcx>>, }

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: <ins> // Test that the `'a` from the impl doesn't // prevent us from creating a `'a` parameter // on the `blah` function. // // check-pass #![feature(in_band_lifetimes)] struct Foo<'a> { x: &'a u32 } impl Foo<'a> { fn method(&self) { fn blah(f: Foo<'a>) { } } } fn main() { } </ins>

The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).


Question: = note: `impl Trait` is only allowed in arguments and return types of functions and methods error[E0798]: function pointers with the `"C-cmse-nonsecure-call"` ABI cannot contain generics in their type <del> --> $DIR/generics.rs:19:9 </del> <ins> --> $DIR/generics.rs:20:9 </ins> | LL |     f3: extern "C-cmse-nonsecure-call" fn(T, u32, u32, u32) -> u64, |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0798]: function pointers with the `"C-cmse-nonsecure-call"` ABI cannot contain generics in their type <del> --> $DIR/generics.rs:20:9 </del> <ins> --> $DIR/generics.rs:21:9 </ins> | LL |     f4: extern "C-cmse-nonsecure-call" fn(Wrapper<T>, u32, u32, u32) -> u64, |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <del> error: aborting due to 5 previous errors </del> <ins> error[E0798]: return value of `"C-cmse-nonsecure-call"` function too large to pass via registers --> $DIR/generics.rs:27:73 | LL | type WithTraitObject = extern "C-cmse-nonsecure-call" fn(&dyn Trait) -> &dyn Trait; |                                                                         ^^^^^^^^^^ this type doesn't fit in the available registers | = note: functions with the `"C-cmse-nonsecure-call"` ABI must pass their result via the available return registers = note: the result must either be a (transparently wrapped) i64, u64 or f64, or be at most 4 bytes in size error[E0798]: return value of `"C-cmse-nonsecure-call"` function too large to pass via registers --> $DIR/generics.rs:31:62 | LL |     extern "C-cmse-nonsecure-call" fn(&'static dyn Trait) -> &'static dyn Trait; |                                                              ^^^^^^^^^^^^^^^^^^ this type doesn't fit in the available registers | = note: functions with the `"C-cmse-nonsecure-call"` ABI must pass their result via the available return registers = note: the result must either be a (transparently wrapped) i64, u64 or f64, or be at most 4 bytes in size error[E0798]: return value of `"C-cmse-nonsecure-call"` function too large to pass via registers --> $DIR/generics.rs:38:62 | LL |     extern "C-cmse-nonsecure-call" fn(WrapperTransparent) -> WrapperTransparent; |                                                              ^^^^^^^^^^^^^^^^^^ this type doesn't fit in the available registers | = note: functions with the `"C-cmse-nonsecure-call"` ABI must pass their result via the available return registers = note: the result must either be a (transparently wrapped) i64, u64 or f64, or be at most 4 bytes in size error[E0045]: C-variadic function must have a compatible calling convention, like `C` or `cdecl` --> $DIR/generics.rs:41:20 | LL | type WithVarArgs = extern "C-cmse-nonsecure-call" fn(u32, ...); |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ C-variadic function must have a compatible calling convention error: aborting due to 9 previous errors </ins> <del> Some errors have detailed explanations: E0412, E0562, E0798. For more information about an error, try `rustc --explain E0412`. </del> <ins> Some errors have detailed explanations: E0045, E0412, E0562, E0798. For more information about an error, try `rustc --explain E0045`. </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'', 'thread 'rustc' panicked at ' has escaping bound vars, so it cannot be wrapped in a dummy binder.'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [issizedraw] computing whether is [layoutof] computing layout of -- label +F-impltraitinassoctype +F-inherentassociated_types
ah lol this regressed in cc


Question: rustflags.arg(sysroot_str); } <del> // https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20link.20new.20library.20into.20stage1.2Frustc if self.config.llvm_enzyme { rustflags.arg("-l"); rustflags.arg("Enzyme-19"); } </del> let use_new_symbol_mangling = match self.config.rust_new_symbol_mangling { Some(setting) => { // If an explicit setting is given, use that

A while ago we merged the first backend pr to enable automatic differentiation in Rust: This was good enough to add and enable the config in and run . We would now like to improve the integration to also successfully run (to use Rust in our autodiff compiler explorer). and I looked into it for a while and while it seems like a simple linker issue, we didn't fully understood where it comes from and what's the best way to fix it. This commit has a few more changes (not yet upstreamed) that might help for understanding how enzyme is used We also have documentation here: Back to the issue. We first build Enzyme (a git submodule) and then try to link it. To copy Jed's observations: The code to add is in inside fn cargo. Note that linking works correctly when building normal crates. Also, I find it odd that this one line of code yields so many repeat arguments (as in, Is there a better way to link Enzyme? Should we prefer to elide Enzyme linking when it isn't needed or be more explicit with paths so it is always found? A potentially related linking error only happens under MacOS: Related Zulip issue: https://rust- Tracking:
It's not just about dist builds; this happens on any build that triggers tool builds (e.g., running would fail too). This happens because enzyme linking flags are set in the general-purpose cargo function and used in every build even when they aren't needed. changes this so that the flags are set only for the rustc build as they aren't required for other builds.
Thank you for the quick fix!


Question: } } <del> pub fn retokenise_span(&self, span: Span) -> StringReader<'a> { lexer::StringReader::retokenize(&self.sess.parse_sess, span) } pub fn sub_span_of_token(&self, span: Span, tok: TokenKind) -> Option<Span> { let mut toks = self.retokenise_span(span); loop { let next = toks.next_token(); if next == token::Eof { return None; } if next == tok { return Some(next.span); } </del> <ins> /// Finds the span of `*` token withing the larger `span`. pub fn sub_span_of_star(&self, mut span: Span) -> Option<Span> { let begin = self.sess.source_map().lookup_byte_offset(span.lo()); let end = self.sess.source_map().lookup_byte_offset(span.hi()); // Make the range zero-length if the span is invalid. if begin.sf.start_pos != end.sf.start_pos { span = span.shrink_to_lo(); </ins> } <del> } // // Return the name for a macro definition (identifier after first `!`) // pub fn span_for_macro_def_name(&self, span: Span) -> Option<Span> { //     let mut toks = self.retokenise_span(span); //     loop { //         let ts = toks.real_token(); //         if ts == token::Eof { //             return None; //         } //         if ts == token::Not { //             let ts = toks.real_token(); //             if ts.kind.is_ident() { //                 return Some(ts.sp); //             } else { //                 return None; //             } //         } //     } // } </del> <ins> let sf = Lrc::clone(&begin.sf); </ins> <del> // // Return the name for a macro use (identifier before first `!`). // pub fn span_for_macro_use_name(&self, span:Span) -> Option<Span> { //     let mut toks = self.retokenise_span(span); //     let mut prev = toks.real_token(); //     loop { //         if prev == token::Eof { //             return None; //         } //         let ts = toks.real_token(); //         if ts == token::Not { //             if prev.kind.is_ident() { //                 return Some(prev.sp); //             } else { //                 return None; //             } //         } //         prev = ts; //     } // } </del> <ins> self.sess.source_map().ensure_source_file_source_present(Lrc::clone(&sf)); let src = sf.src.clone().or_else(|| sf.external_src.borrow().get_source().map(Lrc::clone))?; let to_index = |pos: BytePos| -> usize { (pos - sf.start_pos).0 as usize }; let text = &src[to_index(span.lo())..to_index(span.hi())]; let start_pos = { let mut pos = 0; tokenize(text) .map(|token| { let start = pos; pos += token.len; (start, token) }) .find(|(_pos, token)| token.kind == TokenKind::Star)? .0 }; let lo = span.lo() + BytePos(start_pos as u32); let hi = lo + BytePos(1); Some(span.with_lo(lo).with_hi(hi)) } </ins> /// Return true if the span is generated code, and /// it is not a subspan of the root callsite.

contains a function, which allows to to, well, retokenize existing span: There's only caller of this function: And there's only one caller of that caller: In other words, the only reason why we need is to get the span of hir::Usewhich happens to be a glob import. ( rls needs to know the span of use foo:: with explicit list of imported items" code action. This was the first demoed code action and is still that is implemented ) I'd like to remove the function, as it is one of the few remaining things that requires to be public, and as it is very much a hack anyway. Additionally, I believe I've broken this function accidently a while ago: Rather than retokenizing a span, it retokenized file from the begining until the end of the span (whcih, as uses are usually on top, worked correctly most of the times by accident). What would be the best way to fix this? Add hir::Use-- this seem to be the "proper" solution here Move hack's implementation to where it belongs: in , just fetch the text of the file and look for ('') Remove the deglog functionlity from RLS? I don't like this option as it handicaps the RLS before we formally decided to deprecated it. But I don't completely disregard it either, as, as a whole, it seems to be a full-stack one off hack penetrating every layer of abstraction. WDYT?
I'd suggest the second alternative (move hack's implementation to in librutcsaveanalysis), save analysis is a home of many hacks already and one more until save analysis is deprecated in its entirety won't hurt. Adding span for would be ok if it were useful for anything else at least.


Question: for possible_ancestor in min_cap_list.iter_mut() { match determine_place_ancestry_relation(&place, &possible_ancestor.place) { // current place is descendant of possible_ancestor <del> PlaceAncestryRelation::Descendant => { </del> <ins> PlaceAncestryRelation::Descendant | PlaceAncestryRelation::SamePlace => { </ins> ancestor_found = true; let backup_path_expr_id = possible_ancestor.info.path_expr_id;

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