Question: &self.buf } <ins> /// Returns a mutable reference to the internal buffer. /// /// This can be used to write data directly into the buffer without triggering writers /// to the underlying writer. /// /// That the buffer is a `Vec` is an implementation detail. /// Callers should not modify the capacity as there currently is no public API to do so /// and thus any capacity changes would be unexpected by the user. pub(in crate::io) fn buffer_mut(&mut self) -> &mut Vec<u8> { &mut self.buf } </ins> /// Returns the number of bytes the internal buffer can hold without flushing. /// /// # Examples

When I built and ran the release version, the speed jumped to over 1 GB/s.
With merged you can now (on next nightly) use to control the chunk size of . Since this relies on specialization it only works if you pass a directly, any other wrapper around it would disable this optimization.


Question: <ins> #![feature(const_generics)] pub struct Num<const N: usize>; // Braces around const expression causes crash impl Num<{5}> { pub fn five(&self) { } } </ins>

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


Question: } pub fn foobar() {} <ins> pub type Alias = u32; pub struct Foo { pub x: Alias, } impl Foo { pub fn a_method(&self) {} } pub trait Trait { type X; const Y: u32; } impl Trait for Foo { type X = u32; const Y: u32 = 0; } </ins>

It looks like a CSS rule is being applied incorrectly. It also looks weird if you click through to the type alias's page (). ! !
I'm not really sure, could that be slipped in ?
It turns out it was actually much more recent. The PR causing the regression was , cc searched nightlies: from nightly-2021-05-01 to nightly-2021-06-12 regressed nightly: nightly-2021-06-04 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The culprit CSS rule is here: It also caused which was fixed by .
Ah, I have missed this one. Sending a fix.
Assigning priority as in the prioritization working group. label: +P-medium -I-prioritize
The fix should be merged in less than 3 hours. ;)
I know, but we had already agreed on a priority :)
Oh I see. Thanks for taking care of that then! :)


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type="lib"] pub extern crate core; </ins>

On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.


Question: <ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![crate_type="lib"] pub extern crate core; </ins>

In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .


Question: } /* Code highlighting */ <del> .cm-s-default span.cm-keyword {color: #803C8D;} </del> <ins> .cm-s-default span.cm-keyword {color: #8959A8;} </ins> .cm-s-default span.cm-atom {color: #219;} <del> .cm-s-default span.cm-number {color: #2AA198;} .cm-s-default span.cm-def {color: #256EB8;} .cm-s-default span.cm-variable {color: black;} .cm-s-default span.cm-variable-2 {color: #817E61;} .cm-s-default span.cm-variable-3 {color: #085;} </del> <ins> .cm-s-default span.cm-number {color: #3E999F;} .cm-s-default span.cm-def {color: #4271AE;} /*.cm-s-default span.cm-variable {color: #C82829;}*/ .cm-s-default span.cm-variable-2 {color: #6F906C;} .cm-s-default span.cm-variable-3 {color: #B76514;} </ins> .cm-s-default span.cm-property {color: black;} .cm-s-default span.cm-operator {color: black;} <del> .cm-s-default span.cm-comment {color: #A82323;} .cm-s-default span.cm-string {color: #866544;} .cm-s-default span.cm-string-2 {color: #F50;} </del> <ins> .cm-s-default span.cm-comment {color: #8E908C;} .cm-s-default span.cm-string {color: #718C00;} .cm-s-default span.cm-string-2 {color: #866544;} </ins> .cm-s-default span.cm-meta {color: #555;} /*.cm-s-default span.cm-error {color: #F00;}*/ .cm-s-default span.cm-qualifier {color: #555;} .cm-s-default span.cm-builtin {color: #30A;} .cm-s-default span.cm-bracket {color: #CC7;} <del> .cm-s-default span.cm-tag {color: #170;} </del> <ins> .cm-s-default span.cm-tag {color: #C82829;} </ins> .cm-s-default span.cm-attribute {color: #00C;} /* The rest

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


Question: ///   as the compiler doesn't need to prove that it's sound to elide the ///   copy. /// <ins> /// Unaligned values cannot be dropped in place, they must be copied to an aligned /// location first using [`ptr::read_unaligned`]. /// </ins> /// [`ptr::read`]: ../ptr/fn.read.html <ins> /// [`ptr::read_unaligned`]: ../ptr/fn.read_unaligned.html </ins> /// /// # Safety ///

The docs for  state: And include an example which uses to copy the value from an unaligned pointer into an aligned one. However, the docs for  state: Either the docs for are wrong, and does not need to be aligned, or the example for invokes UB and should be updated to use
cc (It's also notable that the example in is wrong when it uses as is seen if you move the statement out of the block; we should fix that ASAP)
Good catch! What we'd really want is , I think... we don't want an intermediate value on the stack. Feel free to suggest code that we can use instead. We have several doctests that need They have been there since 1.0 and longer, probably. But nobody listens to me when I say that there is existing code that we need to support ASAP.
The example given is just using to put it on the stack anyway. If you're having to copy the value at all, there's really no reason to use at that point, since the only reason to use it instead of is to avoid the copy (which is optimized out in release mode anyway). I think we can probably just remove the unaligned example entirely and change the documentation to read: I think we should probably mention the caveat WRT the optimizer eliminating the copy (or can it even do that in this case? The docs mention that the drop glue generated for packed structs does this copy automatically, I'm curious if it's doing so in a way that is UB or if the copy is just the price you have to pay here. It's also worth noting that there's no way to an unsized value through an unaligned pointer, but I'm not sure that's worth bringing up at all in the docs, since there's no reasonable way to actually get that pointer in the first place.
Oh, good point. Yeah then you can basically just make it , right? I wonder why / ever got used here? Well but wouldn't it make sense for that text to come with an example? It cannot, because then it would be introducing alignment errors. Uh... yeah. With it could work. Doesn't seem like a reasonable thing to have either way?
Presumably because they wanted the example to continue to use Sure, we could -- it just wouldn't ever call the function being documented.


Question: ///   as the compiler doesn't need to prove that it's sound to elide the ///   copy. /// <ins> /// Unaligned values cannot be dropped in place, they must be copied to an aligned /// location first using [`ptr::read_unaligned`]. /// </ins> /// [`ptr::read`]: ../ptr/fn.read.html <ins> /// [`ptr::read_unaligned`]: ../ptr/fn.read_unaligned.html </ins> /// /// # Safety ///

Yes, it's just unrelated to dropping unaligned pointers since the only place you can reasonably copy them to is the stack. Unless you happen to already have an valid pointer of the proper size and alignment sitting around
I'm not actually sure unalgined DSTs are so unreasonable. For example, is only stopped by this rule: Which could be solved if we had e.g. a way to express "does not have drop glue" as a bound ( doesn't work for obvious reasons). In any case, I think "copy unaligned" functions make sense but we might want to consider multiple variants for src only / dest only / both unaligned. This can be expressed in LLVM IR though in a brief test I couldn't demonstrate that it currently makes a codegen difference (but I could only try on x86_64, where alignment rarely matters for codegen).
:rofl: fair. I guess all of this is basically saying an in-place drop of unaligned data is just not possible. Do an "out-of-place" drop instead.
Actually looks like the use of an unaligned pointer in the doctest just caused to fail to land. ;)
Proposed fix at


Question: pub const FILE_TYPE_PIPE: u32 = 3; <ins> pub const CP_UTF8: DWORD = 65001; pub const MB_ERR_INVALID_CHARS: DWORD = 0x08; pub const WC_ERR_INVALID_CHARS: DWORD = 0x80; </ins> #[repr(C)] #[derive(Copy)] pub struct WIN32_FIND_DATAW {

(and similarly, should call ) Windows provides these nice functions which performantly implement utf-8 <-utf-16 conversions. We should probably call them in the standard library when possible.
Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages. And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.
Do we have any good benchmarks for console I/O perf?
A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?
For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.
I don't think we do because most benchmarks suppress console output.
I did do a benchmark, and interestingly, ASCII text was about twice as fast with as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this. See benchmarks at [strega-nil/rust-bench-cvt-utf8-utf16][]. [strega-nil/rust-bench-cvt-utf8-utf16]: Run on M1 chip: someone may want to check on an x64 chip, since that might be faster.
Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.
There are now (since Windows 10, 1809) which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.
In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?
yeah, I think it's unlikely that the complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.


Question: pub const FILE_TYPE_PIPE: u32 = 3; <ins> pub const CP_UTF8: DWORD = 65001; pub const MB_ERR_INVALID_CHARS: DWORD = 0x08; pub const WC_ERR_INVALID_CHARS: DWORD = 0x80; </ins> #[repr(C)] #[derive(Copy)] pub struct WIN32_FIND_DATAW {

I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:
Mmh, thanks I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks! Nicole


Question: // inferred in this method call. let arg = &args[i]; let arg_ty = self.node_ty(arg.hir_id); <del> err.span_label( arg.span, &format!( "this is of type `{arg_ty}`, which causes `{ident}` to be  inferred as `{ty}`", ), ); </del> <ins> if !arg.span.overlaps(mismatch_span) { err.span_label( arg.span, &format!( "this is of type `{arg_ty}`, which causes `{ident}` to be  inferred as `{ty}`", ), ); } </ins> param_args.insert(param_ty, (arg, arg_ty)); } }

I tried this code on nightly: I expected to see this happen: compiler does not panic. Instead, this happened: compiler panics and suggests I open a bug report. I initially posted to , but says this is a different issue, despite panicking on the same line in . (Though I'm realizing now that might be the proximal cause but not very related to the root cause.) : <details<summaryPanic message</summary<p</p</detailsThanks all for maintaining Rust, by the way.
Thanks!
searched nightlies: from nightly-2022-12-01 to nightly-2023-01-21 regressed nightly: nightly-2023-01-07 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
It's , i'll fix it unless someone beats me to it since I'm busy this weekend
Hi it's Justin from Commure :wave:. I found a compiler panic you made :grinning:
sorry for causing you trouble


Question: } } <ins> fn handle_assign(&mut self, expr: &'tcx hir::Expr<'tcx>) { if self .typeck_results() .expr_adjustments(expr) .iter() .any(|adj| matches!(adj.kind, ty::adjustment::Adjust::Deref(_))) { self.visit_expr(expr); } else if let hir::ExprKind::Field(base, ..) = expr.kind { // Ignore write to field self.handle_assign(base); } else { self.visit_expr(expr); } } </ins> fn handle_field_pattern_match( &mut self, lhs: &hir::Pat<'_>,

<!-- 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. --Here's a reduced test-case from Firefox source code: Compiling that program warns with: Which is obviously not true. <!-- 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. --:
Seems like this is a regression from .
cc
Oops, sorry! Technically, field is, in fact, never read. What went wrong is is written and read through other ways. I think restricting the lint to non-reference fields should work, and will submit a PR to do so quickly. Please double check whether my thinking is correct.
Ah, yeah, I somehow thought that the macro was needed to trigger the bug but it is not. That sounds good. Writes to mutable references have side effects so doing that seems ok.
Would that also cover this case here, in the idna crate? (The field is a reference to an type, which is in fact returned to the caller of .)
Yeah, I think it's the same.
Ah, this was closed, but the bug leaked into beta (as mentioned in ) while the fix is only in nightly. Reopening and tagging as stable-to-beta regression
Assigning and removing .
As noted on , we're going to resolve the beta issue by reverting PR on beta (which I have assigned myself to take care of).
This was a regression affecting beta 1.51, closing this.


Question: rbml_w.wr_tagged_str(tag_crate_hash, hash.as_str()); } <ins> fn encode_rustc_version(rbml_w: &mut Encoder) { rbml_w.wr_tagged_str(tag_rustc_version, &rustc_version()); } </ins> fn encode_crate_name(rbml_w: &mut Encoder, crate_name: &str) { rbml_w.wr_tagged_str(tag_crate_crate_name, crate_name); }

When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata


Question: <ins> #![deny(warnings)] //! Email me at <hello@localhost>. //~^ ERROR unknown disambiguator `hello` //! This should *not* warn: <hello@example.com>. </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: rustdoc parses the link as an email address and renders it as a mailto: link. Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --(from a GitHub Actions run, the latest nightly won't install on my Arch box due to broken components)
This turned out to be a bug in my docs; I didn't intend for this to be rendered as a link, but I was hoping for a better error message.
I think this PR introduced this new behavior:
This is weird - rustdoc should be ignoring any link that has in it:
Ah I see the issue - should only be reported if the link isn't ignored. do you have time to fix it? It should be as simple as adding the same check here:
Assigning and removing as in the prioritization working group. label: +P-medium -I-prioritize
can part of the fix here be to improve the error message? "Unknown disambiguator" doesn't tell me much about what is wrong or how to fix it.
I'm confused. After there won't be an error message, because the link shouldn't have been treated as an intra-doc link in the first place. Are you asking for a lint that warns about docs that will be rendered as mailto: links? I'm not sure how useful that is, mailto: links are normal and reasonable to write.
based on the UI tests that are checked in, if I actually intend to use an intradoc link with a disambiguator and fat finger as , the error message is not super friendly.
Hmm, what would you like to see instead? There's quite a few valid disambiguators, I'm not sure it makes sense to list them all. Maybe we could add a header to the disambiguator section of and link there?
Ideally I'd like to see a suggestion to use a disambiguator that corresponds to an item that is currently in scope or otherwise resolvable via the path after the invalid disambiguator.


Question: <ins> #![deny(warnings)] //! Email me at <hello@localhost>. //~^ ERROR unknown disambiguator `hello` //! This should *not* warn: <hello@example.com>. </ins>

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


Question: <ins> // This used to cause an ICE for an internal index out of range due to simd_shuffle_indices being // passed the wrong Instance, causing issues with inlining. See #67557. // // run-pass // compile-flags: -Zmir-opt-level=3 #![feature(platform_intrinsics, repr_simd)] extern "platform-intrinsic" { fn simd_shuffle2<T, U>(x: T, y: T, idx: [u32; 2]) -> U; } #[repr(simd)] #[derive(Debug, PartialEq)] struct Simd2(u8, u8); fn main() { unsafe { let _: Simd2 = inline_me(); } } #[inline(always)] unsafe fn inline_me() -> Simd2 { simd_shuffle2(Simd2(10, 11), Simd2(12, 13), [0, 3]) } </ins>

It should use . ( is the second field of .) While both instances are normally equal, they can differ after running the mir inliner. In that case the promoted will refer to the inlined function. modify labels: +A-mir +C-bug +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Can I give this a go? claim
Do you have any specific tests in mind I should add to check for the correct behaviour?
should be a test if the mir inliner would to inline . Somehow it doesn't though.
You might be running into this unfortunate check Try moving below .
Wow, that's hilarious. With just the changes suggested, the inlining still doesn't work properly, but doesn't seem to break any existing stuff. But I've just tried this and yeah, putting ret_slice below main has made the MIR inliner work.
This does inline, but somehow no assertion fires with current rustc. The printed MIR doesn't seem to show the the def_id from which the promoted originates, so I don't know what the problem is.
Unless I'm misunderstanding something, isn't this the correct behaviour? Both of those assertions are true, and swapping and around in the assertions correctly triggers an assertion failure.
I forgot that this problem was only with .
I got a working test:
Ah, that's a good test case. Yeah, that's definitely not the expected behaviour. While messing about with your example, I also managed to come across an ICE with this slightly shorter version: causes an ICE currently due to an internal index out of range. The good news is that the changes you suggested fixes both of these test cases. Good spot :) I'm putting up the PR now.


Question: #[derive(Copy, Clone)] pub struct Quad { a: u64, b: u64, c: u64, d: u64 } <ins> #[derive(Copy, Clone)] pub struct QuadFloats { a: f32, b: f32, c: f32, d: f32 } </ins> #[repr(C)] #[derive(Copy, Clone)] pub struct Floats { a: f64, b: u8, c: f64 }

We encountered this with WebRender, where we exposed a method in Rust to the Gecko, and the last parameters supplied appeared random on the Rust side. I made a reduced test case adapted from it that you can grab at: It is a very simple test case where the C++ program puts all the parameters on the stack, prints the expected values of some of them, and calls the Rust method. The Rust method prints the values it received. We have enough parameters to fill up the registers used in the calling convention, and once we get to pushing things on the stack, it goes wrong. You can see from the output that they mismatch. ./build- && ./run- outputs c++ expect width=7 height=8 c++ expect slice=9 10 11 12 c++ expect outset=13. 13. 13. 13. c++ expect repeat h=0 v=0 got rust image 6 width 7 height 8 got rust slice SideOffsets { top: 9, right: 10, bottom: 11, left: 12 } got rust outset LayoutGeometry { top: 0.0, left: 0.0, width: 0.0, height: 0.0 } got rust repeat h=26 v=58 Note that the earlier parameters are correct, but the last 3 (outset, repeat h and repeat v) are all incorrect.
Is there an upstream issue in WebRender you can link? What platform is this happening on?
The Gecko side integrating with WebRender was disabled, and I have been working to re-enable this in You can find the code in question at: I intend to just work around this using structs for the moment as part of the aforementioned bug.
We're seeing this on all of our x64 platforms (win, mac, linux; all using clang). It looks like a pretty clear bug in our sysv callee ABI for x64 when there are lots of arguments.
<details<summaryrustc callee llvm-ir </summary</details<details<summaryclang caller llvm-ir </summary</detailsJust the signatures:
Note to self: can go negative from scalar integer arguments after the 6 integer registers have been exhausted and then is always true. Will try to fix soon (also I wonder if this is a stable-to-stable regression from years ago?).


Question: #[derive(Copy, Clone)] pub struct Quad { a: u64, b: u64, c: u64, d: u64 } <ins> #[derive(Copy, Clone)] pub struct QuadFloats { a: f32, b: f32, c: f32, d: f32 } </ins> #[repr(C)] #[derive(Copy, Clone)] pub struct Floats { a: f64, b: u8, c: f64 }

Looks like this was working circa 1.0, but has been broken at least since 1.12. Oof.
Do you need this fixed on beta as well, btw?
it would certainly be great if you uplifted this, but we have to work around it for the next few weeks anyway


Question: #[doc(keyword = "CookieMonster")] pub mod keyword {} <ins> /// Just some type alias. pub type SomeType = u32; </ins>

: Local docs: ! But has the same issue: Probably caused by: ()
It seems like this css rule: applies to this element: !. Before () this rule wouldn't have applied because it would've been contrained by instead of .
This also had some other side-effects here: ! The search results have top/bottom margins compared to the previous styling.
The second issue was fixed in I'm checking for the first one, unless you want to send a PR?
Hmm, sorry I didn't/don't have much time to dig into this more. I couldn't think of an immediate fix for this because it kinda looked non-trivial (to me) :/
Don't worry, I'll send a fix in the next hours then.


Question: } }; <del> if let Some(path) = path && let Ok(mut out) = crate::fs::File::options().create(true).append(true).open(&path) { write(&mut out, BacktraceStyle::full()); } </del> if let Some(local) = set_output_capture(None) { <del> write(&mut *local.lock().unwrap_or_else(|e| e.into_inner()), backtrace); </del> <ins> write(&mut *local.lock().unwrap_or_else(|e| e.into_inner())); </ins> set_output_capture(Some(local)); } else if let Some(mut out) = panic_output() { <del> write(&mut out, backtrace); </del> <ins> write(&mut out); </ins> } }

slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.


Question: <ins> // aux-build:issue-66286.rs // Regression test for #66286. extern crate issue_66286; #[issue_66286::vec_ice] pub extern fn foo(_: Vec(u32)) -> u32 { //~^ ERROR: parenthesized type parameters may only be used with a `Fn` trait 0 } fn main() {} </ins>

Follow up to and , as per Minimize a test that exercises the same codepath as
As already stated in the proc macro can be reduced to:
How do you write a UI test that depends on 3rd-party libraries?
is an example of a test that relies on a procmacro, and we can use snippet for the necessary proc_macro being tested.


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-android: FIXME(#9116) Bus error </del> use std::mem; #[repr(packed)]

Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:


Question: actual: Ty<'tcx>, ti: TopInfo<'tcx>, ) -> Option<DiagnosticBuilder<'tcx, ErrorGuaranteed>> { <del> self.demand_eqtype_with_origin(&self.pattern_cause(ti, cause_span), expected, actual) </del> <ins> let mut diag = self.demand_eqtype_with_origin(&self.pattern_cause(ti, cause_span), expected, actual)?; if let Some(expr) = ti.origin_expr { self.suggest_fn_call(&mut diag, expr, expected, |output| { self.can_eq(self.param_env, output, actual).is_ok() }); } Some(diag) </ins> } fn demand_eqtype_pat(

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


Question: infer::RelateOutputImplTypes(_) => "mismatched types", infer::MatchExpressionArm(_, _) => "match arms have incompatible types", infer::IfExpression(_) => "if and else have incompatible types", <ins> infer::IfExpressionWithNoElse(_) => "if may be missing an else clause", </ins> }; self.tcx.sess.span_err(

I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:


Question: <ins> // The various #[inline(never)] annotations and std::hint::black_box calls are // an attempt to make unwinding as non-flaky as possible on i686-pc-windows-msvc. #[inline(never)] fn generate_backtrace(x: &u32) { std::hint::black_box(x); let bt = std::backtrace::Backtrace::force_capture(); println!("{}", bt); std::hint::black_box(x); } #[inline(never)] fn fn_in_backtrace(x: &u32) { std::hint::black_box(x); generate_backtrace(x); std::hint::black_box(x); } fn main() { let x = &41; std::hint::black_box(x); fn_in_backtrace(x); std::hint::black_box(x); } </ins>

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


Question: <ins> // The various #[inline(never)] annotations and std::hint::black_box calls are // an attempt to make unwinding as non-flaky as possible on i686-pc-windows-msvc. #[inline(never)] fn generate_backtrace(x: &u32) { std::hint::black_box(x); let bt = std::backtrace::Backtrace::force_capture(); println!("{}", bt); std::hint::black_box(x); } #[inline(never)] fn fn_in_backtrace(x: &u32) { std::hint::black_box(x); generate_backtrace(x); std::hint::black_box(x); } fn main() { let x = &41; std::hint::black_box(x); fn_in_backtrace(x); std::hint::black_box(x); } </ins>

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


Question: <ins> // The various #[inline(never)] annotations and std::hint::black_box calls are // an attempt to make unwinding as non-flaky as possible on i686-pc-windows-msvc. #[inline(never)] fn generate_backtrace(x: &u32) { std::hint::black_box(x); let bt = std::backtrace::Backtrace::force_capture(); println!("{}", bt); std::hint::black_box(x); } #[inline(never)] fn fn_in_backtrace(x: &u32) { std::hint::black_box(x); generate_backtrace(x); std::hint::black_box(x); } fn main() { let x = &41; std::hint::black_box(x); fn_in_backtrace(x); std::hint::black_box(x); } </ins>

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


Question: ); } else { // Trivial case: `T` needs an extra bound: `T: Bound`. <del> let (sp, suggestion) = match super_traits { None => predicate_constraint( </del> <ins> let (sp, suggestion) = match ( generics .params .iter() .filter( |p| !matches!(p.kind, hir::GenericParamKind::Type { synthetic: Some(_), ..}), ) .next(), super_traits, ) { (_, None) => predicate_constraint( </ins> generics, trait_ref.without_const().to_predicate(tcx).to_string(), ), <del> Some((ident, bounds)) => match bounds { [.., bound] => ( bound.span().shrink_to_hi(), format!(" + {}", trait_ref.print_only_trait_path().to_string()), ), [] => ( ident.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), }, </del> <ins> (None, Some((ident, []))) => ( ident.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), (_, Some((_, [.., bounds]))) => ( bounds.span().shrink_to_hi(), format!(" + {}", trait_ref.print_only_trait_path().to_string()), ), (Some(_), Some((_, []))) => ( generics.span.shrink_to_hi(), format!(": {}", trait_ref.print_only_trait_path().to_string()), ), </ins> }; err.span_suggestion_verbose(

The following code errors, and the error contains a suggestion how to fix the error: The error message states: Obviously, writing is invalid syntax.
It seems the issue is that it's inserting the suggestion after the trait name and before the generics, rather than after the generics.
No-nightly-features code that exhibits the same problem: label -requires-nightly (should the F-labels go as well?)


Question: LLC_$(1)=$$(CFG_LLVM_INST_DIR_$(1))/bin/llc$$(X_$(1)) LLVM_ALL_COMPONENTS_$(1)=$$(shell "$$(LLVM_CONFIG_$(1))" --components) <ins> LLVM_VERSION_$(1)=$$(shell "$$(LLVM_CONFIG_$(1))" --version) </ins> endef

I believe this is due to travis using system llvm which misses the fix backported in . cc
Can we do anything about this?
Our best bet is to add a for tests, I think (alternative is to drop support for LLVM pre 3.9, which would be a shame, even if its buggy in certain cases). Implementation of such directive could be implemented by injecting an environment variable or some such (done ) and checking for that in
There's no need to set an extra environment variable, just check if is set (or if you're boring :wink: )
but… but… what if people have on their own systems too?
cc
no we do not have existing infrastructure for this. I'd prefer to avoid as that's not the relevant piece here, but rather something like or . Distros or anyone else building with an older LLVM are likely to hit this and we'd need a solution for them as well. That being said I think it's fine to temporarily disable the test until we get that. There's basically a 0% chance of us regressing that test as it's just an LLVM bug, and they already have a regression test upstream as well.
Another option would be to create a base Docker image (publishing it to Docker Hub) that is just and the appropriate steps to build whatever version of LLVM we want.
We currently advertise ourselves as supporting LLVM 3.7+, and Travis is kinda our test for that, so I'd prefer to not pull that forward just yet (but instead just fix this)
For the record, I downgraded our LLVM version in a botched rebase and only this test stopped it at bors. Hopefully, someone would have noticed the absence of a fix, but you can't count of that.
touche!


Question: ///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

The following sample crashed rustc: Removing the , or unwrapping the (leaving only ), or replacing the predicate (leaving ), solves the crash. Reproduced on Windows 64-bit, Fedora 32-bit, Ubuntu 64-bit. Full crash log (thanks to ) @ Short crash message:
Fixed pending
Fixed in


Question: ///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

While I was playing with the new rustc 0.6, I encountered an internal compiler error The source code is here: Compiler version is 0.6, built with gcc, on OS X 10.7.5
If you run rustc under gdb and break on , could you paste the backtrace here?
OK. Here is the backtrace:
Looks like stack exhaustion to me. What happens if you remove ?
The code compiles with no problem when I wrap the rest of the code with mod block. Like:
This yields a proper error message now; closing.


Question: ///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

When you download the 0.6 tarball and execute ./configure && make, a download occurs. and a wget info dump appears. It would be really awesome if this piece was integrated with the tarball. Not all environments are friendly to downloading arbitrary code off the net. E.g., I might be in a SCIF[1] and experimenting with Rust on a machine disconnected from the public net. Or I might be on a laptop working in a no-wifi area. :-/ (I know this is probably a real low priority issue, but it IS a (usually minor) hassle) [1]
Please note that you can avoid that if you already have a (compatible) locally installed rust compiler. Check the --local-rust and --local-rust-root parameters for ./configure. Also, I'm against bundling binaries in source tarballs. They are target-dependent and bundling all of them will make the released archive quite large. Downloading an external bootstrapper is a minor issue for downstream packagers too, though. See
far-future
Yeah, you can also just populate the directory in your builddir with an appropriate snapshot tarball. There's not much else we can do here. Putting binaries in a source tarball feels even worse, to me. Closing as I don't expect we're going to much change the requirements here and have several workable workarounds.


Question: ///     assert_eq!(v.len(), 42); /// } /// ``` <del> /// should be </del> <ins> /// </ins> /// ```rust <ins> /// // should be </ins> /// fn foo(v: &[i32]) { ///     assert_eq!(v.len(), 42); /// }

As seen in , LLVM has lots of places where it will insert calls to libm directly, not switching stacks. One of places that I recall seeing this before is the translation of the instruction. Rust has floating point modulus and presumably it is doing it in the red zone.
We can solve this with an lang item.
Is this an issue with calls to compiler-rt too? Or are they compiled in some special way to avoid the issue?
Nominating for milestone 5, production-ready
, , and are also all generated. As far as I can tell, we can't prevent it from generating these by altering the IR we output.
We can possibly be selective about when we emit memcpy/memmov, second guessing LLVM (like, never for big things)
accepted for production-ready milestone
Closing due to segmented stacks being gone (stack switches no longer a thing)


Question: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(conservative_impl_trait)] fn foo() -> impl Copy { foo } fn main() { foo(); } </ins>

Code works cc
Bug triage: on current nightly (), this no longer is an ICE, but yields the following error:


Question: LL |     foo::<_, L>([(); L + 1 + L]); |     ^^^^^^^^^^^ <del> error: aborting due to 5 previous errors </del> <ins> error: unconstrained generic constant `{const expr}` --> $DIR/issue_114151.rs:17:5 | LL |     foo::<_, L>([(); L + 1 + L]); |     ^^^^^^^^^^^ | = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` error: aborting due to 6 previous errors </ins> Some errors have detailed explanations: E0107, E0308. For more information about an error, try `rustc --explain E0107`.

we should change the following function to use a instead of Using a walker causes the control-flow to be a lot more complicated and given that this code is soundness-critical, we should make sure it's as easy to understand as possible <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: target_os = "openbsd", target_arch = "aarch64", no_elf_tls))] <ins> #[doc(hidden)] </ins> mod imp { use prelude::v1::*;

There is an  in the scoped TLS module, which allows for sharing of data that wasn't meant to be shared. An unqualified should only_ be used when provides some sort of threadsafe locking mechanism. and do not. This lets us, for example, clone an or between threads, in safe code: Here, we have clones from different threads being interleaved, which can cause unsafety if there's a race on the refcount. We could also cause unsafety with a , or any other non-Sync type. basically lets us share across threads even if . I put the sleeps in there because somehow without them the routines are run serially. Note that this is not a problem with the API. I'm using here because to exploit one needs to be able to share across threads, and has an additional bound which doesn't satisfy. Any usable API will probably have to make the assumption that . Nor is this a problem with , since it can be done with , too. Solution: Make it ... I think. I'm not familiar with this API, and I'm not sure why it's even in the first place.
cc
cc This seems concerning: this is designed to be thread-local, so that e.g. storing a works (which would be safe, if it were guaranteed to stay on one thread). However currently requires unconditionally, hence this overly-accepting impl.
Qualifying the impl with breaks scoped TLS for (see the associated PR); because becomes no longer and thus can't be stuffed inside a static.
I believe the only way statics can be safe is by requiring the absence of Sync. That may sound odd, but consider the following: - sending thread-local references across threads is memory unsafe even with no interior mutability a static with no interior mutability is almost entirely useless, certainly not a common case non- containers offering interior mutabilities are cheaper and preferred to ones, where they can be used The main issue is actually within the libstd TLS implementation: is a wrapper for getters so it's unaffected by it, but may live in a static or a global one, depending on whether the platform natively supports TLS or not. -ing a across threads is actually safe on the architectures which do not have native TLS support. However, allowing it on some architectures and not on others is undesirable. Should use an accessor model like ?


Question: target_os = "openbsd", target_arch = "aarch64", no_elf_tls))] <ins> #[doc(hidden)] </ins> mod imp { use prelude::v1::*;

Then the actual borrow of a static is an implementation detail and happens on the thread where the key is used, not where it was itself borrowed.
"I believe the only way #[threadlocal] statics can be safe is by requiring the absence of ." This is wrong, I think. For example, one might use thread local data for intrusive linked lists of hazard pointers. They would be thread local but might still be (one can guarantee existence with scoped threads or in certain circumstances where threads are bound to cores). That said you can obviously come up with other representations. In any case, I've mostly come around to believing that we need a separate lifetime (not just for this, but for things like ensuring that can't catch an error in a thread that changes thread local data, violating exception safety).
Based on what wrote, it seems like the TLS interface requires a that only allows non- data and is still accessible like one. One idea I had of how to enable this in todays Rust is to make generate a unit like struct instead of a . That struct would be and have a impl: According to this could also help with , but I'm not familiar enough with the TLS API in general to really reason about this.
I was expecting the impl to target an intermediary type, not the contents themselves. and have their own APIs to deal with. You would still be about to use the TLS API provided by libstd with thread-safe data, it's just the low-level which would have the requirement. Ideas of thread-local lifetimes predate the removal of from , and I'm not sure how relevant they are anymore. I'm also conflating thread-safe data access and thread lifetime... but how long does a thread live? What would unify with? Actually, there's an... easy solution for this. Somehow we were blinded by language semantics, but their details are fluid. It is trivial to make borrows of behave like borrows of an arbitrary rvalue, allowing the resulting reference to be passed down, but not returned. That would ensure that the the thread is just as alive for such borrows as it is for stack ones. would still require a like has, because it may not be when native TLS is supported. But both their APIs are compatible with such a change.
Wouldn't that limit the usability of thread locals in some cases, though?


Question: target_os = "openbsd", target_arch = "aarch64", no_elf_tls))] <ins> #[doc(hidden)] </ins> mod imp { use prelude::v1::*;

e.g., wouldn't that make it difficult to have a thread local point to another thread local? Maybe I just have to think about it. (BTW, I'm aware we're just talking about the low-level API :)).
in a , borrows are , I didn't even think of that. First off, a global static shouldn't be allowed to borrow a static. And in general, having borrows in a is going to be difficult to support, except for non- data, because they would be right now. We could disallow borrows or we could give some kind of scope to those borrows. Which makes me think, as a compromise between a lifetime and , there could be a pseudo-(rvalue)-scope. Combined with the ability to leave out in globals' type (or not having a type at all), the scope should bubble up into users of those statics. They would behave as if they were borrowed before everything else in the function where they're used, but still not (and they can't be returned from functions).
There's a few intertwined issues here at play, so I just want to quickly summarize the way I see things: This does not affect as it which has an , which while sound should be fixed, allowing removal of the block for . A borrow of a static should not yield something with the lifetime, as that is clearly not sound. I'm not sure I follow why we might require the types in a are not , I haven't quite followed that. Due the cross-platform requirements of std, however, I believe the best solution here is to use the same strategy as with an indirect accessor to ensure the semantics are the same across platforms that have and those that don't (where a normal is used).
triage: P-medium This is an unstable API so it's not super-high priority to fix, but we should defnitely fix!
requiring that a is not is an easy way to ensure that a borrow of it, while , cannot escape the current thread. I've changed my mind and prefer an rvalue borrow semantic for , but it still is the case that and use non- statics (ignoring the workarounds for ). If was supported everywhere, having rvalue borrow semantics wouldn't hurt the std TLS API (aside from stability issues with ), as the access patterns are already through anonymous lifetimes (references passed to closures).


Question: target_os = "openbsd", target_arch = "aarch64", no_elf_tls))] <ins> #[doc(hidden)] </ins> mod imp { use prelude::v1::*;

Maybe a combined strategy, where borrows of statics are iff the data is not (and rvalue-like otherwise), might work better and would require fewer changes to the std TLS implementation.
Right, but returning a borrow with a lifetime for a global is unsafe for other reasons (the lifetime of the thread is not ).
how can it be abused without sending it to a different thread?
The actual values themselves do not have a lifetime, so it can be a source of unsafety to advertise otherwise. For example you could stick a into a TLS value with a destructor, but when the destructor runs that pointer could be invalid.


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)


Question: <ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>

It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.


Question: // handled below clean::ModuleItem(..) => {} <del> // impls/tymethods have no control over privacy clean::ImplItem(..) | clean::TyMethodItem(..) => {} </del> <ins> // trait impls for private items should be stripped clean::ImplItem(clean::Impl{ for_: clean::ResolvedPath{ id: ref for_id, .. }, .. }) => { if !self.exported_items.contains(for_id) { return None; } } clean::ImplItem(..) => {} // tymethods have no control over privacy clean::TyMethodItem(..) => {} </ins> } let fastreturn = match i.inner {

Trying to search for anything on results in a Javascript error: on line 313 of I'm on Chrome 30.0.1599.101 if that matters.
Weirdly, search results still appear if I search for most things, but not for anything starting with "sle" like "sleep".
This appears to be dying because of the method defined in . This shouldn't be showing up in the search because the entire module should be pruned as a result of it being private. This warrants more investigation...
Update: seems like it's not for "any" keyword as the OP states; for example or don't trigger any error for me. does for instance.
doesn't work either.
Happens to me too.
, , , , , , , and (and all shortened forms e.g. , ) don't work for me, but does work (i.e. shows results). The error I'm getting (on Firefox Nightly 29.0a1) is .
The error happens when a trait is implemented on a type that is pruned by one of the passes ( or ). The type was pruned but the implementation was not, so the search index included a method that referenced a missing type. fixes this.


Question: <ins> // Previously, in addition to the real cause of the problem as seen below, // the compiler would tell the user: // // ``` // error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or // predicates // ``` // // With this test, we check that only the relevant error is emitted. trait Foo {} impl<T> Foo for Bar<T> {} //~ ERROR cannot find type `Bar` in this scope fn main() {} </ins>

The second error in this snippet is "nonsense" because it says the type parameter is not constrained, while the real error was already reported — the actual type could not be imported. Found in: rustc 1.13.0-nightly ( 2016-09-26)
.


Question: <ins> pub trait MyTrait { type Assoc; } pub fn foo<S, T>(_s: S, _t: T) where S: MyTrait, T: MyTrait<Assoc == S::Assoc>, //~^ ERROR: expected one of `,` or `>`, found `==` //~| ERROR: this trait takes 0 generic arguments but 1 generic argument was supplied { } fn main() {} </ins>

<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: Playground: I expected to see this happen: The error message should indicate that the should be a single . Instead, this happened: The error message gives no hint of the correct syntax. It gives two errors, neither of which are helpful: This error is unhelpful because it says "expected one of or ", but is also allowed. Also, the suggestion to use curly braces is a red herring. This error is unhelpful because I am not specifying const arguments; I'm specifying associated types. Rust version according to 1.53.0
cc


Question: let tokens = match *nt { Nonterminal::NtItem(ref item) => prepend_attrs(sess, &item.attrs, nt, item.tokens.as_ref()), Nonterminal::NtBlock(ref block) => convert_tokens(block.tokens.as_ref()), <del> Nonterminal::NtStmt(ref stmt) => prepend_attrs(sess, stmt.attrs(), nt, stmt.tokens()), </del> <ins> Nonterminal::NtStmt(ref stmt) => { let do_prepend = |tokens| prepend_attrs(sess, stmt.attrs(), nt, tokens); if let ast::StmtKind::Empty = stmt.kind { let tokens: TokenStream = tokenstream::TokenTree::token(token::Semi, stmt.span).into(); do_prepend(Some(&LazyTokenStream::new(tokens))) } else { do_prepend(stmt.tokens()) } } </ins> Nonterminal::NtPat(ref pat) => convert_tokens(pat.tokens.as_ref()), Nonterminal::NtTy(ref ty) => convert_tokens(ty.tokens.as_ref()), Nonterminal::NtIdent(ident, is_raw) => {

This the the of a proc macro crate : And here is the of another crate: When building, this outputs: 49.0, 1.50.0-beta.5 rustc 1.51.0-nightly ( 2021-01-05) binary: rustc commit-hash: commit-date: 2021-01-05 host: x86_64-unknown-linux-gnu release: 1.51.0-nightly
cc
cc
Assigning as discussed as part of the and removing .
assigning to self to confirm if is the cause of the breakage, and if so, revert the PR until it can be revised to handle this case.
This is caused by us not handling properly - I'm working on a fix.
Opened


Question: } bb0: { <del> StorageLive(_2);                 // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 ((_2 as Some).0: i32) = const 1_i32; // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 discriminant(_2) = 1;            // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 _1 = ((_2 as Some).0: i32);      // scope 0 at $DIR/issue-73223.rs:3:14: 3:15 StorageDead(_2);                 // scope 0 at $DIR/issue-73223.rs:5:6: 5:7 ((_3 as Some).0: i32) = _1;      // scope 1 at $DIR/issue-73223.rs:7:22: 7:27 </del> <ins> StorageLive(_1);                 // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 ((_1 as Some).0: i32) = const 1_i32; // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 discriminant(_1) = 1;            // scope 0 at $DIR/issue-73223.rs:2:23: 2:30 _2 = ((_1 as Some).0: i32);      // scope 0 at $DIR/issue-73223.rs:3:14: 3:15 StorageDead(_1);                 // scope 0 at $DIR/issue-73223.rs:5:6: 5:7 ((_3 as Some).0: i32) = _2;      // scope 1 at $DIR/issue-73223.rs:7:22: 7:27 </ins> discriminant(_3) = 1;            // scope 1 at $DIR/issue-73223.rs:7:17: 7:28 <del> (_4.0: &i32) = &_1;              // scope 3 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </del> <ins> (_4.0: &i32) = &_2;              // scope 3 at $SRC_DIR/core/src/macros/mod.rs:LL:COL </ins> (_4.1: &i32) = const main::promoted[1]; // scope 3 at $SRC_DIR/core/src/macros/mod.rs:LL:COL // ty::Const // + ty: &i32

This little matrix processing code shows miscompilation if compiled with: But it compiles correctly with: With:
Hmm, on first glance the replacement it performs looks correct: It replaces local () with the return place . Previously the return place was only used in the block by a copy statement, so this transformation should be correct. Maybe this part of the diff causes a problem? We're using our return place as the return destination for the inner call. It's possible that there's an undocumented (and maybe unintended) assumption that the return place is not reused like this, either in other MIR optimizations or in codegen. Haven't looked too deeply yet though.
Ah, there's this bad call in LLVM IR: It passes a reference to as both the return pointer, and the second (immutable) argument.
we have this corresponding MIR, where we already incorrectly pass a reference to as an argument, while also assigning the call result to it: The destination propagation pass already has code that prevents merging a call destination with one of the arguments, but here we pass a reference instead. Curiously, the was produced by merging with , which is not really something the pass should be doing since a reference is taken to , and we avoid touching any local that has its address taken.
The propagation is disabled only if both locals have their address taken. Changing that to be more conservative does fix this issue. Minimized:
Oof, this should have been an , not an
Thanks
Opened with a fix


Question: // Create generics from the generics specified in the impl head. debug!("convert: ast_generics={:?}", generics); let def_id = ccx.tcx.map.local_def_id(it.id); <del> let ty_generics = ty_generics_for_type_or_impl(ccx, generics); </del> <ins> let ty_generics = ty_generics_for_impl(ccx, generics); </ins> let mut ty_predicates = ty_generic_predicates_for_type_or_impl(ccx, generics); debug!("convert: impl_bounds={:?}", ty_predicates);

If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high


Question: <ins> // Test for #78438: ensure underline alignment with many tabs on the left, long line on the right // ignore-tidy-linelength // ignore-tidy-tab fn main() { let money = 42i32; match money { v @ 1 | 2 | 3 => panic!("You gave me too little money {}", v), // Long text here: TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT //~^ ERROR variable `v` is not bound in all patterns v => println!("Enough money {}", v), } } </ins>

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


Question: #[stable(feature = "rust1", since = "1.0.0")] pub use self::mutex::{Mutex, MutexGuard}; #[stable(feature = "rust1", since = "1.0.0")] <ins> #[allow(deprecated)] </ins> pub use self::once::{Once, OnceState, ONCE_INIT}; #[stable(feature = "rust1", since = "1.0.0")] pub use crate::sys_common::poison::{PoisonError, TryLockError, TryLockResult, LockResult};

, anyone using the former . I guess we can't outright deprecate given our backwards compatibility policy, but I would like to lint on its usage and at the very least call it out in the documentation ("use instead"). This also opens the conversation around the larger problem of what to do with the parts of the API that would get superseded by new features, like const generics, or in this case const fns.
Can we just deprecate it?
Why is a problem?
Similarly, the initializers for the family of structs were deprecated in 1.34 and have a rustfix-able suggestion to use the function. For example, see .
"There should be only one way of doing it" I saw someone today get quite confused today as to why both existed in the first place, which required an explanation of 's backwards compatibility policy, behavior, and release schedules. I feel that we should have an aggressive funnel towards "the right way of doing things" across the board, that includes linting against usages that are only kept because of historical reasons. At the very least I'd like to see the documentation updated so that it preempts the questions I got asked today
/me Prepares plans to deprecate :) In all seriousness, imo someone's confusion as to why both existed and "only one way to do it" is a rather weak justification for churn when the old way isn't harmful in any way. Seems fine.
We deprecate things like ONCE_INIT 3 releases after their replacements (in this case Once::new specifically being a const fn) were . I can't find in the release notes when that happened, but if someone tracks it down, it should be an easy PR!
was stabilized . Didn't find any reference to it .
Was it callable as a const fn in 1.2.0?
The const-ness was made stable in the same PR as for AtomicUsize::new:


Question: let mut lifetime_to_bounds: FxHashMap<_, FxHashSet<_>> = Default::default(); let mut ty_to_traits: FxHashMap<Type, FxHashSet<Path>> = Default::default(); <del> let mut ty_to_fn: FxHashMap<Type, (Option<PolyTrait>, Option<Type>)> = Default::default(); </del> <ins> let mut ty_to_fn: FxHashMap<Type, (PolyTrait, Option<Type>)> = Default::default(); </ins> for p in clean_where_predicates { let (orig_p, p) = (p, p.clean(self.cx));

No crash in stable 1.62.1, crashes with nightly 2022-07-24 and 2022-08-03 : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label -E-needs-mcve
Was this at least on a project you can share the source to, or was it closed source? If it's a big project that you can't minimise, then it would be good to share/link to that, so someone else can do the minimisation. an example is better than no example, even if it's not minimal.
Managed to find something. The bound seems crucially important.
searched nightlies: from nightly-2022-01-01 to nightly-2022-08-02 regressed nightly: nightly-2022-06-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like


Question: if let mir::PlaceRef { base: &PlaceBase::Static(box Static { <del> kind: StaticKind::Promoted(promoted, _), </del> <ins> kind: StaticKind::Promoted(promoted, substs), </ins> ty, <del> def_id: _, </del> <ins> def_id, </ins> }), projection: &[], } = place.as_ref() { <del> let c = bx.tcx().const_eval_promoted(self.instance, promoted); </del> <ins> let c = bx.tcx().const_eval_promoted( Instance::new(def_id, self.monomorphize(&substs)), promoted, ); </ins> let (llval, ty) = self.simd_shuffle_indices( &bx, terminator.source_info.span,

It should use . ( is the second field of .) While both instances are normally equal, they can differ after running the mir inliner. In that case the promoted will refer to the inlined function. modify labels: +A-mir +C-bug +requires-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Can I give this a go? claim
Do you have any specific tests in mind I should add to check for the correct behaviour?
should be a test if the mir inliner would to inline . Somehow it doesn't though.
You might be running into this unfortunate check Try moving below .
Wow, that's hilarious. With just the changes suggested, the inlining still doesn't work properly, but doesn't seem to break any existing stuff. But I've just tried this and yeah, putting ret_slice below main has made the MIR inliner work.
This does inline, but somehow no assertion fires with current rustc. The printed MIR doesn't seem to show the the def_id from which the promoted originates, so I don't know what the problem is.
Unless I'm misunderstanding something, isn't this the correct behaviour? Both of those assertions are true, and swapping and around in the assertions correctly triggers an assertion failure.
I forgot that this problem was only with .
I got a working test:
Ah, that's a good test case. Yeah, that's definitely not the expected behaviour. While messing about with your example, I also managed to come across an ICE with this slightly shorter version: causes an ICE currently due to an internal index out of range. The good news is that the changes you suggested fixes both of these test cases. Good spot :) I'm putting up the PR now.


Question: use crate::errors::OpaqueHiddenTypeDiag; use crate::infer::{DefiningAnchor, InferCtxt, InferOk}; use crate::traits; <ins> use hir::def::DefKind; </ins> use hir::def_id::{DefId, LocalDefId}; use hir::{HirId, OpaqueTyOrigin}; use rustc_data_structures::sync::Lrc;

Here's a MVCE: I expected to see this happen: compilation fails because I'm clearly returning an instead of a Instead, this happened: bad codegen ("async fn resumed after completion") :
This is specifically a bug with default body in traits, this doesn't happen in s. I'll check it out, it's probably a very simple fix.


Question: <ins> struct RGB { g: f64, b: f64, } fn main() { let (r, alone_in_path, b): (f32, f32, f32) = (e.clone(), e.clone()); //~^ ERROR cannot find value `e` in this scope //~| ERROR cannot find value `e` in this scope //~| ERROR mismatched types let _ = RGB { r, g, b }; //~^ ERROR cannot find value `g` in this scope //~| ERROR struct `RGB` has no field named `r` //~| ERROR mismatched types } </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in
I think it's enough to change to be without .


Question: <ins> macro_rules! many_args { ([$($t:tt)*]#$($h:tt)*) => { many_args!{[$($t)*$($t)*]$($h)*} }; ([$($t:tt)*]) => { fn _f($($t: ()),*) {} //~ ERROR function can not have more than 65535 arguments } } many_args!{[_]########## ######} fn main() {} </ins>

Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low


Question: } item_mac(ref m) => { // FIXME #2888: we might actually want to do something here. <del> item_mac(copy *m) </del> <ins> // ... okay, we're doing something. It would probably be nicer // to add something to the ast_fold trait, but I'll defer // that work. item_mac(fold_mac_(m,fld)) </ins> } } }

See the case in .
Not critical for 0.6; de-milestoning
-- does it make sense for the AST fold to visit macros? Or is the current code correct?
From my perspective: yes, definitely. In particular, I'm going to want ident-folds to hit the idents inside of macro invocations. Could it break code to add this traversal? Well, the only place you're going to see unexpanded macro invocations is prior to expansion, and the only thing inside of macro invocations is tokens, so it seems very unlikely. To summarize: yes, this fold should visit macro invocations.
In that case, nominating for milestone 5, production-ready
accepted for production-ready milestone
I've implemented this in a local branch, I expect to push it soon (next two days)
done, now. FIXME removed downstream.


Question: <ins> error: internal compiler error error: internal compiler error encountered ... with incompatible types: left-hand side has type: <IntFactory as Factory<T>>::Item right-hand side has type: usize --> $DIR/select-param-env-instead-of-blanket.rs:42:5 | LL |     let mut x: <IntFactory as Factory<T>>::Item = bar::<T>(); |                                                   ---------- in this inlined function call ... LL |     0usize |     ^^^^^^ | = note: delayed at compiler/rustc_const_eval/src/transform/validate.rs:128:36 thread 'rustc' panicked </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --./src/test/ui/impl- or ./src/test/ui/impl-trait/issues/issue- <!-- 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</detailscc I believe this might be caused by
I'll look into it regardless
I was unable to reproduce same error perhaps it already fixed on stable channel try updating your rust compiler onto stable channel
the nightly that contains suspicious commit has not been released yet, there is no point in trying to reproduce this with nightly (or even stable). You'll need something that contains
This is the same issue that I identified in , but the bug identified and fixed in actually caused it to not be triggered until now. The issue here is a "trivial bound" () causing us to not select but in the MIR inliner. The caching bug actually caused the latter branch to happen everywhere, so when that bug was fixed, we started to normalize to in some places, causing this ICE. I bet I could trigger an ICE with a slight modification to this code using the inliner even with reverted. This is probably only triggered by the inliner, but the MIR inliner isn't enabled without being explicitly provided, right?


Question: <ins> error: internal compiler error error: internal compiler error encountered ... with incompatible types: left-hand side has type: <IntFactory as Factory<T>>::Item right-hand side has type: usize --> $DIR/select-param-env-instead-of-blanket.rs:42:5 | LL |     let mut x: <IntFactory as Factory<T>>::Item = bar::<T>(); |                                                   ---------- in this inlined function call ... LL |     0usize |     ^^^^^^ | = note: delayed at compiler/rustc_const_eval/src/transform/validate.rs:128:36 thread 'rustc' panicked </ins>

Trying to emulate trivial bounds via generics & associated types panics on stable, beta and nightly. <!-- 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. --: Reproducible on beta and nightly <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bug is not present in 1.51 and appears in 1.52. More precisely, it appeared somewhere between and .
Seems like introduces the regression Probably is the culprit
It seems to affect only traits that are checked by . Changing to fixes the panic.
I wonder if this could be fixed by normalizing the caller-bounds when checking for trivial bounds in WF. Hmm.... might think about this issue later tonight.
I'm putting up a PR soon to fix a whole bunch of impossible-bounds related things. So I'll claim this for the time being. claim


Question: } } #[stable(feature = "rust1", since = "1.0.0")] <del> impl Write for File { </del> <ins> impl Write for &File { </ins> fn write(&mut self, buf: &[u8]) -> io::Result<usize> { self.inner.write(buf) }

Some types ( and in particular) implement and on . If one of these types are wrapped in an (or ), there is no real reason why one shouldn't be able to call or methods on it. For example, this code should compile: I think this can be implemented pretty straightforwardly by adding the following impls to and : Are there good reasons for why impls like these shouldn't be ?
Closing because generic impls like proposed won't behave correctly, as described in .


Question: <ins> #![doc(html_logo_url = "https://raw.githubusercontent.com/sagebind/isahc/master/media/isahc.svg.png")] // Note: this test is paired with logo-class-default.rs. // @has logo_class/struct.SomeStruct.html '//*[@class="logo-container"]/img[@src="https://raw.githubusercontent.com/sagebind/isahc/master/media/isahc.svg.png"]' '' // @!has logo_class/struct.SomeStruct.html '//*[@class="logo-container"]/img[@class="rust-logo"]' '' // // @has logo_class/struct.SomeStruct.html '//*[@class="sub-logo-container"]/img[@src="https://raw.githubusercontent.com/sagebind/isahc/master/media/isahc.svg.png"]' '' // @!has logo_class/struct.SomeStruct.html '//*[@class="sub-logo-container"]/img[@class="rust-logo"]' '' pub struct SomeStruct; </ins>

In RustCrypto crates we use which changes style depending on preferred theme using CSS rules. You can see the for an example which uses it. But the problem is how the logo gets rendered on dark themes: ! ! The reason for such horrible result is the white shadow filter applied to the logo. I understand why it was , but I think it's a wrong approach, especially for projects which aim to properly support dark themes in their media files.
There was a mention back when this was implemented about how it is not possible for a media query approach to work, when I look at the sha2 docs it looks like ! because I use a light theme generally in my browser, but have rustdoc explicitly set to a dark theme. I'm confused why the outline is being applied to these docs though, was meant to only apply it to the default rust logo, and I don't see any relevant newer PRs when searching for .
I believe I broke this in In we are supposed to apply the class only when the logo is the default one. In I missed that distinction and now the always gets the rust-logo class, even when it's a custom logo. I'll fix.
By the way, to confirm what said: the media query embedded in the SVG isn't really right. That gets the browser's preferred light/dark mode, but the user may have overridden that in rustdoc settings. As a concrete example, I'm using Chrome on Linux, which doesn't have a light/dark mode setting. I can select a dark theme in rustdoc settings, which will get me this for the Rust Crypto logo (with applied): ! That's still an improvement over the status quo, and overall I think it's fine. But if we really wanted to support theme-sensitive logos perfectly, I think we'd need to offer separate configuration options for a light logo and a dark logo.
I believe that the media query approach is a correct one in principle. But I agree that, unfortunately, the current state of browsers is far from ideal, e.g. it would be nice to have a way to switch preferred mode for a page using CSS or JS. I'm using Chrome on Linux, which doesn't have a light/dark mode setting Well, it kind of has. Try launching it with (I don't have Chrome installed, but I think it should work similarly).


Question: <ins> warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/unifying-placeholders-in-query-response-2.rs:5:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --minimal project with full compiler output can be found here cargo 1.77.0-nightly ( 2024-01-09) : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details


Question: <del> // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. </del> <ins> // The Computer Language Benchmarks Game // http://benchmarksgame.alioth.debian.org/ </ins> // <del> // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. </del> <ins> // contributed by the Rust Project Developers // Copyright (c) 2012-2014 The Rust Project Developers // // All rights reserved. // // Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions // are met: // // - Redistributions of source code must retain the above copyright //   notice, this list of conditions and the following disclaimer. // // - Redistributions in binary form must reproduce the above copyright //   notice, this list of conditions and the following disclaimer in //   the documentation and/or other materials provided with the //   distribution. // // - Neither the name of "The Computer Language Benchmarks Game" nor //   the name of "The Computer Language Shootout Benchmarks" nor the //   names of its contributors may be used to endorse or promote //   products derived from this software without specific prior //   written permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES // (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR // SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, // STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) // ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED // OF THE POSSIBILITY OF SUCH DAMAGE. </ins> #![feature(phase)] #[phase(plugin)] extern crate green;

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


Question: } } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality // // This is otherwise the same as `eq_unspanned`, only recursing with a // different method. pub fn probably_equal_for_proc_macro(&self, other: &TokenTree) -> bool { match (self, other) { (&TokenTree::Token(_, ref tk), &TokenTree::Token(_, ref tk2)) => { tk.probably_equal_for_proc_macro(tk2) } (&TokenTree::Delimited(_, ref dl), &TokenTree::Delimited(_, ref dl2)) => { dl.delim == dl2.delim && dl.stream().probably_equal_for_proc_macro(&dl2.stream()) } (_, _) => false, } } </ins> /// Retrieve the TokenTree's span. pub fn span(&self) -> Span { match *self {

This is minimized from the dramatic forum thread . The following code is fine in nightly-2018-04-12 but breaks with nightly-2018-04-15. Oddly, lots of minor perturbations make it succeed. For example remove the two characters and it works. Or remove the single quote in the string and it works.
Alrighty-roo. As everything these days with hygiene, there's a couple of bugs here. With this one though I think only two! Everything has to do here with basically. AKA anything that runs through that falls off The usual reasons we think you fall off the "happy path" are due to things like inner attributes, , macro expansion, etc. None of that's present here! It should be the case that above can be losslessly converted to a based on what we've cached. Turns out though had a bug in it (surprise surprise!). There we're using to compare the resulting two token streams which eventually bottoms out in . As it turns out this isn't quite what we want! The implementation is structural, but the token stream we get when stringifying is slightly different than what we parsed. Here in the example you're using the literal string , but rustc stringifies this token as . Similarly if you replaced the string with something like it'll be stringified as . This means that the tokens are not literally byte-for-byte equal, which means we fall off the happy path! tl;dr the token stream of is not equivalent to the token stream . This causes us to fall off the happy path and used a stringified token stream. OK so in the case above we're falling off the happy path when we didn't expect to, but even still there's some weird bad hygiene behavior when we're not on the happy path. There's still something to fix! It turns out that there's also a regression due to (found via bisection). Before that PR this example would compile just fine, afterwards though it's hitting this error. can you help diagnose this and see what's going on? The reduced test case I have right now is: (note the inner attribute on to force using a non-cached token stream)
I've posted a fix for the "happy path" at will actually fix example above.


Question: } } <ins> // See comments in `interpolated_to_tokenstream` for why we care about // *probably* equal here rather than actual equality // // This is otherwise the same as `eq_unspanned`, only recursing with a // different method. pub fn probably_equal_for_proc_macro(&self, other: &TokenTree) -> bool { match (self, other) { (&TokenTree::Token(_, ref tk), &TokenTree::Token(_, ref tk2)) => { tk.probably_equal_for_proc_macro(tk2) } (&TokenTree::Delimited(_, ref dl), &TokenTree::Delimited(_, ref dl2)) => { dl.delim == dl2.delim && dl.stream().probably_equal_for_proc_macro(&dl2.stream()) } (_, _) => false, } } </ins> /// Retrieve the TokenTree's span. pub fn span(&self) -> Span { match *self {

That PR does not, however, fix the regression from which is still reproducible with the example I gisted.
Any idea why my repro case above is fixed if you remove the tokens? It seems like should fall off the happy path just as much.
If you remove the tokens we're still on the stringification path (aka not the happy path). For whatever reason though the hygiene bug goes away. That's likely caused from a subtelty introduced in (or at least so I'm hoping). I don't know much about , so I'm hoping will be able to look at this and know what's going on!
I don't know much about , so I'm hoping will be able to look at this and know what's going on! I'll investigate.
is the commit causing the regression. Further investigation is in progress.
An issue recently popped up on Rocket () that appears to be identical to this one and is not resolved in any recent nightly. It's possible that the root cause is , however.