Question: <ins> mod b { #[derive(Default)] pub struct A(u32); } impl b::A { fn inherent_bypass(&self) { let Self(x) = self; //~^ ERROR: tuple struct constructor `A` is private println!("{x}"); } } pub trait B { fn f(&self); } impl B for b::A { fn f(&self) { let Self(a) = self; //~^ ERROR: tuple struct constructor `A` is private println!("{}", a); } } pub trait Projector { type P; } impl Projector for () { type P = b::A; } pub trait Bypass2 { fn f2(&self); } impl Bypass2 for <() as Projector>::P { fn f2(&self) { let Self(a) = self; //~^ ERROR: tuple struct constructor `A` is private println!("{}", a); } } fn main() {} </ins>

I tried this code: I expected to see this happen: compilation should fail because the trait impl is defined outside of the module for the type but refers to its private field. Instead, this happened: this compiled successfully This reproduces on the playground for stable Rust, version 1.69.0:
Adding a main function and attempting to call the (playground link: ) raises the compilation error: !
This can be reproduced with cross-crate (e.i., any other crate can access the private field). This means that all encapsulations that take advantage of the field being private can be bypassed. (For example, if we change Vec to a tuple struct, the same thing as setlen could be done in safe code by abusing this bug.) label +I-unsound Also, this can be reproduced in all versions where is stable (e.i., 1.32+). It's a matter of how you initialize Foo. If you provide a constructor for Foo, you won't get a compile error:
Just for completeness, turning this into a segfault without external crates/just std:
label A-visibility
this has been unsound ever since in version 1.32
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: | -------------- variant or associated item `PIE` not found here ... LL |     ApplePie = Delicious::Apple as isize | Delicious::PIE as isize, <del> |                                                       ^^^ variant or associated item not found in `Delicious` </del> <ins> |                                                       ^^^ |                                                       | |                                                       variant or associated item not found in `Delicious` |                                                       help: there is a variant with a similar name: `Pie` </ins> error: aborting due to previous error

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


Question: <ins> // check-pass // compile-flags: --emit=mir,link // Regression test for #66930, this ICE requires `--emit=mir` flag. static UTF8_CHAR_WIDTH: [u8; 0] = []; pub fn utf8_char_width(b: u8) -> usize { UTF8_CHAR_WIDTH[b as usize] as usize } fn main() {} </ins>

This is while debug printing all mir statements of libcore.
modify labels: +A-mir +C-bug +requires-nightly
This also reproduces on .
The incorrectly assumes at several places that the allocation kind is always what the type should contain. It for example assumes that an value always points to a function, and always points to raw bytes. It also ignores relocations at several places.
Triage: I think this ICE is fixed by , no longer occurs with the latest nightly. Marking as E-needs-test.


Question: <ins> // check-pass // compile-flags: --emit=mir,link // Regression test for #66930, this ICE requires `--emit=mir` flag. static UTF8_CHAR_WIDTH: [u8; 0] = []; pub fn utf8_char_width(b: u8) -> usize { UTF8_CHAR_WIDTH[b as usize] as usize } fn main() {} </ins>

Minimal reproducer: Make sure to run rustc with to reproduce! Using doesn't fix this.
Minimal repro:
Other failure with code causing the above problem: This one is observable by printing the whole mir using , unlike the other, which requires you to debug print every statement.
cc
That second one is a miri assertion: Interestingly, there's an afterwards that would be more helpful if it were before: cc
It seems like no longer ICE with latest nightly, I guess fixed this (CC: Marked as E-needstest
points out hasn't been fixed yet, dropping E-needstest.
Is the issue description still accurate? "Can't debug format a mir stmt in DefId" reminds me of a after we had some ICE issues with debug-printing DefIds. But as far as I can see, no example mentioned here even triggers an ICE with that message. The ICEs described here sound very different than that, they look like CTFE is not handling ZSTs properly somewhere.
I cannot on beta or nightly, so it looks pretty fixed to me. can you still reproduce this issue with latest nightly? The first backtrace has no code, so it is impossible to debug; the second backtrace (the one with self-contained code) does not seem to ICE any more.
Uhm? I don't think so, did you run with ?
Ah, I just ran on playground. It would be good to have up-to-date reproduction instructions in the first post, and not just in the third post below a huge stacktrace.
Yeah, but I don't have write access :/
Ouch, sorry. :( I didn't know. I will update the OP.
<details<summaryHere's a backtrace with debug info</summary</details Looks like the is wrong.
Triage: I think that ICE is fixed by , no longer occurs with the latest nightly. Marking as E-needs-test.


Question: [[package]] name = "racer" <del> version = "2.1.46" </del> <ins> version = "2.1.47" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "e7cbda48a9124ed2e83766d2c15e3725710d344abca35fad8cf52341a55883b1" </del> <ins> checksum = "513c70e67444a0d62fdc581dffa521c6820942a5f08300d0864863f8d0e750e3" </ins> dependencies = [ "bitflags", "clap",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Sure, I can look at this one.
Thanks for merging ! If I'm reading things right, I think I need a new crater release of it so I can update ? If so, can you please make one of those?


Question: } } <ins> #[derive(Debug)] pub struct OffsetOverflowError; </ins> /// A single source in the `SourceMap`. #[derive(Clone)] pub struct SourceFile {

I know that having huge literal in source is a bad idea, but it should not cause ICE :( It looks like something overflowed. Version: Command, output and backtrace: Here is the generator of the source:
cc
Took a quick look. We certainly have a restriction that any file can't be that large, because we use u32 for indexing. And looks like we never try to enforce it anywhere. I think the place to do that would be . Do we have any way to panic without this being marked as ICE? I don't want to thread to each , and this seems like a marginal error where it's totally OK to panic. This is even OK in the IDE context I think: IDE should enforce reasonable max size of the file (something like 10mb, not 4gb) at the virtual file system layer. The "just panic" fix is here:
Do we have any way to panic without this being marked as ICE? or if the context is available.
I tried to compile the same thing in gcc and clang: With gcc: With clang: EDIT: Opened


Question: let buildpath = fs::connect(_path, "/build"); need_dir(buildpath); #debug("Installing: %s -> %s", cf, buildpath); <del> let p = run::program_output("rustc", ["--out-dir", buildpath, cf]); </del> <ins> let p = run::program_output(rustc_sysroot(), ["--out-dir", buildpath, cf]); </ins> if p.status != 0 { error(#fmt["rustc failed: %dn%sn%s", p.status, p.err, p.out]); ret;

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


Question: let buildpath = fs::connect(_path, "/build"); need_dir(buildpath); #debug("Installing: %s -> %s", cf, buildpath); <del> let p = run::program_output("rustc", ["--out-dir", buildpath, cf]); </del> <ins> let p = run::program_output(rustc_sysroot(), ["--out-dir", buildpath, cf]); </ins> if p.status != 0 { error(#fmt["rustc failed: %dn%sn%s", p.status, p.err, p.out]); ret;

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


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Regression test for issue #25436: check that things which can be // followed by any token also permit X* to come afterwards. macro_rules! foo { ( $a:tt $($b:tt)* ) => { }; ( $a:ident $($b:tt)* ) => { }; ( $a:item $($b:tt)* ) => { }; ( $a:block $($b:tt)* ) => { }; ( $a:meta $($b:tt)* ) => { } } fn main() { } </ins>

In an example like we report the following error: This is part of the macro future-proofing code but it is an unnecessary limitation. For fragments that represent at most one token tree (, , , possibly others) there is no concern at all about being following by sequence repetition. This turns out to be a really big limitation in practice, since making macros that work over a generic sequence of token trees effectively allows for arbitrary parsing. cc
triage: P-medium
I'd be happy to mentor this, if I don't fix it first.
triage: P-medium
cc
I-ICE?
Curious why this was closed, looks like it's blocking lispy-rust.
It was fixed by ; do you still see this issue present in nightly?


Question: So, no need to manually enter those Unicode characters! <ins> ### Adding a warning block If you want to make a warning or similar note stand out in the documentation, you can wrap it like this: ```md /// documentation /// /// <div class="warning">A big warning!</div> /// /// more documentation ``` </ins> [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

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


Question: So, no need to manually enter those Unicode characters! <ins> ### Adding a warning block If you want to make a warning or similar note stand out in the documentation, you can wrap it like this: ```md /// documentation /// /// <div class="warning">A big warning!</div> /// /// more documentation ``` </ins> [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

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


Question: So, no need to manually enter those Unicode characters! <ins> ### Adding a warning block If you want to make a warning or similar note stand out in the documentation, you can wrap it like this: ```md /// documentation /// /// <div class="warning">A big warning!</div> /// /// more documentation ``` </ins> [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

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


Question: So, no need to manually enter those Unicode characters! <ins> ### Adding a warning block If you want to make a warning or similar note stand out in the documentation, you can wrap it like this: ```md /// documentation /// /// <div class="warning">A big warning!</div> /// /// more documentation ``` </ins> [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

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


Question: So, no need to manually enter those Unicode characters! <ins> ### Adding a warning block If you want to make a warning or similar note stand out in the documentation, you can wrap it like this: ```md /// documentation /// /// <div class="warning">A big warning!</div> /// /// more documentation ``` </ins> [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

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


Question: So, no need to manually enter those Unicode characters! <ins> ### Adding a warning block If you want to make a warning or similar note stand out in the documentation, you can wrap it like this: ```md /// documentation /// /// <div class="warning">A big warning!</div> /// /// more documentation ``` </ins> [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

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


Question: So, no need to manually enter those Unicode characters! <ins> ### Adding a warning block If you want to make a warning or similar note stand out in the documentation, you can wrap it like this: ```md /// documentation /// /// <div class="warning">A big warning!</div> /// /// more documentation ``` </ins> [`backtrace`]: https://docs.rs/backtrace/0.3.50/backtrace/ [commonmark markdown specification]: https://commonmark.org/ [commonmark quick reference]: https://commonmark.org/help/

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


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

The following code fails on stable: When compiled in release mode, the assert is optimized out by LLVM even though it checks the exact same condition as the other assert, as can be verified by testing in debug mode. Note that it's theoretically possible for the stack to be aligned correctly such that the bug is suppressed, but that's not likely. The 256's can be replaced with larger alignments if that happens. The bug is caused by the impl of copying to the stack with the default alignment of 16. ()
and seem related
This is a soundness hole.
So... I guess the problem is that the that rustc emits for the unsized local doesn't use ? That's... kind of bad, because it doesn't look like even supports dynamically setting the alignment: If this is correct, the issue should be renamed to something like "unsized locals do not respect alignment".
A way to fix this would be to change the ABI for dynamic trait calls that take by value to always pass by address. When the trait object is created is where the trampoline function would be generated, so there is no additional cost for static calls.
This can also be fixed by not allowing dynamically-sized local variables with an alignment more than some maximum value and having all dynamically-sized locals use that maximum alignment unless optimizations can prove that a smaller alignment suffices.
Messing with the ABI wouldn't help with unsized locals in general (assuming is correct), since e.g. will also need an alloca with dynamic alignment in general. Given only a value, there is no static way to say anything about its alignment, so how would you distinguish whether calling a method on it is OK?
Can we call and then align the pointer for the local ourselves as a workaround until we come up with a good solution?
In clang there's a function which might or might not be useful in this case.
requires a constant alignment. Non constant alignments are . This matches semantics of LLVM instruction, so it's not helping, as alignment of value in is unknown at compile time when moving from .
I think that overallocating for unsized locals of unknown alignment may make sense. You can and then make use of to compute the offset. Sure, it increases stack requirements, but it seems acceptable for , and in most cases you end up with extra 7 bytes on stack or less. 256 alignment seems like an edge case where wasting 255 bytes doesn't matter.


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

if we keep setting as the default alignment we can skip the overallocating and offset dance for types with an alignment below that.
My idea was that rustc would prohibit coercing overaligned types to a dyn trait that takes by value. So:
The alignment is dynamically determined though, not sure if saving 15 bytes of stack space is worth the conditional branch?
Oh right. Yea that's probably not helpful.
Since , this would be backwards incompatible (at latest) once trait object upcasting is finally implemented: and trait objects would have to have the same alignment restriction (because you can upcast to ), but today you can freely create such objects with any alignment.
I was under the impression that calling didn't require dynamic , is that related to missing MIR optimizations, meaning we have unnecessary moves which end up duplicating the data on the stack using a dynamic ?
Correctness shouldn't rely on optimizations to fire...
Sure, I was just hoping we weren't relying on "unsized locals", only unsized parameters (i.e. ), for what we're exposing as stable. And I was hoping an optimization wouldn't need to be involved to get there. I wonder if it would even be possible to restrict "unsized locals" to the subset where we can handle it entirely through ABI, and not actually have dynamic s anywhere, since that would make me far more comfortable with 's implementation or even stabilization. Ironically, if that works, it's also the subset we could've implemented years earlier than we did, since most of the complexity, unknowns (and apparently bugs) are around dynamic s, not calling trait object methods on a dereference of .
That should be possible. I think everything that is necessary is performing the deref of the box as argument () instead of moving the box contents to a local first () That would also make it possible to call in cg_clif. Cranelift doesn't have alloca support, so the current MIR is untranslatable.
Hmm, but that's not trivially sound because it could lead to MIR calls where argument and return places overlap, which is UB. We'd potentially have to special-case it to derefs, but even then what's to stop someone from doing ? Maybe we could introduce a temporary for the return value instead, for these kinds of virtual calls? That should remove any potential overlap while allowing the call.


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

(Unrelatedly, I just realize we use a copying-out shim for vtable entries that take by value, even when would be passed as at the call ABI level. We would probably have to make computing the call ABI a query for this microopt to not be expensive)
That would result in being moved to a temp first before dropping and calling the boxed closure. If it wasn't moved first before the drop of , then borrowck would give an error. (I meant for this change to be done at mir construction level, not as an optimization pass, so borrowck should catch any soundness issues)
We can try it, I guess, but right now a lot relies on many redundant copies/moves being created by MIR building and may not catch edge cases like this. But also I don't think moving out of a moves the itself today. Me too, but I was going with the "correct by construction" approach of creating a redundant copy/move, just on the return side, instead of the argument side, of the call.
After revisiting on triage, removing nomination.
pre-triage: nominated for discussion in the next weekly meeting.
I just checked and, a function call roughly this (touched up for clarity): Some of my previous comments assumed the wasn't there and the call would use the destination directly, but given that there is a move, that simplifies my suggestion. <hr/For virtual by-value calls, we can skip one move when building the MIR, specifically the move out of the dereference of a for the argument. Given that we already move the result of the call, there should be no aliasing caused by this, but if we decide to change anything about how we build MIR calls, we'd need to be extra careful. We can also make this pattern be gated by a separate feature-gate (rather than ), and make sure the standard library only uses that feature-gate and not . This should solve any alignment issues might have, because we'd not be using dynamic unless the broader feature is used.
OK, if I understand what's being proposed here, it is to excerpt a subset of the "original unsized-locals plan" -- specifically, to permit locals with unsized types, but only in contexts where we can be guaranteed that we can point to the original storage and don't actually have to move any value (and hence we don't require variable size stack frames).


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

I'm in favor of this proposal, but I do think we want to be slightly careful to ensure we're not violating soundness. The main concern would be if there is some way to access or re-use the variable that was moved. I attempted to do so with this example () but it fails to compile: The error here arises because the closure would need to capture a to do anything, which prevents a later move. But maybe there is some kind of tricky example that can arise where we re-assign the value during argument evaluation?
compiles and does before , where is the result of .
Borrowck should prevent that, right?
borrowck may rely on MIR building creating extraneous copies, so we can't just assume it helps us. IMO we should limit it to functions taking unsized parameters and function calls passing such parameters or dereferences of es (any other pointer/reference doesn't support moving out of).
Well, I think is right that borrowck would catch violations of soundness in some strict sense, but I guess what I meant is that we might be breaking backwards compatibility.
The example that feels pretty relevant. If I understood your proposal, it would no longer compile. If I recall (thinking back), I had a plan to handle this by save the to an alternate location in the actual call, we pass ownership of and then do a shallow free of the This still seems like it would work, though I'm not sure how easy/elegant it is to formulate. In a sense we'd be rewriting to .
Isn't example dependent on doing a direct virtual call? My understanding is that you can't do this on stable with because the virtual call exists in one place, in libstd, and it doesn't do anything weird, so it would work with a restricted ruleset. EDIT: if it can work on stable, it's because calling 's will move the whole before the assignment is evaluated, which is fine, because the shallow drop is actually inside that , not its caller.
I agree that this code doesn't compile on stable today, but I'm not sure if that's the point. I guess you're saying it's ok for it to stop compiling? I think what I would like is that our overall behavior is as consistent as possible between Sized and Unsized parameters. I think we could actually do a more general change that doesn't special case Sized vs Unsized or anything else.


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

I think I am basically proposing the same thing as earlier, but with a twist: Today, when building the parameters, we introduce a temporary for each parameter. So if we had we might do: What I am saying is that we could say: If the argument is moved (not copied), and the "place" has outer derefs (e.g., we are passing where is some place), then we assign the place to a temporary and we make the argument to the function be : I don't believe this is observable to end-users, except potentially for when the destructor on runs. I believe that it accepts all the same code we used to accept. It also has nothing specific to or types at all. Does that make sense? I'm very curious to know if anyone sees any problems with it. (One obvious thing: if we ever add , its design would have to accommodate this requirement, but I think that's fine, in fact the complications around getting moves right for precisely this case are one of the reasons we've held off on thus far.)
Can you not reinitialize today? If you move the whole , it is indeed more conservative (and should let us skip unnecessary moves even in cases). But also, do you want to move the locals check from typeck to borrowck? I don't have an intuition for when your approach wouldn't create unsized MIR locals, from the perspective of typeck. However, this is only relevant if we want a stricter feature-gate. At the very least it seems like it would be easier to implement a change only to MIR building, and it should fix problems with for the time being, even without a separate feature-gate.
Hmm, that's a good point, I think do that. Sigh. I knew that seemed too easy. I remember we used to try and prevent that, but we never did it fully, and in the move to NLL we loosened those rules back up, so this compiles: Still, you could do my proposal for unsized types, though it would introduce an incongruity. UPDATE: Oh, wait, I remember now. For unsized types, reinitialization is not possible, because you can't do with an unsized rvalue (we wouldn't know how many bytes to move). So in fact there isn't really the same incongruity.


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

To be clear, I wasn't proposing changing anything apart from MIR building either, I don't think. IIUC, what you proposed is that would be compiled to: whereas under my proposal (limited to apply to unsized parameters, instead of moved parameters) would yield: I think I mis-stated the problem earlier. It's not so much that your proposal will introduce compilation errors, it's that I think it changes the semantics of code like this in what I see as a surprising way: I believe that this code would compile to the following under your proposal: which means that would be invoked with the new value of , right? Under my proposal, the code would still compile, but it would behave in what I see as the expected fashion. Specifically, it would generate:
Isn't there a way to "lock" that value through the borrow-checker, so further accesses would be disallowed, until the call returns? I'd rather be stricter here. <hr/My point was that if your proposal affects sized moves, you're breaking stable reinitialization. If it doesn't affect sized moves, I don't see how this applies anymore:
Let me just chime in here and say that this is a pain in Miri. Unsized locals are pretty different from sized locals, I had to introduce a bunch of special hacks to make them work. MIR locals even needed a new state just for them: Lazily allocating locals seems odd to me, but at least we can consistently do that for all locals. Elsewhere however to make this lazy initialization actually work out and catch mistakes where an unsized local is "overwritten" with a value of different size: This all feels really unprincipled, and it would be great if at some point we could come up with a coherent semantics for unsized locals in MIR. The worst part is that the size of a local is implicitly determined on the first write to it. It would be much better to be explicit about that, e.g. at time.
I don't think we have anything like this today, but presumably we could add such a thing, but I'm not quite sure what you have in mind. When does this prohibition on further accesses take effect?


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

In particular, the IR for under your proposal, if I understood, would be But the access to that (I believe) we wish to prevent takes place in the "evaluate remaining arguments" part of things. So I think we'd have to add some sort of "pseudo-move" that tells borrowck that should not be assignable from that point forward, right? Well, it depends on your perspective. It's true that, given the need to permit reinitialization, the check is now specific to unsized values -- i.e., MIR construction will be different depending on whether we know the type to be sized or not. That's unfortunate. However, I think we still maintain a degree of congruence, from an end-user perspective. In particular, users could not have reinitialized a anyhow. However, under my proposal, users can write things like and the code works as expected (versus either having an unexpected result or getting an error). In any case, it seems like we're sort of "narrowing in" on a proposal here: when we see a function call with a parameter that is , and the value being passed is a deref, we want to modify the IR to not introduce a temporary and instead pass that parameter directly from its location, either we do some sort of "no more assignments" lock, or we move the pointer and introduce a temporary (and then pass in a deref of that temporary) Does that sound right so far?
If it's easier to do the more flexible approach (by moving the pointer) than the "locking" approach (which is a bit like borrowing the pointer until all arguments are evaluated, then releasing the borrow and doing a move instead), I don't mind it, I was only arguing with the "uniformity" aspect. Something important here: your approach is stabilizable, while mine is meant more for that one in the standard library, and not much else.
Yes, I was kind of shooting for something that we could conceivably stabilize.
Removing nomination, this was already discussed in triage meeting and it's under control.
So should we maybe try out the approach I proposed and see how well it works?
yes, going to try that out.
For the record, the "new plan" is this.


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

When generating the arguments to a call, we ordinarily will make a temporary containing the value of each argument: But we will modify this such that, for arguments that meet the following conditions: The argument is moved (not copied), and its type is not known to be , and the "place" has outer derefs (e.g., we are passing P where P is some place), then we assign the place P (instead of ) to a temporary and we make the argument to the function be (instead of ). This means that given where , we used to generate but now we generate We are now moving the box itself, which is slightly different than the semantics for values known to be sized. In particular, it does not permit of the box after having moved its contents. But that is not supported for unsized types anyway. The change does permit modifications to the callee during argument evaluation and they will work in an analogous way to how they would work with sized values. So given something like: we will find that we (a) save the old value of to a temporary and then (b) overwrite while evaluating the arguments and then (c) invoke the with the old value of .
Update: There is also
is a perfectly normal operand, I don't know what you mean. It's the same kind of as we currently have in (on the RHS)
Oh sorry, somehow I thought operands could only refer directly to locals, not also dereference them. I think I am beginning to see the pieces here -- together with function argument handling, this entirely avoids having to dynamically determine the size of a local. I have to agree that is quite elegant, even though baking "pass-by-reference" into MIR semantics still seems like a heavy hammer to me. On the other hand this places a severe restriction on now unsized locals may be used, basically taking back large parts of Is there some long-term plan to bring that back (probably requires with dynamic alignment in LLVM)? Or should we amend the RFC or at least the tracking issue with the extra restrictions?
I would keep the more general feature but use two different feature-gates (if we can). And just like with a few other feature-gates () we could warn that (the general one) is incomplete and could lead to misaligned variables (or something along those lines).


Question: error[E0382]: borrow of moved value: `x` --> $DIR/borrow-after-move.rs:39:24 | <ins> LL |         let x = "hello".to_owned().into_boxed_str(); |             - move occurs because `x` has type `std::boxed::Box<str>`, which does not implement the `Copy` trait </ins> LL |         x.foo(); |         - value moved here LL |         println!("{}", &x); <del> |                        ^^ value borrowed here after partial move | = note: move occurs because `*x` has type `str`, which does not implement the `Copy` trait </del> <ins> |                        ^^ value borrowed here after move </ins> error: aborting due to 5 previous errors

We could also add runtime asserts that the (dynamic) alignment is respected, once we know could never trigger them (e.g. from stable code).
I was wondering about that too. It seems like it'd be good to review the more general feature in any case. This is partly why I brought up the idea of wanting a guaranteed "no alloca" path -- this was something I remember us discussing long ago, and so in some sense I feel like the work we're doing here isn't just working around LLVM's lack of dynamic alignment support (though it is doing that, too) but also working to complete the feature as originally envisioned.
I two notes to the tracking issue so we don't overlook this in the future.
This is probably expected, but the fix failed to actually make sound:


Question: <ins> #![feature(fn_delegation)] #![allow(incomplete_features)] mod to_reuse {} trait Trait { reuse to_reuse::foo { foo } //~^ ERROR cannot find function `foo` in module `to_reuse` //~| ERROR cannot find value `foo` in this scope } fn main() {} </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
this probably crashes since but I haven't verified that yet
smaller
even smaller


Question: tt @ &TtSequence(..) => { check_matcher(cx, Some(tt).into_iter(), &Eof); }, <del> _ => cx.span_bug(sp, "wrong-structured lhs for follow check (didn't find  a TtDelimited or TtSequence)") </del> <ins> _ => cx.span_err(sp, "Invalid macro matcher; matchers must be contained  in balanced delimiters or a repetition indicator") </ins> }, _ => cx.span_bug(sp, "wrong-structured lhs for follow check (didn't find a  MatchedNonterminal)")

A simple malformed macro makes the compiler crash. Code: Playpen error: Playpen:
Another case: Playpen:
I had a crash in a bad macro which hits the same bug as Note that his/her error has the following which is a different stack trace: I'm on the latest beta; not nightly.
I think you and I are getting a different panic from this bug. I've opened since the panic is in a different location in the code.


Question: <ins> // Regression test for #92111. // // The issue was that we normalize trait bounds before caching // results of selection. Checking that `impl NoDrop for S` requires // checking `S: !Drop` because it cannot overlap with the blanket // impl. Then we save the (unsatisfied) result from checking `S: Drop`. // Then the call to `a` checks whether `S: ~const Drop` but we normalize // it to `S: Drop` which the cache claims to be unsatisfied. // // check-pass #![feature(const_trait_impl)] #![feature(const_fn_trait_bound)] pub trait Tr {} #[allow(drop_bounds)] impl<T: Drop> Tr for T {} #[derive(Debug)] pub struct S(i32); impl Tr for S {} const fn a<T: ~const Drop>(t: T) {} fn main() { a(S(0)); } </ins>

<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: print (from Debug impl) Instead, this happened: E0277, trait impl not found This was found by CI in the Ruffle Project: The issue is caused by the effective anti-bound of Drop, introduced by the manual impl of the trait, as well as the PR which introduced bounds for a number of functions in . It most recently worked on: rustc 1.59.0-nightly ( 2021-12-18) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! items { () => { type A = (); fn a() {} } } trait Foo { type A; fn a(); } impl Foo for () { items!(); } fn main() { } </ins>

Mm, we have "method macros" but now there are other things that can go in a trait.
Seems to be fixed by , but I don't see tests for it specifically, so I guess this needs tests.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! items { () => { type A = (); fn a() {} } } trait Foo { type A; fn a(); } impl Foo for () { items!(); } fn main() { } </ins>

Rust Version: rustc 1.0.0-nightly ( 2015-02-12 00:38:24 +0000) Description: When compiling the following code with rustc the output is: ERROR:rbml::reader: failed to find block with tag 7 error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'explicit panic', C:botslavenightly-dist-rustc-win-64buildsrclibrbml stack backtrace: 1: 0x69bfbbeb - sys::backtrace::write::h57b621d79849130fitB 2: 0x69c13974 - rt::unwind::register::h686925f8fa692ab9GSJ 3: 0x69b836ef - rt::unwind::beginunwindinner::hc2a974b1bdaa4639YPJ 4: 0x302da8 - reader::maybegetdoc::h2547f886a15a227erHa 5: 0x301d2f - reader::getdoc::hc198b8918d0de179nLa 6: 0x1138635 - metadata::decoder::itemtype::h7f6e008c4a79af18mck 7: 0x11480d9 - metadata::decoder::gettype::h9620389d7a7d23c0Xok 8: 0x10fb7a8 - metadata::csearch::gettype::h3af5a6a2534b2d8bCkn 9: 0x6d605059 - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 10: 0x6d5f49ab - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 11: 0x6d5f64ef - rscope::ShiftedRscope<'r.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! items { () => { type A = (); fn a() {} } } trait Foo { type A; fn a(); } impl Foo for () { items!(); } fn main() { } </ins>

RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 12: 0x6d5978bd - astconv::asttytoty::h1dadfccc9ddb5e90VHv 13: 0x6d5ef523 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 14: 0x6d5fa734 - rscope::ShiftedRscope<'r.RegionScope::anonregions::h0a5ed4a2d46d3aeeqlu 15: 0x6d61330f - collect::CollectCtxt<'a, 'tcx.AstConv<'tcx::tcx::hf449f596d422460aAFw 16: 0x6d60a79a - collect::CollectCtxt<'a, 'tcx.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! items { () => { type A = (); fn a() {} } } trait Foo { type A; fn a(); } impl Foo for () { items!(); } fn main() { } </ins>

AstConv<'tcx::getitemtypescheme::he174d5be00f2627cMFw 17: 0x6d643867 - checkcrate::h72731a5b4298723fkrB 18: 0x6d64131c - checkcrate::h72731a5b4298723fkrB 19: 0x70b1eb58 - driver::phase3runanalysispasses::hc863f28a1bd50b11SGa 20: 0x70b02618 - driver::compileinput::hd580d8c011d24ba3Eba 21: 0x70bcfc4c - runcompiler::hb48a33a057cced0e5bc 22: 0x70bcd85b - run::h3df2025cf41d43b3Ibc 23: 0x70bcc56a - run::h3df2025cf41d43b3Ibc 24: 0x69c4180c - rusttry 25: 0x69c417e9 - rusttry 26: 0x70bccbdc - run::h3df2025cf41d43b3Ibc 27: 0x69c03ae2 - sys::tcp::TcpListener::bind::h2319ec78a0f49dc2faF 28: 0x770f59ed - BaseThreadInitThunk
Same error as .


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! items { () => { type A = (); fn a() {} } } trait Foo { type A; fn a(); } impl Foo for () { items!(); } fn main() { } </ins>

I got this while trying to implement something similar to a FromStr trait and tried to rely on a lot of inferencing when calling it. I can try to extract a standalone example if needed.
This ICE is also producible by trying to refer to an associated type that's never defined. is accepted by the compiler when it clearly should not be - what on earth is ? The following and code cases the same ICE. Here's the stack trace:


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! items { () => { type A = (); fn a() {} } } trait Foo { type A; fn a(); } impl Foo for () { items!(); } fn main() { } </ins>

I get the ICE below when I compile this fragment of code: The above structs are defined here: The above fragment is part of That crate depends on And that crate requires erlang-17.4 to be installed.
A minimal program to demonstrate the crash is...


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! items { () => { type A = (); fn a() {} } } trait Foo { type A; fn a(); } impl Foo for () { items!(); } fn main() { } </ins>

compile with opt-level = 2 (works fine with opt-level=0)
strange. the program looks legit to me.
this works for me now, as of
This prints on all opt levels for me at .


Question: <ins> struct Foo(i32); fn main() { let Foo(...) = Foo(0); //~ ERROR unexpected `...` let [_, ..., _] = [0, 1]; //~ ERROR unexpected `...` let _recovery_witness: () = 0; //~ ERROR mismatched types } </ins>

` The problem here is that we have instead of The compiler however points towards in the error message instead of the superfluous : Fun fact: when using four dots , it correctly points at the last dot :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems like a simple issue to fix. If I were to take a shot at fixing this, where would I start?
Mentoring instructions: Add a branch after this one... instead of , check that . This should be interpreted as a as in the previous branch, but an error should also be emitted. (Add the code for error emission in a separate method, with an appropriate , where the span of the is replaced with . See for an example on emitting an error with a suggestion.)
Sure thing! Will get to it right after work. Thanks for the pointers.
assign


Question: <ins> mod list { pub use self::List::Cons; pub enum List<T> { Cons(T, Box<List<T>>), } } mod alias { use crate::list::List; pub type Foo = List<String>; } fn foo(l: crate::alias::Foo) { match l { Cons(..) => {} //~ ERROR: cannot find tuple struct or tuple variant `Cons` in this scope } } fn main() {} </ins>

Bisected to a rollup, but I think it's very likely to be . cc searched nightlies: from nightly-2021-10-01 to nightly-2021-10-19 regressed nightly: nightly-2021-10-02 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 old suggestion was actually incorrect because it suggested , which is a private import. However, the new error is "more incorrect" IMO since it says something confusing (and incorrect).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: <ins> Couldn't create directory for doctest executables: Permission denied (os error 13) </ins>

When setting the directory to persist doctests to if an UNC path is used on windows there's a segfault. The offending setting of persist-doctests: . cargo-tarpaulin sets this programatically using a path it gets for the target directory from cargo-metadata. The path from cargo-metadata is an UNC path and this then causes a segfault. I'm going to detect UNC paths in my code and remove the on windows, but I felt this warrants a bug report as someone else will hit it eventually. Also, I'm not sure if other parts of the compiler fall prey to this issue? Compiler version is: the latest nightly (1.64.0-nightly 2022-06-28) The stack trace: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This panic is also triggered in Linux if e.g. trying to write into a directory that the user has no permission to write. I PR'd fix to change the unwrap to more orderly panic and relaying the underlying error detail via eprintln! ~/gg/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc --test -Z unstable-options --persist-doctests /tmp/foobar Couldn't create directory for doctest executables: Permission denied (os error 13) instead of:
The lack of ICE is definitely nicer, but this still won't handle UNC paths on windows will it? Which is the main issue I personally have with the code
That's a problem for std::fs::createdirall(&path) me thinks has to be fixed there
Makes sense looking at the code, should I raise another issue for the libs team?
Actually, yes it would be great to raise another issue targeting std::fs::createdirall - as it is wider issue. you are right. Thanks!
So isn't this an issue with the tool generating an incorrect argument?
So the paths are weirding me out (I normally only use linux), because they seem to sometimes print differently given different display methods. It shows up as printing the path in my rust code before making the env var, and if I print the rustdocflags I'm setting it's correct.


Question: <ins> Couldn't create directory for doctest executables: Permission denied (os error 13) </ins>

But if I do it returns false, I have to do for it to return true. I'll raise the other issue and after work look into it more properly try to make a better MRE for windows
do you mind changing title s/UNC/invalid/ to address the panic on this issue, thanks! :)
also please remove s/on windows// thanks a lot :+1:
Done, and I realised what was wrong with the path, it's correct in the code, it's just when it got set into the environment variable it seems it needed the first slash to be escaped and that caused the invalid path (so no issues in std::fs need fixing)
claim label +I-ICE +T-RUSTDOC


Question: fn main() { let x = box 3; //~^ ERROR box expression syntax is experimental; you can call `Box::new` instead. <del> //~| HELP add #![feature(box_syntax)] to the crate attributes to enable </del> }

Steps to reproduce: The output of is: does as suggested by the message, but that fails too (as expected): Proposed fix: in the beta and stable channels (i.e. whenever is forbidden), the message that suggests adding should not be shown. (Clean up the test case with .) CC
Gonna milestone this real quick, as it seems quite important.
I might be able to whip up a quick fix, though I'm not 100% sure about testing it properly ... (I've never actually tried building something for a non-dev release channel before...)
after chatting with it seems like I have a patch, building it now
gonna leave to it
Hello good Rust folks :smile: Before the beta, I used which is in . Is there any way to use this trait during the beta ? I'm not sure how I can get the code to compile. Thanks for any tip / hints you can offer :+1:
Hi Commenting on random unrelated issues is usually not the right thing to do. You should rather open a new issue, or ask on . But to answer your question anyway, that trait only has : … and is stable and can be used on beta. So I’d recommend you copy/paste the trait into your code, or make a function.
Thanks for taking the time to answer. I appreciate it. I don't see how this is unrelated. This is related, since the code I'm talking about used to compile with and the compiler suggests to do that, during the beta period. Thanks for your tip on copying the function :+1: I guess I'll just do that if nothing better is available and change this again when the trait is stable.
This specific issue is about fixing one of the compiler’s error message, not about fixing code that triggers that error. It really helps everyone to keep discussions on topic.
Alright. I understand. I'll make sure to open a new issue or go on StackOverflow next time if appropriate. Thanks again :+1:
This doesn't seem to be properly fixed in the beta channel. I'm still being recommended to add in the errors, and then told it's not available in the beta channel. Rust version: The code I used (snappy example in the docs with the extra addition on the first line:
This happened after Beta release.


Question: fn main() { let x = box 3; //~^ ERROR box expression syntax is experimental; you can call `Box::new` instead. <del> //~| HELP add #![feature(box_syntax)] to the crate attributes to enable </del> }

We'll see the effect of this patch in 1.0 and afterwards Beta, etc.
Whoops, I thought this made it in before beta. Thanks!
are there plans to release updates to the beta channel within a given 6 weeks cycle? Either this one or in the future.
I'm certain there will be updates; see discussion from last night here:
So how does one fix this error? I'm a new user of the rust library and I can't seem to use the collections library during the beta due to this problem. Given this git issue is a top google result, it would be nice if there were a solution here. Edit: Looks like the solution is to switch to the rust nightly. Is the entire collections library off-limits in the beta?
by design, you have access to the parts of that are re-exported from (and are stable).


Question: <ins> // compile-flags: -Ztrait-solver=next-coherence // Makes sure we don't ICE on associated const projection when the feature gate // is not enabled, since we should avoid encountering ICEs on stable if possible. trait Bar { const ASSOC: usize; } impl Bar for () { const ASSOC: usize = 1; } trait Foo {} impl Foo for () {} impl<T> Foo for T where T: Bar<ASSOC = 0> {} //~^ ERROR associated const equality is incomplete //~| ERROR conflicting implementations of trait `Foo` for type `()` fn main() {} </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


Question: let scope = if self.monotonic { invoc.expansion_data.mark } else { orig_expansion_data.mark }; <ins> let attr_id_before = invoc.attr_id(); </ins> let ext = match self.cx.resolver.resolve_invoc(&mut invoc, scope, force) { Ok(ext) => Some(ext), Err(Determinacy::Determined) => None, Err(Determinacy::Undetermined) => { <ins> // Sometimes attributes which we thought were invocations // end up being custom attributes for custom derives. If // that's the case our `invoc` will have changed out from // under us. If this is the case we're making progress so we // want to flag it as such, and we test this by looking if // the `attr_id()` method has been changing over time. if invoc.attr_id() != attr_id_before { progress = true; } </ins> undetermined_invocations.push(invoc); continue }

This is the code you are supposed to use according to the lint. It fails to compile, with It compiles fine if you use just one of the two attributes. Swapping attribute order makes it complain about the last non-derive attribute. This seems broken? cc
Confirmed, this behavior is broken. Possibly related to .
As a workaround specific to serde_derive, we allow multiple elements within one attribute.
yeah, that's what I ended up doing
This should be fixed in


Question: | LL | extern "C" unsafe { |            ^^^^^^ <ins> | = note: see issue #123743 <https://github.com/rust-lang/rust/issues/123743> for more information = help: add `#![feature(unsafe_extern_blocks)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date </ins> error: items in unadorned `extern` blocks cannot have safety qualifiers --> $DIR/unsafe-foreign-mod-2.rs:4:5 | LL |     unsafe fn foo(); |     ^^^^^^^^^^^^^^^^ <del> | help: add unsafe to this `extern` block | LL | unsafe extern "C" unsafe { | ++++++ </del> error: aborting due to 3 previous errors

With the following code: We get this error: Making the block then gives: cc
:+1:, this should error in both cases but the diagnostics are misleading. Going to fix it. r?


Question: <ins> // Don't suggest double quotes when encountering an expr of type `char` where a `&str` // is expected if the expr is not a char literal. // issue: rust-lang/rust#125595 fn main() { let _: &str = ('a'); //~ ERROR mismatched types let token = || 'a'; let _: &str = token(); //~ ERROR mismatched types } </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --
cc


Question: <ins> error[E0771]: use of non-static lifetime `'a` in const generic --> $DIR/outer-lifetime-in-const-generic-default.rs:4:17 | LL |         let x: &'a (); |                 ^^ | = note: for more information, see issue #74052 <https://github.com/rust-lang/rust/issues/74052> error: aborting due to previous error For more information about this error, try `rustc --explain E0771`. </ins>

Const generic defaults are being stabilized, <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to also happen with closures:
I got a fix for this one I think. claim
even worse, this compiles on beta but shouldn't
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
I think this needs to remain open until the fix is beta-backported :thinking: not 100% sure on procedure here
You might be correct. At least that's what happened last time one of my PRs was backport nominated (), though I'm not sure if that was due to that being a regression on stable. Regardless, thanks for reopening this.
that's my understading, too. I /think/ issues that are pending a beta/stable backport (like this one) will stay open until the corresponding backport PR has landed. The {stable,beta}-backport procedure is detailed but this detail is not explicited (I'll see if I can fix that to be more clear). For completeness, backports are discussed every Thursday during the compiler team weekly meeting (). Anyway, thanks a lot for fixing this issue and also to + for reporting and debugging :)
Copied from Zulip: Question/thought: Is this a case where tracking bound vars got in the way? Or did it actually help uncover a potential bug?
Not sure what you mean. The bug was that we were just not doing lifetime name resolution at all on const generic defaults. Like this code compiles on beta: edit: ohhh, you mean ?


Question: <ins> error[E0771]: use of non-static lifetime `'a` in const generic --> $DIR/outer-lifetime-in-const-generic-default.rs:4:17 | LL |         let x: &'a (); |                 ^^ | = note: for more information, see issue #74052 <https://github.com/rust-lang/rust/issues/74052> error: aborting due to previous error For more information about this error, try `rustc --explain E0771`. </ins>

Yeah I think in this case it helped uncover the bug, because of the fact it ICEd and showed us we weren't resolving the closure default.
I guess this example shows that this did help us uncover a bug, but kind of indirectly: This just didn't uncover a case where "lost" bound vars.
this is now fixed on beta


Question: /// ``` ``` <ins> As of version 1.34.0, one can also omit the `fn main()`, but you will have to disambiguate the error type: ```ignore /// ``` /// use std::io; /// let mut input = String::new(); /// io::stdin().read_line(&mut input)?; /// # Ok::<(), io:Error>(()) /// ``` ``` This is an unfortunate consequence of the `?` operator adding an implicit conversion, so type inference fails because the type is not unique. Please note that you must write the `(())` in one sequence without intermediate whitespace so that rustdoc understands you want an implicit `Result`-returning function. </ins> ## Documenting macros Here’s an example of documenting a macro:

Rustdoc now allows us to use in our tests. Unfortunately, this requires writing the manually, which really shouldn't be needed IMHO. So we now have to write: rust ///# fn main() -Result<(), (){ /// let foo = Ok(1usize); /// assert!(foo? 0); ///# } /// where it should suffice to write: rust /// let foo = Ok(1usize); /// assert!(foo? 0); /// Doing so will make the tests shorter and hopefully lead to more and less in tests.
Feels like a no-brainer to me; would be great. :)
I think there are two things we want before doing this: , so that it can always be , and existing code will just work. The re-do, so we can make a type that accepts any error type (since it'll just error anyway).
?
Yes, that's what I'm thinking, and I'm setting up a PR for that. However, it's still unstable.
I talked about this back in March on the " in main" tracking issue: That sample you gave isn't even valid as-is, unless coercing to is also in the pipeline?
That'll be next, hopefully. I wonder if it suffices to or if we need to keep a generic error type (which might mess with type inference). In any event, having both the aforementioned and should be a no-brainer, right?


Question: <ins> error: macro-expanded `extern crate` items cannot shadow names passed with `--extern` --> $DIR/issue-78325-inconsistent-resolution.rs:3:9 | LL |         extern crate std as core; |         ^^^^^^^^^^^^^^^^^^^^^^^^^ ... LL | define_other_core!(); | --------------------- in this macro invocation | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Seems to have regressed in Rust 1.33 based on testing in Godbolt.
With only the errors relevant to the ICE:
I'll fix this.
Fixed in


Question: #[stable(feature = "rust1", since = "1.0.0")] pub trait PhantomFn<A:?Sized,R:?Sized=()> { } <del> /// `PhantomData` is a way to tell the compiler about fake fields. /// Phantom data is required whenever type parameters are not used. /// The idea is that if the compiler encounters a `PhantomData<T>` /// instance, it will behave *as if* an instance of the type `T` were /// present for the purpose of various automatic analyses. </del> <ins> /// `PhantomData<T>` allows you to describe that a type acts as if it stores a value of type `T`, /// even though it does not. This allows you to inform the compiler about certain safety properties /// of your code. /// /// Though they both have scary names, `PhantomData<T>` and "phantom types" are unrelated. 👻👻👻 </ins> /// /// # Examples /// /// When handling external resources over a foreign function interface, `PhantomData<T>` can <del> /// prevent mismatches by enforcing types in the method implementations, although the struct /// doesn't actually contain values of the resource type. </del> <ins> /// prevent mismatches by enforcing types in the method implementations: </ins> /// /// ``` /// # trait ResType { fn foo(&self); };

I need to give a Rust slice to a C API that will return an opaque handle (that actually contains a pointer to the slice), and the slice must outlive the handle. nicely suggested using for this, but the description of phantom data (and its RFC) for me is so far removed from my mental model/terminology of the problem, that it . "…tell the compiler about fake fields" — fake field doesn't sound like a thing I want to create. I'm not sure if a fake field is an actual Rust concept. I'm hoping it's a different way of saying a "pointer that Rust isn't keeping track of". "inform the compiler that one or more instances of the type T could be dropped" — but does it actually drop anything? I want to prevent value from being dropped, so this confuses me. The RFC is even worse, since it uses type variance terminology which is so confusing, that the most comprehensible description of them on Wikipedia is a 3D cube! !
allows you to describe that a type acts as if it stores a value of type , e.g. maybe one is having to use opaque pointers or otherwise disguise the fact that there is a contained in the value, or need to have a lifetime without having an actual reference to attach it to. This is what is meant by "fake field": a field doesn't actually store any data, but it behaves as if it does. If you have a lifetime, and the type is acting like a reference, then (or ) is the recommended approach. It's hard to be more specific without knowing your exact use-case, though. In any case, the major motivation for is to avoiding having to think in terms of co*variance, and instead just think of what the intended "storage" of a type is. The RFC is meant to serve as a technical reference to describe the behaviour unambiguously. I definitely agree that the current docs are not as helpful as they could be.
I see you've used lifetime as part of 's type. In my code I've used and got confusing error messages. That bit in the documentation would help a lot! (just saying is very unhelpful) BTW: the first paragraph in your comment is already clearer to me than the documentation :)
The example seems relevant.


Question: #[stable(feature = "rust1", since = "1.0.0")] pub trait PhantomFn<A:?Sized,R:?Sized=()> { } <del> /// `PhantomData` is a way to tell the compiler about fake fields. /// Phantom data is required whenever type parameters are not used. /// The idea is that if the compiler encounters a `PhantomData<T>` /// instance, it will behave *as if* an instance of the type `T` were /// present for the purpose of various automatic analyses. </del> <ins> /// `PhantomData<T>` allows you to describe that a type acts as if it stores a value of type `T`, /// even though it does not. This allows you to inform the compiler about certain safety properties /// of your code. /// /// Though they both have scary names, `PhantomData<T>` and "phantom types" are unrelated. 👻👻👻 </ins> /// /// # Examples /// /// When handling external resources over a foreign function interface, `PhantomData<T>` can <del> /// prevent mismatches by enforcing types in the method implementations, although the struct /// doesn't actually contain values of the resource type. </del> <ins> /// prevent mismatches by enforcing types in the method implementations: </ins> /// /// ``` /// # trait ResType { fn foo(&self); };

A previous example was referenced at the though I think rustbyexample is clearer. Note that the syntax of this example has changed recently. That didn't used to be required. If indeed what you need is something similar, you should flag it on rustbyexample for a more practical example. I was only aware of using phantom types in for use cases like unit system manipulation and such. If you can provide the gist of what other things they can be used for I can probably shoehorn it into an rustbyexample example(s) (there's IRC if I get stuck). Though I don't know when I'd get to it.
is designed as a low-level building block to enable certain types of unsafe code to be written safely. The relationship to phantom types (as used for dimensional analysis etc.) is the name (almost-coincidence) and the fact that the language doesn't allow type parameters to be left completely unused (meaning a phantom type has to be mentioned, e.g, in , to let the code compile). Almost instances of phantom types for dimensional analysis won't care about the precise variance (unlike unsafe/low-level code) and so just need to make the compiler shut up. :)
great that you've made progress!
Okay. The distinction between them is definitely unclear then too (in the docs).
If it's just to make the compiler shut up, then it's a good indication that the old default was better (not needing PhantomData for most unused type parameters).
I sympathize. PhantomData and PhantomFn are Byzantine to me as well, and I'm hitting several issues in rlibc because of them.
, because unused parameter did absolutely nothing, even when I used a parameter with the same name a method. I don't mind having a marker, I just needed to learn how to use it.
To be clear, it is just the use of 'unused' type parameters for dimensional analysis/tagging where the details of the precise used aren't so important. It is extremely important for data structures building on (or otherwise not using their lifetime/type parameters directly internally) to get their uses correct, as they are actually informing the compiler of information necessary for safety. There has been a regular stream of bugs/problems discovered in types in this repo due to the old default not helping with code.


Question: #[stable(feature = "rust1", since = "1.0.0")] pub trait PhantomFn<A:?Sized,R:?Sized=()> { } <del> /// `PhantomData` is a way to tell the compiler about fake fields. /// Phantom data is required whenever type parameters are not used. /// The idea is that if the compiler encounters a `PhantomData<T>` /// instance, it will behave *as if* an instance of the type `T` were /// present for the purpose of various automatic analyses. </del> <ins> /// `PhantomData<T>` allows you to describe that a type acts as if it stores a value of type `T`, /// even though it does not. This allows you to inform the compiler about certain safety properties /// of your code. /// /// Though they both have scary names, `PhantomData<T>` and "phantom types" are unrelated. 👻👻👻 </ins> /// /// # Examples /// /// When handling external resources over a foreign function interface, `PhantomData<T>` can <del> /// prevent mismatches by enforcing types in the method implementations, although the struct /// doesn't actually contain values of the resource type. </del> <ins> /// prevent mismatches by enforcing types in the method implementations: </ins> /// /// ``` /// # trait ResType { fn foo(&self); };

(I imagine that many external libs with data structures have had to insert 's since the change... meaning they were likely incorrect too.)


Question: use std::fmt::{Debug, Display}; <del> #[marker] trait Marker {} </del> <ins> #[marker] trait Marker {} </ins> impl<T: Debug> Marker for T {} impl<T: Display> Marker for T {}

Not sure if we have a test for the following and rust #![feature(markertraitattr)] #[marker] trait Marker {} impl Marker for &' () {} impl Marker for &' () {} If not, we need to add them, since they would be important for special casing during canonicalization. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I can help add this test if needed. (Did not rustbot claim so as to not remove lcnr from assignee)
Sure :) would help out if nothing else
assign Rageking8
Error: Parsing assign command in failed: ...' Rageking8' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
assign
label +F-markertraitattr In case this needs to be indexed in the future.


Question: pub fn new_raw(fam: c_int, ty: c_int) -> io::Result<Socket> { unsafe { <del> // On linux we first attempt to pass the SOCK_CLOEXEC flag to // atomically create the socket and set it as CLOEXEC. Support for // this option, however, was added in 2.6.27, and we still support // 2.6.18 as a kernel, so if the returned error is EINVAL we // fallthrough to the fallback. #[cfg(target_os = "linux")] { match cvt(libc::socket(fam, ty | libc::SOCK_CLOEXEC, 0)) { Ok(fd) => return Ok(Socket(FileDesc::new(fd))), Err(ref e) if e.raw_os_error() == Some(libc::EINVAL) => {} Err(e) => return Err(e), } } let fd = cvt(libc::socket(fam, ty, 0))?; let fd = FileDesc::new(fd); fd.set_cloexec()?; let socket = Socket(fd); </del> <ins> cfg_if::cfg_if! { if #[cfg(target_os = "linux")] { // On Linux we pass the SOCK_CLOEXEC flag to atomically create // the socket and set it as CLOEXEC, added in 2.6.27. let fd = cvt(libc::socket(fam, ty | libc::SOCK_CLOEXEC, 0))?; Ok(Socket(FileDesc::new(fd))) } else { let fd = cvt(libc::socket(fam, ty, 0))?; let fd = FileDesc::new(fd); fd.set_cloexec()?; let socket = Socket(fd); </ins> <del> // macOS and iOS use `SO_NOSIGPIPE` as a `setsockopt` // flag to disable `SIGPIPE` emission on socket. #[cfg(target_vendor = "apple")] setsockopt(&socket, libc::SOL_SOCKET, libc::SO_NOSIGPIPE, 1)?; </del> <ins> // macOS and iOS use `SO_NOSIGPIPE` as a `setsockopt` // flag to disable `SIGPIPE` emission on socket. #[cfg(target_vendor = "apple")] setsockopt(&socket, libc::SOL_SOCKET, libc::SO_NOSIGPIPE, 1)?; </ins> <del> Ok(socket) </del> <ins> Ok(socket) } } </ins> } }

Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: uses the flag with  (mentioned above, in 2.6.23) uses with  ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") uses  to atomically set the flag on the pipe fds ( in 2.6.27) uses with  ( in 2.6.27) uses  to permit use of ( in 2.6.28) ~ ( in 4.5, not fixed by this proposal)~ As you can see, the workarounds fixed by this proposal all have a similar flavor. Originally posted by in
Kernel updated in .
As noted, needs a much newer kernel 4.5, so we'll still need that fallback. But all the stuff should be ok to assume available now.
The new minimal version is 2.6.27 from what I can see, so "Socket::accept uses accept4(2) to permit use of SOCK_CLOEXEC" still needs a fallback, right?
The builder is using 2.6.32 headers, so I would call that our new minimum.
Ah right; I am actually not sure where I got the 27 from...
The title of suggested 2.6.27, but we went a little higher to match the actual distros in use.
I know this is ancient history, but do you recall the problem with ? You introduced that comment about "some kernel" in , and you were the last to update it in . If the problem kernels were before 2.6.32, then I'd like to clean that up now.
Just digging in kernel history, I did find one hiccup in , but that bug was introduced and resolved during the 3.7 development cycle, not in a release.
IIRC we just mirrored what musl did at the time, which looks like it : Looks like the original mailing list thread is gone and there's no comments in the musl source, and I don't recall what happened here. I suspect it would be safe to remove those workarounds and just assume works one the first try until someone says differently.


Question: <del> Subproject commit 4cf36f285084f8f841f3cff7b29d44b1d95ee1dd </del> <ins> Subproject commit 54bbbd13ac532deed80416295a224ce12547a40c </ins>

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Where can I learn more about how this check is done? I just built stage 1 compiler with current master, and I was able to build miri with .
I'm guessing one of the tests is failing because it now needs a . The failure should be hidden somewhere in the logs of the runner:
should fix tihs.
Ah, so the problem is in one of the tests.. I only checked building.
usually, should let you run the tests, but this is currently broken by


Question: pub mod map; pub mod set; <ins> #[doc(hidden)] </ins> trait Recover<Q: ?Sized> { type Key;

It shows up on and , but not on or
This is actually a known bug in rustdoc and/or the compiler, although I can't seem to find the issue right now... Basically it'll suffice to just tag the trait with for now.


Question: assert_eq!(c.stream_position()?, 8); assert_eq!(c.stream_position()?, 8); <ins> c.rewind()?; assert_eq!(c.stream_position()?, 0); assert_eq!(c.stream_position()?, 0); </ins> Ok(()) }

<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: This is a tracking issue for the convenience method . [x] Implementation: [x] Final commenting period (FCP) [x] Stabilization PR: <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the .


Question: assert_eq!(c.stream_position()?, 8); assert_eq!(c.stream_position()?, 8); <ins> c.rewind()?; assert_eq!(c.stream_position()?, 0); assert_eq!(c.stream_position()?, 0); </ins> Ok(()) }

:bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
I missed it completely in nigthlies sadly, else I would have proposed it returns the of the old offset, because currently it cannot replace , only the form without assignement.


Question: <ins> // edition: 2021 use std::collections::HashMap; use std::future::Future; use std::pin::Pin; pub trait Trait { fn do_something<'async_trait>(byte: u8) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>; } pub struct Struct; impl Trait for Struct { fn do_something<'async_trait>(byte: u8) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>> { Box::pin( async move { let byte = byte; let _: () = {}; }) } } pub struct Map { map: HashMap<u16, fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>>>, } impl Map { pub fn new() -> Self { let mut map = HashMap::new(); map.insert(1, Struct::do_something); Self { map } //~^ ERROR mismatched types } } fn main() {} </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
Is this related to ?
Nope
Ooh I misread the Typerror ice, my bad :upsidedownface:
No big deal, this has to do with a lock (well, refcell) being held in hir typeck, if you're curious