Question: "lazy_static", "log", "rls-span", <del> "rustc-ap-rustc_ast", "rustc-ap-rustc_ast_pretty", "rustc-ap-rustc_data_structures", "rustc-ap-rustc_errors", "rustc-ap-rustc_parse", "rustc-ap-rustc_session", "rustc-ap-rustc_span", </del> ] [[package]]

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!
This might be due to no longer builds: ` We need a new version I think. The last published version of is 5 months old already :thinking: Can you please check why there are no new versions being published?
TIL scheduled GitHub Action Workflows apparently require regular activity in the repository to keep going :eyes:
I didn't realize anyone was still using those crates so I disabled the action, I believe it was broken anyway. Does rustfmt and/or other crates still use those packages? If so I can try to find time to restart the action.
Racer those crates. And RLS . So without those crates compiling racer with the latest nightly isn't possible, which makes compiling RLS impossible and therefore blocks the sync of RLS back to rust-lang/rust.
Would it maybe be an option to make racer depend on to compile instead of publishing AP crates?
We stopped using them in rustfmt a while ago and I can't imagine a scenario where we'd switch back. Agreed on racer, which AIUI is the last true direct consumer of those crates. However, it's also in and those crates only get bumped in racer when a racer consumer needs them to be bumped.
Ah ok. In that case if this is purely for something in maintenance mode I think my own personal tenure in maintaining these crates is over with, so I would prefer to hand over the reins to someone else. Would someone be willing to volunteer to take over these crates?
let's sync up on #t-infra on Zulip -- I think it makes sense to move these crates into infra control/publication.
Let's wait if Racer can move over to rustc-dev racer-rust/racer. If so, there shouldn't be a need to keep maintaining rustc-ap crates at all. Looking at the dependents on , there really is only , the crates themselves and (which by now uses ).
has some relevant considerations as well.


Question: "lazy_static", "log", "rls-span", <del> "rustc-ap-rustc_ast", "rustc-ap-rustc_ast_pretty", "rustc-ap-rustc_data_structures", "rustc-ap-rustc_errors", "rustc-ap-rustc_parse", "rustc-ap-rustc_session", "rustc-ap-rustc_span", </del> ] [[package]]

One way or another I think the AP crates need to be accounted for as per the accepted RFC, though it certainly would be a simpler story if they no longer need to be updated/published
Happy to coordinate as necessary, just let me know!
Over a month now. Is this gonna be fixed?
it's blocked on


Question: enum FieldName { UnnamedField(uint), // index <del> // FIXME #6993: change type (and name) from Ident to Name NamedField(ast::Ident), </del> <ins> // (Name, not Ident, because struct fields are not macro-hygienic) NamedField(ast::Name), </ins> } impl<'a, 'tcx> PrivacyVisitor<'a, 'tcx> {

Tracking issue for: rust-lang/rfcs Functional record update does not mark the source as consumed, even if does not implement Copy. This means that e.g. the source's destructor will eventually be run, so the following code prints :
Note that, as discovered, you can also explicitly consume , also allowing code like:
:bomb:
Is legal, even if all members are private? It's a bit surprising
It is. There's the potentially-useful case where some of the members are private, and FRU allows you to update the public ones. Of course it should consume the source even then.
P-backcompat-lang, 1.0 beta
In my opinion the problem here is the privacy violation. The idea is that is expanded to and so forth. In this case, that does not trigger a move, because the types of those fields are . I think that part is acting as expected. What is surprising is that one can do this from outside the module.
That was (but my favored solution isn't minor).
When I initially saw this problem, I did not see it as a privacy violation, for the (obvious?) reason that since no private members of had been mentioned in the code , the client module is not breaking any abstraction introduced by privacy. I think this line of thinking is analogous to outline of the useful case where FRU allows one to update the public members of a type and silently move the private ones as well, via . This is useful for the case where the author of wants to reserve the right to add new private members to while still allowing for clients to use the convenient FRU syntax. I originally was going to try to explain my point of view via analogy with something from hygienic macros: If I were to define (and export) a macro within 's defining module: then it should, in principle, not be a privacy violation to use from client code outside 's defining module. (That is, in principle, hygiene should allow macros to expose controlled access to private internals.) Then I realized the crucial problem with that kind of analogy: is something that the designer of has to choose to put into the module; i.e., it is opt-in. But currently in Rust, FRU is not opt-in; its not even something you can opt out of.


Question: enum FieldName { UnnamedField(uint), // index <del> // FIXME #6993: change type (and name) from Ident to Name NamedField(ast::Ident), </del> <ins> // (Name, not Ident, because struct fields are not macro-hygienic) NamedField(ast::Name), </ins> } impl<'a, 'tcx> PrivacyVisitor<'a, 'tcx> {

Any struct automatically is given support for it, whether it be appropriate for that struct or not. And that seems wrong, at least given examples like the one provided here in . This latter point, that providing support for FRU should not be something that is silently attached to a type like , seems somewhat in line with the thinking given in . But I am also pretty sure we cannot adopt anything of the scope given in that draft. (Still, maybe there's a hint of solution embedded within, in the sense of having some way of marking a type as data vs abstract; see final two bullet points below.) So, as I see it, we can either: out a way to support the point-of-view outlined here in the description for , in that should somehow be treated as consuming . Such a change seems like it would be quite subtle, since we would need to have some way of expressing that code like is sound, even if the types of the fields and are consumed by their respective and methods. (In other words, need to consume , yet somehow not completely consume it. Maybe there's a way to think of it as consuming "whatever is left of the type", I do not know.) Advantages: This would address the bug as described by the issue author, and would not break any code that was not already broken. Drawbacks: It is not clear what the semantics are for this form (in other words: the phrase "would not break any code" above is only true if you first accept that this hypothesized semantics exists). Also, there may not be time to do this properly for 1.0. , try to adopt a data/abstract-type distinction along the lines of the one in draft RFC. (I'm not going to write Advantages/Drawbacks for this; I think we clearly do not have time to do it that way for 1.0) , change FRU into a non-hygienic expansion into the record construction form with all fields listed, in the sense that is synonymous with and subject to privacy checks. Advantages: Seems really simple to implement, and is consistent with at least one core team member's mental model of FRU. Drawbacks: If we did this, then code like the example above would break.


Question: enum FieldName { UnnamedField(uint), // index <del> // FIXME #6993: change type (and name) from Ident to Name NamedField(ast::Ident), </del> <ins> // (Name, not Ident, because struct fields are not macro-hygienic) NamedField(ast::Name), </ins> } impl<'a, 'tcx> PrivacyVisitor<'a, 'tcx> {

, let FRU keep its current hygienic (aka "privacy violating") semantics, but also make FRU something one must opt-in to support on a type. E.g. make a builtin trait that a struct must implement in order to be usable with FRU. (Or maybe its an attribute you attach to the item.) Advantages: Also seems really simple to implement (in the language). Accommodates users of FRU for the example. Drawbacks: If we did this, it would impose a burden on all code today that makes use of FRU, since they would have to start implementing . Thus, not simple to implement for the libraries and the overall ecosystem. , a hybrid between the previous two bullet-points: By default, treat FRU as non-hygienic expansion, but add a builtin trait that one can opt-into to get the hygienic (aka "privacy violating") semantics. As a bonus, perhaps implementing on a struct would also imply implementing on that struct, which seems like it would basically give us something very similar to the semantics desired by (Or, again, maybe its an attribute you attach to the item. This detail does not particularly matter to me.) Advantage: While this is obviously more complicated than the previous two bullet-points, it has the advantage that it has a staged landing strategy: We could just_ implement the change to FRU to be non-hygienic expansion for 1.0 beta. We could add at an arbitrary point in the future; it would not have to be in the 1.0 release. Drawback: People have claimed that some of my past proposals were a bit ... baroque. I imagine this one is no exception. :) (In other words, this semantics is a little complicated to explain to a newcomer.)
I don't want to make a big fuss about it, but I do want to note, again, that our "deadlines" are entirely self-imposed, and that under these circumstances "we don't have time" is slightly odd, because we can make time, any time we want. The blanket refusal to even contemplate doing that - even in light of new information - and to weigh the tradeoffs on their own merits is something I still don't really understand.


Question: enum FieldName { UnnamedField(uint), // index <del> // FIXME #6993: change type (and name) from Ident to Name NamedField(ast::Ident), </del> <ins> // (Name, not Ident, because struct fields are not macro-hygienic) NamedField(ast::Name), </ins> } impl<'a, 'tcx> PrivacyVisitor<'a, 'tcx> {

That out of the way, an additional possibility, let's call it 6., for list: We could just make the "abstract type" vs. "data type" distinction based on "does or doesn't the type have a private field". This doesn't entirely fill me with satisfaction (as with "worse is better" solutions in general), with specific drawbacks being that it doesn't extend cleanly to the nullary case (no fields at all), and that in terms of UX a change of semantics based on the presence or absence of a private field may be unexpected, but on the plus side, it's simpler, and would, I think, work.
Sure, hypothetical show-stopper issues could cause us to revisit our self-imposed schedule. I personally don't think that this issue, on its own at least, provides sufficient motivation for schedule revision. I admit that your draft RFC seems like it addresses a host of issues, so maybe all of them taken in unison would be a different story. (But then again, that's not even my call to make.)
There were a couple more options that I should have put on the list, for completeness, but overlooked. 6 note, the "has any private fields ==abstract-type; all public fields ==data-type", is one of them. This would (probably) be less work than adopting the draft RFC in full, but I am not sure what the other Advantages/Disadvantages are. I invite others to write an Advantages/Drawbacks for this approach (perhaps in an RFC PR). 7 We could add a way for a struct to opt-out of FRU support entirely. So in this approach, one would attach the appropriate attribute to , , etc. Advantages: won't break any existing code Drawbacks: Seems quite fragile; we may be good about auditing our own stdlib, but clients who are not aware of the attribute may inadvertently expose themselves to the same bug that currently plagues .
Also, I just wanted to mention: when I wrote my comment 6 hours ago, I came to the keyboard thinking that the FRU support for adding new private fields to and having still work was an important use case. But after some reflection in the hours since, supporting that use case does not seem as important to me.


Question: enum FieldName { UnnamedField(uint), // index <del> // FIXME #6993: change type (and name) from Ident to Name NamedField(ast::Ident), </del> <ins> // (Name, not Ident, because struct fields are not macro-hygienic) NamedField(ast::Name), </ins> } impl<'a, 'tcx> PrivacyVisitor<'a, 'tcx> {

Here is why: It is relatively easy for a developer who wants to provide that sort of extensible abstraction can still do it, by factoring the type into a all-public front-end with a single public field that holds the all-private back-end, like so: So, given that there exists a reasonable pattern to bring back usable FRU even under the option "(3.) change FRU into a non-hygienic expansion into the record construction form with all fields listed, in the sense that is synonymous with and subject to privacy checks.", I would not object to us adopting (3.) aka solution.
I think that "has any private field" is a decent way to handle abstractness (you can always add a private unit field). On the other hand, Rust supports trait bounds of types – these should handle roles just fine – you shouldn't be able to coerce past a trait bound. By the way, this is somewhat subtle, because coercing to is wrong (as it leaks memory – it coerces past the implicit bound), but coercing to is fine (as the bound isn't used by ). However, this isn't a property of – you still can't coerce to – so we probably want a relatively-sophisticated way to occasionally ignore roles.
I mean, Rust already has a mechanism for ensuring representation-abstraction – private fields – which are semantic (they are handled after type-checking, we probably want to handle them during it, but they definitely aren't handled syntactically or during resolution). It is just that FRU currently accesses them improperly. Also, it doesn't have much to do with e.g. roles – is an abstract type, but it doesn't use any bound on . only uses the implicit bound. A for data-only types would be nice, through.
Another alternative came to me while I was drafting an RFC about this. (But its an alternative that I do not particularly like.) 8a Instead of making "has any private fields" the thing that makes FRU unavailable, instead make the rule be "has all private fields." Thus types like and will not be subject to the vulnerability outlined here. Adding a single field to an otherwise private struct is what changes the nature of a struct with respect to abstraction and FRU, rather than adding a single non- field to an otherwise public struct.


Question: enum FieldName { UnnamedField(uint), // index <del> // FIXME #6993: change type (and name) from Ident to Name NamedField(ast::Ident), </del> <ins> // (Name, not Ident, because struct fields are not macro-hygienic) NamedField(ast::Name), </ins> } impl<'a, 'tcx> PrivacyVisitor<'a, 'tcx> {

8b, which is so similar to 8a that I gave them both the same numeral: Outlaw the trivial FRU form . That is, to use FRU, you have to use at least one field in the constructing expression. Again, this implies that types like and will not be subject to the vulnerability outlined here. (This may be a decent change to make to the language regardless of whatever else happens on this ticket; the only argument in favor of keeping support for such a trivial form is maybe for supporting certain macro-expansions. But fully-general macro-authors already have to tread very carefully around corner cases on structs, due to issues like the empty braces problem (see )
That would leave the vulnerability intact in the case where the type has both public fields and private fields, the fact that no such type currently exists in the standard library notwithstanding (just as a very artificial demonstration, consider a with ).
yep. Library authors would have to factor their structures very carefully. (I described the drawback you mention in the RFC I posted shortly after you wrote your comment, though I did not include the detail of having the private fields be , which does seem like it could make the situation all the more subtle. Not insurmountable, but a definite drawback.) Just to be clear, I'm not saying I prefer (8a) or (8b); I'm just trying to be complete in my exploration of the solution space.
Repurposed as the tracking issue for rust-lang/rfcs
I'll just go snag


Question: // Try to lookup name in more relaxed fashion for better error reporting. let ident = path.last().unwrap().ident; <del> let candidates = self.lookup_import_candidates(ident, ns, is_expected); </del> <ins> let candidates = self.lookup_import_candidates(ident, ns, is_expected) .drain(..) .filter(|ImportSuggestion { did, .. }| { match (did, def.and_then(|def| def.opt_def_id())) { (Some(suggestion_did), Some(actual_did)) => *suggestion_did != actual_did, _ => true, } }) .collect::<Vec<_>>(); </ins> if candidates.is_empty() && is_expected(Def::Enum(DefId::local(CRATE_DEF_INDEX))) { let enum_candidates = self.lookup_import_candidates(ident, ns, is_enum_variant);

For this code: You get the following error message: The suggestion may be excused to be not 100% perfect, but here it suggests to add an use statement despite that same item being imported already. What I want is this exactly: that it removes stuff from the suggestion list that is already being imported. Note that changing the glob import to a non glob one doesn't change anything.
cc
Why is that even an error?
tuple structs have private fields by default, you can't construct instances of B outside of the foo module.
oh ^^ maybe we should simply modify this error message then to say that the "function" is private?
It already says "constructor is not visible here due to private fields". That's okay, but maybe you might have meant another B from another module or something. However, the candidate offered is not any better as its the same one you are attempting to use.
Reopening to track "removal of suggestion" work for pub tuple structs with private fields.


Question: pub struct AnonPipe(FileDesc); pub fn anon_pipe() -> io::Result<(AnonPipe, AnonPipe)> { <del> syscall! { fn pipe2(fds: *mut c_int, flags: c_int) -> c_int } static INVALID: AtomicBool = AtomicBool::new(false); </del> let mut fds = [0; 2]; <del> // Unfortunately the only known way right now to create atomically set the // CLOEXEC flag is to use the `pipe2` syscall on Linux. This was added in // 2.6.27, however, and because we support 2.6.18 we must detect this // support dynamically. if cfg!(any( target_os = "dragonfly", target_os = "freebsd", target_os = "linux", target_os = "netbsd", target_os = "openbsd", target_os = "redox" )) && !INVALID.load(Ordering::SeqCst) { // Note that despite calling a glibc function here we may still // get ENOSYS. Glibc has `pipe2` since 2.9 and doesn't try to // emulate on older kernels, so if you happen to be running on // an older kernel you may see `pipe2` as a symbol but still not // see the syscall. match cvt(unsafe { pipe2(fds.as_mut_ptr(), libc::O_CLOEXEC) }) { Ok(_) => { return Ok((AnonPipe(FileDesc::new(fds[0])), AnonPipe(FileDesc::new(fds[1])))); } Err(ref e) if e.raw_os_error() == Some(libc::ENOSYS) => { INVALID.store(true, Ordering::SeqCst); } Err(e) => return Err(e), </del> <ins> // The only known way right now to create atomically set the CLOEXEC flag is // to use the `pipe2` syscall. This was added to Linux in 2.6.27, glibc 2.9 // and musl 0.9.3, and some other targets also have it. cfg_if::cfg_if! { if #[cfg(any( target_os = "dragonfly", target_os = "freebsd", target_os = "linux", target_os = "netbsd", target_os = "openbsd", target_os = "redox" ))] { cvt(unsafe { libc::pipe2(fds.as_mut_ptr(), libc::O_CLOEXEC) })?; Ok((AnonPipe(FileDesc::new(fds[0])), AnonPipe(FileDesc::new(fds[1])))) } else { cvt(unsafe { libc::pipe(fds.as_mut_ptr()) })?; let fd0 = FileDesc::new(fds[0]); let fd1 = FileDesc::new(fds[1]); fd0.set_cloexec()?; fd1.set_cloexec()?; Ok((AnonPipe(fd0), AnonPipe(fd1))) </ins> } } <del> cvt(unsafe { libc::pipe(fds.as_mut_ptr()) })?; let fd0 = FileDesc::new(fds[0]); let fd1 = FileDesc::new(fds[1]); fd0.set_cloexec()?; fd1.set_cloexec()?; Ok((AnonPipe(fd0), AnonPipe(fd1))) </del> } impl AnonPipe {

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: <ins> error[E0308]: `if` and `else` have incompatible types --> $DIR/issue-82361.rs:10:9 | LL | /     if true { LL | |         a | |         - expected because of this LL | |     } else { LL | |         b | |         ^ | |         | | |         expected `usize`, found `&usize` | |         help: consider dereferencing the borrow: `*b` LL | |     }; | |_____- `if` and `else` have incompatible types error[E0308]: `if` and `else` have incompatible types --> $DIR/issue-82361.rs:16:9 | LL | /     if true { LL | |         1 | |         - expected because of this LL | |     } else { LL | |         &1 | |         -^ | |         | | |         expected integer, found `&{integer}` | |         help: consider removing the `&` LL | |     }; | |_____- `if` and `else` have incompatible types error[E0308]: `if` and `else` have incompatible types --> $DIR/issue-82361.rs:22:9 | LL | /     if true { LL | |         1 | |         - expected because of this LL | |     } else { LL | |         &mut 1 | |         -----^ | |         | | |         expected integer, found `&mut {integer}` | |         help: consider removing the `&mut` LL | |     }; | |_____- `if` and `else` have incompatible types error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

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


Question: // `match ::std::future::IntoFuture::into_future(<expr>) { ... }` let into_future_span = self.mark_span_with_reason( DesugaringKind::Await, <del> await_span, </del> <ins> dot_await_span, </ins> self.allow_into_future.clone(), ); let into_future_expr = self.expr_call_lang_item_fn(

This code: produces: Which is invalid. Looks like the span of the desugaring of uses only the part, instead of the span of the entire expression. This results in invalid suggestions when used by the code in .
I'm not entirely sure if this means that desugaring should use a bigger span, or if the suggestion diagnostic needs to be interpreted differently.
hmm.. is the only case where the desugared expr's span doesn't cover the whole piece of code it comes from? That doesn't sound right. If wonder if the expr should have the bigger span by default, and then async-specific code could grab the tighter span for diagnostics that need to point at the operator.
Some of the desugaring only uses the span, but the parts relevant for diagnostics like this do use the full span. Not sure if there's a problem there too.
I thought I might have accidentally introduced this bug in , but right after that PR was merged, the output was correct: So something changed in the last two months in what spans are used for await desugarings, it seems.
actually I think it was introduced in in , cc Do you need someone to fix this? I'm happy to put up a quick PR.
Yeah, looks like it: I just finished bisecting, which pointed at a rollup involving .
this was introduced in the PR linked earlier to try and improve other errors. It is tricky because reducing the span to only incurs these kind of bugs. On the other hand, the errors that got improved there became much less noisy, so I wouldn't want to revert the whole change. My fix above will solve this issue, but I'm sure there will be others in the future :-/


Question: # # Note that we don't literally overwrite the gdb.exe binary because it appears # to just use gdborig.exe, so that's the binary we deal with instead. <del> - script: | powershell -Command "$ProgressPreference = 'SilentlyContinue'; iwr -outf %MINGW_ARCHIVE% %MINGW_URL%/%MINGW_ARCHIVE%" 7z x -y %MINGW_ARCHIVE% > nul powershell -Command "$ProgressPreference = 'SilentlyContinue'; iwr -outf 2017-04-20-%MSYS_BITS%bit-gdborig.exe %MINGW_URL%/2017-04-20-%MSYS_BITS%bit-gdborig.exe" mv 2017-04-20-%MSYS_BITS%bit-gdborig.exe %MINGW_DIR%bingdborig.exe echo ##vso[task.prependpath]%CD%%MINGW_DIR%bin </del> <ins> - bash: | set -e curl -o mingw.7z $MINGW_URL/$MINGW_ARCHIVE 7z x -y mingw.7z > /dev/null curl -o $MINGW_DIR/bin/gdborig.exe $MINGW_URL/2017-04-20-${MSYS_BITS}bit-gdborig.exe echo "##vso[task.prependpath]`pwd`/$MINGW_DIR/bin" </ins> condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'), ne(variables['MINGW_URL'],'')) displayName: Download custom MinGW <del> # Otherwise pull in the MinGW installed on appveyor - script: | echo ##vso[task.prependpath]%MSYS_PATH%mingw%MSYS_BITS%bin </del> <ins> # Otherwise install MinGW through `pacman` - bash: | set -e arch=i686 if [ "$MSYS_BITS" = "64" ]; then arch=x86_64 fi pacman -S --noconfirm --needed mingw-w64-$arch-toolchain mingw-w64-$arch-cmake mingw-w64-$arch-gcc mingw-w64-$arch-python2 echo "##vso[task.prependpath]$(System.Workfolder)/msys2/mingw$MSYS_BITS/bin" </ins> condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'), eq(variables['MINGW_URL'],'')) <del> displayName: Add MinGW to path </del> <ins> displayName: Download standard MinGW </ins> # Make sure we use the native python interpreter instead of some msys equivalent # one way or another. The msys interpreters seem to have weird path conversions # baked in which break LLVM's build system one way or another, so let's use the # native version which keeps everything as native as possible. <del> - script: | copy C:Python27amd64python.exe C:Python27amd64python2.7.exe echo ##vso[task.prependpath]C:Python27amd64 </del> <ins> - bash: | set -e cp C:/Python27amd64/python.exe C:/Python27amd64/python2.7.exe echo "##vso[task.prependpath]C:/Python27amd64" </ins> displayName: Prefer the "native" Python as LLVM has trouble building with MSYS sometimes condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT')) # Note that this is originally from the github releases patch of Ninja <del> - script: | md ninja powershell -Command "$ProgressPreference = 'SilentlyContinue'; iwr -outf 2017-03-15-ninja-win.zip https://rust-lang-ci-mirrors.s3-us-west-1.amazonaws.com/rustc/2017-03-15-ninja-win.zip" 7z x -oninja 2017-03-15-ninja-win.zip del 2017-03-15-ninja-win.zip set RUST_CONFIGURE_ARGS=%RUST_CONFIGURE_ARGS% --enable-ninja echo ##vso[task.setvariable variable=RUST_CONFIGURE_ARGS]%RUST_CONFIGURE_ARGS% echo ##vso[task.prependpath]%CD%ninja </del> <ins> - bash: | set -e mkdir ninja curl -o ninja.zip https://rust-lang-ci-mirrors.s3-us-west-1.amazonaws.com/rustc/2017-03-15-ninja-win.zip 7z x -oninja ninja.zip rm ninja.zip echo "##vso[task.setvariable variable=RUST_CONFIGURE_ARGS]$RUST_CONFIGURE_ARGS --enable-ninja" echo "##vso[task.prependpath]`pwd`/ninja" </ins> displayName: Download and install ninja condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))

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


Question: fn get_str() -> &str; // ILLEGAL, no inputs fn frob(s: &str, t: &str) -> &str; // ILLEGAL, two inputs <ins> fn frob<'a, 'b>(s: &'a str, t: &'b str) -> &str; // Expanded: Output lifetime is unclear </ins> fn get_mut(&mut self) -> &mut T; // elided fn get_mut<'a>(&'a mut self) -> &'a mut T; // expanded

Reading over the Ownership section in TRPL and came across the example As a newbie, this was very confusing. I believe the situation could be explained by simply adding another line. I'm not sure if this is the best way to do this.
This sounds like a great fix to me, (although I would add the to the signature for clarity). PR welcome! :smile:
I've been waiting for input on my PR for several days. Still have no response. The ? didn't compile, and so I'm not sure what to change it to. I thought this section was ignored by the compile, but it doesn't seem that way.
How about:
Oh, sorry. I didn't even parse that there was a PR referring back to this issue :sweat_smile:
That's what the original is, I was very confused by that, and I was trying to update the docs to sufficiently explain the problem with just a short bit of code. The second bit of code was much better at explaining the problem to me, as the question mark implies that the return lifetime is ambiguous.
It's also the only place that this notation is used, which makes it confusing.
So what should I change it to? suggested
I think that's fine


Question: -> Option<(Level, LintSource)> { self.id_to_set.get(&id).map(|idx| { <del> self.sets.get_lint_level(lint, *idx) </del> <ins> self.sets.get_lint_level(lint, *idx, None) </ins> }) } }

The following snippet works fine before but now it reports a warning: Steps to reproduce: clone rustup override set nightly-2017-08-11 cargo test Is this an expected behavior, or a bug? Thank you!
cc -- probably related to the new lint implementation
Yes this was caused by The bug is on . The check for whether is in scope is not checking the current set of attributes being linted. For example this does not warn: but this warns: (as you've noticed) The fix is to just take the local variable into account which has the up-to-that-point set of lint attributes collected.
I've opened a PR for this at


Question: use crate::hir::def_id::DefId; use crate::hir; use crate::ty::TyCtxt; <del> use syntax_pos::symbol::{sym, Symbol}; </del> <ins> use syntax_pos::symbol::Symbol; </ins> use crate::hir::map::blocks::FnLikeNode; use syntax::attr;

The feature allows calling any expression of a tuple-like constructor in a : cc
Implemented on 2019-06-07 by in which was reviewed by
Is there anything else needs to be done to resolve this issue?
FCP and stabilization pull request.
Do you think you have time to write a report (e.g. in the style of ) and amend the reference after?
I propose that we stabilize . Tracking issue: Version target: 1.40 (2019-11-05 =beta, 2019-12-19 =stable). Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called : Consistency with other . This should also ensure that constructors implement traits and can be coerced to function pointers, if they are introduced. - Tests various syntactic forms, use in both and items, and constructors in both the current and extern crates. The case in should also get a test.
Thanks! Could you embed this report in a PR with the aforementioned test there as well? I'll FCP that PR.


Question: use crate::hir::def_id::DefId; use crate::hir; use crate::ty::TyCtxt; <del> use syntax_pos::symbol::{sym, Symbol}; </del> <ins> use syntax_pos::symbol::Symbol; </ins> use crate::hir::map::blocks::FnLikeNode; use syntax::attr;

When using to create an enum variant in Rust 1.37+, we get an error: results in: but if the enum is constructed explicitly, the compilation succeeds: Looking at , it looks like should be considered a with . Playground links for both variants: ,
Duplicate of (will close in a bit). It seems like folks open this issue because on stable, the error message does not point to the tracking issue, e.g. you don't see: can we fix this?
I think we should just stabilize it
Is this diagnostics problem specific to this feature gate? I meant a more general fix to const-fn related gates.
Not sure. I thought we're using the normal feature gate infra
Reopening this to make sure we add a test per


Question: fn collect_bang_proc_macro(&mut self, item: &'a ast::Item) { if self.in_root && item.vis.node.is_pub() { <del> self.bang_macros.push(ProcMacroDef { </del> <ins> self.macros.push(ProcMacro::Def(ProcMacroDef { </ins> span: item.span, function_name: item.ident, <del> }); </del> <ins> def_type: ProcMacroDefType::Bang })); </ins> } else { let msg = if !self.in_root { "functions tagged with `#[proc_macro]` must

The PR improved the situation about documenting proc macros. Thanks for that! However, I noticed a bug with it. I'm using . Running results in this: ! Looks like a simple typo or off-by-one or something like that bug. When using only and not s, everything looks good to me. CC
Oh, and also, running prints: Not sure if this warning is expected there. And not sure if related to this bug.
This is a consequence of the fact that has not yet been merged. Once it gets merged, and rust updates its Cargo submodule, this issue should go away.
It turns out that this issue was unrelated. I've opened a PR to fix it.
I see. Thanks for your work on this :)


Question: <ins> // check-pass #![feature(allocator_api)] fn main() { Box::new_in((), &std::alloc::Global); } </ins>

While working on , I've run into the following ICE. On further consideration, the issue also appears with as long as is non zero sized. This ICE was likely not encountered during testing of because in the case of , is zero sized. In the example below, removing the borrow of will cause the compilation to succeed. could you take a look at this? :) cc you may run into this as well on <!-- 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<pFrom playground </p</details
This ice is still showing up in . We are using it over in in embedded programming to allocate from heaps located on externally mounted sdram.
Vec is not affected by this, and can even be used to get a Box. This code did not ICE on playground.
Interestingly, trying to print the Box created in that way gives the same ICE as
Hello, I get this error in two flavor: By ref: Produce the following: Without ref: Cause: Where does implement both and traits.
I'm hitting this issue too, on code that basically equates to this: Seems like there are plenty of ways to reproduce this in here, but if a minimal test case is needed, I would be happy to try to provide one. I just made a repro, wasn't really that tricky.
As far as I understand it, the issue is as follows: std is special cased, it has the attribute This corresponds to , which returns true if the type as been annotated to be a Somewhere, some code which uses makes an assumption that such a box data type only contains one field, the inner pointer itself. This causes the allocator struct field to be removed. This breaks when there is a non ZST allocator field that needs to be accessed in generated code. I'm guessing this might be related to the special deref move semantics for boxes?


Question: <ins> // check-pass #![feature(allocator_api)] fn main() { Box::new_in((), &std::alloc::Global); } </ins>

Is the case where the compiler should call for the for the box in the case where a deref move is performed even handled correctly as is today?
It seems that is the one that developed the feature, in He had been warned of the incomming issue, , and opt for a "workaround", can you give us more information about the problem you , the workaround you choose, any hint for why it isn't working, and maybe give us possible path to explore ?


Question: = help: add #![feature(generic_associated_types)] to the crate attributes to enable error[E0658]: generic associated types are unstable (see issue #44265) <del> --> $DIR/feature-gate-generic_associated_types.rs:24:5 </del> <ins> --> $DIR/feature-gate-generic_associated_types.rs:25:5 </ins> | LL |     type Pointer2<u32> = Box<u32>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable <del> error: aborting due to 4 previous errors </del> <ins> error[E0658]: where clauses on associated types are unstable (see issue #44265) --> $DIR/feature-gate-generic_associated_types.rs:30:5 | LL |     type Assoc where Self: Sized; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(generic_associated_types)] to the crate attributes to enable error: aborting due to 6 previous errors </ins> For more information about this error, try `rustc --explain E0658`.

clauses on associated types don't work yet so should be feature gated, presumably with . cc . Happens on versions = 1.24


Question: (cfg, _) => cfg.as_deref().cloned(), }; <del> debug!("Portability {:?} - {:?} = {:?}", item.cfg, parent.cfg, cfg); </del> <ins> debug!("Portability name={:?} {:?} - {:?} = {:?}", item.name, item.cfg, parent.cfg, cfg); </ins> if let Some(ref cfg) = cfg { tags += &tag_html("portability", &cfg.render_long_plain(), &cfg.render_short_html()); }

From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.


Question: (cfg, _) => cfg.as_deref().cloned(), }; <del> debug!("Portability {:?} - {:?} = {:?}", item.cfg, parent.cfg, cfg); </del> <ins> debug!("Portability name={:?} {:?} - {:?} = {:?}", item.name, item.cfg, parent.cfg, cfg); </ins> if let Some(ref cfg) = cfg { tags += &tag_html("portability", &cfg.render_long_plain(), &cfg.render_short_html()); }

Thanks for the suggestion - I moved before and (I've never built rustc/rustdoc from source, pleasantly surprised that only took just under 7min on a ThreadRipper :partyingface:) but it doesn't change anything to the generated output unfortunately :(
I observe this on public items as well: Does not show the badge at re-exports.
So from the following code: is stripped and then inlined. The stripped version contains all the correct information but the inlined one doesn't. Checking what's the best course here: either cloning the stripped item or propagating when inlining.


Question: 14 | } | - immutable borrow ends here <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins>

Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?


Question: --> $DIR/privacy-struct-ctor.rs:20:9 | LL |         Z; <del> |         ^ constructor is not visible here due to private fields help: a tuple struct with a similar name exists | LL |         S; </del> |         ^ <del> help: possible better candidate is found in another module, you can import it into scope | LL |     use m::n::Z; | </del> <ins> |         | |         constructor is not visible here due to private fields |         help: a tuple struct with a similar name exists: `S` </ins> error[E0423]: expected value, found struct `S` --> $DIR/privacy-struct-ctor.rs:33:5 | LL |     S; |     ^ constructor is not visible here due to private fields <del> help: possible better candidate is found in another module, you can import it into scope | LL | use m::S; | </del> error[E0423]: expected value, found struct `S2` --> $DIR/privacy-struct-ctor.rs:38:5


Question: <ins> fn main() { // There shall be no suggestions here. In particular not `Ok`. let _ = 读文; //~ ERROR cannot find value `读文` in this scope } </ins>

In I noticed this surprising spelling suggestion: To me and don't seem like they would be similar enough to meet the threshold for showing such a suggestion. Can we calibrate this better for short idents? For comparison, even doesn't assume you mean . rustc 1.45.0-nightly ( 2020-05-23) Mentioning who worked on suggestions most recently in .
I debugged it a bit. is selected as the candidate because the edit distance is just 2 to . The code to fix is likely in or around . I tried some quick tricks but got ICEs and failing tests and gave up. One thing I didn't try that could perhaps work is to consider edit distance between characters of different alphabets/logogram sets as infinite, rather than 1, which is the case right now.
Thank you for investigating! Independent of what we do with different logogram sets (your suggestion sounds plausible), an edit distance of 2 for a string of length 2 should not meet the threshold for showing a suggestion, even within a single logogram set.
I think edit distance of 1 for a string of length 1 is reasonable (a lot of existing UI tests relies on it), but maybe an edit distance of 2 for a string of length 2 is not reasonable indeed. As you point out, with regular chars, the edit distance is still 2 but is not suggested. So maybe there is a simpler fix to be made for than looking at what alphabets/logogram sets characters belong to.


Question: /// You can also use `dbg!()` without a value to just print the /// file and line whenever it's reached. /// <ins> /// Finally, if you want to `dbg!(..)` multiple values, it will treat them as /// a tuple (and return it, too): /// /// ``` /// assert_eq!(dbg!(1usize, 2u32), (1, 2)); /// ``` /// /// However, a single argument with a trailing comma will still not be treated /// as a tuple, following the convention of ignoring trailing commas in macro /// invocations. You can use a 1-tuple directly if you need one: /// /// ``` /// assert_eq!(1, dbg!(1u32,)); // trailing comma ignored /// assert_eq!((1,), dbg!((1u32,))); // 1-tuple /// ``` /// </ins> /// [stderr]: https://en.wikipedia.org/wiki/Standard_streams#Standard_error_(stderr) /// [`debug!`]: https://docs.rs/log/*/log/macro.debug.html /// [`log`]: https://crates.io/crates/log

It would be nice if the compiler suggested the intended form: as this seems like a reasonable mistake. This is specific to a particular macro, though, so I'm not sure how flexible we can be with diagnostics here.
Or we could just make the macro accept ...


Question: --set target.i686-unknown-linux-gnu.linker=clang  --build=i686-unknown-linux-gnu  --set llvm.ninja=false  <del> --set llvm.use-linker=lld  --set rust.use-lld=true  </del> --set rust.jemalloc <del> ENV SCRIPT python3 ../x.py dist --build $HOSTS --host $HOSTS --target $HOSTS </del> <ins> ENV SCRIPT python2.7 ../x.py dist --build $HOSTS --host $HOSTS --target $HOSTS </ins> ENV CARGO_TARGET_I686_UNKNOWN_LINUX_GNU_LINKER=clang # This was added when we switched from gcc to clang. It's not clear why this is

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


Question: --set target.i686-unknown-linux-gnu.linker=clang  --build=i686-unknown-linux-gnu  --set llvm.ninja=false  <del> --set llvm.use-linker=lld  --set rust.use-lld=true  </del> --set rust.jemalloc <del> ENV SCRIPT python3 ../x.py dist --build $HOSTS --host $HOSTS --target $HOSTS </del> <ins> ENV SCRIPT python2.7 ../x.py dist --build $HOSTS --host $HOSTS --target $HOSTS </ins> ENV CARGO_TARGET_I686_UNKNOWN_LINUX_GNU_LINKER=clang # This was added when we switched from gcc to clang. It's not clear why this is

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


Question: <ins> // edition: 2021 // https://github.com/rust-lang/rust/pull/111761#issuecomment-1557777314 macro_rules! m { () => { extern crate core as std; //~^ ERROR macro-expanded `extern crate` items cannot shadow names passed with `--extern` } } m!(); use std::mem; 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +S-bug-has-mcve
I'm having trouble understanding this ICE. Could someone point me in the right direction? Thanks for your help!
release-assignment I'm finding this quite hard. For anyone else: I suspect is responsible.


Question: } #[derive(Diagnostic)] <ins> #[diag(passes_lang_item_fn_with_target_feature)] pub struct LangItemWithTargetFeature { #[primary_span] pub attr_span: Span, pub name: Symbol, #[label] pub sig_span: Span, } #[derive(Diagnostic)] </ins> #[diag(passes_lang_item_on_incorrect_target, code = "E0718")] pub struct LangItemOnIncorrectTarget { #[primary_span]

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


Question: #![feature(exhaustive_patterns)] #![feature(extend_one)] #![feature(external_doc)] <del> #![feature(fmt_as_str)] </del> #![feature(fn_traits)] #![feature(format_args_nl)] #![feature(gen_future)]

Tracking issue for (), gated by .
I don't quite understand fmt internals, but Make fmt::Arguments::asstr() return a 'static str. seems unnecessarily restrictive. And it breaks which depends on hidden apis e.g. Arguments::newv1
cannot be generated at runtime because it cannot safely be done. So returns makes sense.
I'd like to be able to use this in the log crate to correctly implement a codegen optimization that doesn't really work otherwise: fcp 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] [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.
This SGTM. One question though. Are we sure that the bound will always be correct here?
is the result from parsing a formatting string at compile time. In the future, this might not always be a literal but might be a too. But a non-static/constant format string will be a very different beast.
That's what I figured, but wanted to make sure it was explicitly addressed.
:bell: This is now entering its final comment period, as per the . :bell:
Does this make any guarantees about when is returned? I've been interested in redoing the macro to be much more intelligent (and thus performant), but obviously don't know when it's possible to return something statically knowable.
Currently it returns Some for only. But my plan is to extend that also to , , and possibly also things like , etc. See
Yeah, I see that from looking at the source code. I was more inquiring about whether it would be considered breaking to go from returning to returning . I don't suspect anything would be out-of-reach when reimplementing the macro, but you never know.
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.


Question: #![feature(exhaustive_patterns)] #![feature(extend_one)] #![feature(external_doc)] <del> #![feature(fmt_as_str)] </del> #![feature(fn_traits)] #![feature(format_args_nl)] #![feature(gen_future)]

I think you'd generally want to use it as an optimization only, but we can probably guarantee that it will return Some for certain cases in particular (e.g. ).
This function seems particularly bad for compressed formatting strings and breaks the otherwise clean abstraction.


Question: mod foo { enum Bar { <del> Baz { a: isize } </del> <ins> Baz { a: isize }, </ins> } } <del> fn f(b: foo::Bar) { //~ ERROR enum `Bar` is private </del> <ins> fn f(b: foo::Bar) { //~^ ERROR enum `Bar` is private </ins> match b { foo::Bar::Baz { a: _a } => {} //~ ERROR enum `Bar` is private }

<!-- 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
Seems to be the indicated function:
.
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Oh this is ugly x) Reading the PR, the problem is that there are two ways to match a Box: via a box-pattern or via . But we can't know which will be used based on the type only. Current code assumes box-patterns, hence the error. The PR works because luckily all the fields of are private. If you tried pattern-matching within the module that defines , you'd get crazy results like (actually wouldn't even typecheck): We'll need to figure out a real solution when we implement generalized Deref patterns...
in that case we should open a new ticket for that work, tagged something like or something.


Question: pub(crate) const PASSES: &[Pass] = &[ CHECK_CUSTOM_CODE_CLASSES, CHECK_DOC_TEST_VISIBILITY, <ins> STRIP_ALIASED_NON_LOCAL, </ins> STRIP_HIDDEN, STRIP_PRIVATE, STRIP_PRIV_IMPORTS,

I tried this code: with and . I expected to see this happen: No internal fields of the should be displayed as users won't be able to use the fields, making their appearance confusing and useless. Instead, this happened: The internal fields of the are displayed ! Real impact as can be seen . : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
labels +T-rustdoc +A-rustdoc-ui -needs-triage claim
Dupe of and more discussion there


Question: pub(crate) const PASSES: &[Pass] = &[ CHECK_CUSTOM_CODE_CLASSES, CHECK_DOC_TEST_VISIBILITY, <ins> STRIP_ALIASED_NON_LOCAL, </ins> STRIP_HIDDEN, STRIP_PRIVATE, STRIP_PRIV_IMPORTS,

Using to document private types of the current workspace exposes external types private implementation details (in this case private fields). I would expect the expansion to limit itself to public fields. e.g. gives ! <details<summary<coderustc --version --verbose</code</summary<p</p</detailsr?
I suppose it's "ok" since you used the option. I'll add it to the next rustdoc team meeting agenda to be confirmed by the team.
Rendered output for anyone wondering: !
I'll summarize the exchange I had with Guillaume on matrix. First, the flag I'm talking about is the one you provide to . does not blindly pass the flag to but only for crates you own in your current workspace. That means that when documenting your workspace with . Private items, fields of your crates are shown contrary to your dependencies. Regarding design, it seems weird to me that aliased type expansion shows private implementation details of dependencies (e.g. for the given example). I would personally expect something like:


Question: <ins> error[E0425]: cannot find value `missing` in this scope --> $DIR/tainted-body-2.rs:9:5 | LL |     missing; |     ^^^^^^^ not found in this scope error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0425`. </ins>

<!-- ICE: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: impossible case reached', 'error: internal compiler error: impossible case reached' 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: [coroutinebymovebodydefid] looking up the coroutine by-move body for [analysis] running analysis passes on this crate -- label +F-asyncclosure
As a step of reducing your code examples, could you please ensure that is necessary to reproduce this ICE before mentioning it in the issue? This ICE reproduces on edition 2021, which is the current stable edition.
My project fails on nightly also while using edition 2021.
Yep, a fix is already up and it's waiting for approval. I recommend downgrading to a slightly older nightly until this is fixed.


Question: pub fn emit_feature_warn(diag: &SpanHandler, feature: &str, span: Span, explain: &str) { diag.span_warn(span, explain); <ins> // #23973: do not suggest `#![feature(...)]` if we are in beta/stable if option_env!("CFG_DISABLE_UNSTABLE_FEATURES").is_some() { return; } </ins> if diag.handler.can_emit_warnings { diag.fileline_help(span, &format!("add #![feature({})] to the  crate attributes to silence this warning",

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: pub fn emit_feature_warn(diag: &SpanHandler, feature: &str, span: Span, explain: &str) { diag.span_warn(span, explain); <ins> // #23973: do not suggest `#![feature(...)]` if we are in beta/stable if option_env!("CFG_DISABLE_UNSTABLE_FEATURES").is_some() { return; } </ins> if diag.handler.can_emit_warnings { diag.fileline_help(span, &format!("add #![feature({})] to the  crate attributes to silence this warning",

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: #[link_args = "aFdEfSeVEEE"] extern {} //~^ ERROR the `link_args` attribute is not portable across platforms <del> //~| HELP add #![feature(link_args)] to the crate attributes to enable </del> fn main() { }


Question: #[link_args = "aFdEfSeVEEE"] extern {} //~^ ERROR the `link_args` attribute is not portable across platforms <del> //~| HELP add #![feature(link_args)] to the crate attributes to enable </del> fn main() { }


Question: #[derive(SessionDiagnostic)] #[diag(driver::rlink_no_a_file)] pub(crate) struct RlinkNotAFile; <ins> #[derive(SessionDiagnostic)] #[diag(driver::unpretty_dump_fail)] pub(crate) struct UnprettyDumpFail { pub path: String, pub err: String, } </ins>

If you , you get a normal error like but if you try to at the same time: rust will panic which is a bit weird. Mayne that panic should be demoted to a regular error? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To reproduce: `
claim


Question: <ins> // compile-pass // edition:2018 #![feature(arbitrary_self_types, async_await, await_macro)] use std::task::{self, Poll}; use std::future::Future; use std::marker::Unpin; use std::pin::Pin; // This is a regression test for a ICE/unbounded recursion issue relating to async-await. #[derive(Debug)] #[must_use = "futures do nothing unless polled"] pub struct Lazy<F> { f: Option<F> } impl<F> Unpin for Lazy<F> {} pub fn lazy<F, R>(f: F) -> Lazy<F> where F: FnOnce(&mut task::Context) -> R, { Lazy { f: Some(f) } } impl<R, F> Future for Lazy<F> where F: FnOnce(&mut task::Context) -> R, { type Output = R; fn poll(mut self: Pin<&mut Self>, cx: &mut task::Context) -> Poll<R> { Poll::Ready((self.f.take().unwrap())(cx)) } } async fn __receive<WantFn, Fut>(want: WantFn) -> () where Fut: Future<Output = ()>, WantFn: Fn(&Box<Send + 'static>) -> Fut, { await!(lazy(|_| ())); } pub fn basic_spawn_receive() { async { await!(__receive(|_| async { () })) }; } fn main() {} </ins>

(edit: much simpler reproducer at second post) (see edit history for the initial issue text) Potential duplicate of and cc
(edit: updated to nightly from 2018-08-14, as the error message changed) Another simpler reproducer: Backtrace: The backtrace looks quite different though, so I guess a fix for this one should also be checked to fix the first example.
Latest nightly appears to have fixed the ICE, however it's still making unbounded recursion :)
Async-await traige: Marking as blocking pending investigation to understand what is happening.
Alright, so here's what I've worked out so far: I was able to reproduce the ICE from the original code snippet using the compiler version and library versions from when the issue was reported ( was the closest version I could find and I had to use patch to make Cargo download versions of libraries that worked). I was then able to confirm that the reproduction supplied in the next comment also triggered the ICE. I was then able to get rid of the external dependencies (mostly by copying in parts of that version of futures) and still get the ICE - . After that, I upgraded to as mentioned in the next comment and confirmed that the ICE had been fixed and the unbounded recursion was happening with that same test case. Then, I took that test case that was confirmed to have the problem and tried to run it on the latest nightly - I had to make some minor adjustments as the pin module had changed since August, but I couldn't get the recursion error to happen. I'm inclined to say that this has been fixed at some point - .
I've submitted with a regression test for this issue. if you are able to reproduce this failure on a more recent nightly then feel free to re-open or file a new issue.
Sounds good to me, thanks!


Question: { write!(f, "n{}", Indent(n + 4))?; } <ins> let last_input_index = self.inputs.values.len().checked_sub(1); </ins> for (i, input) in self.inputs.values.iter().enumerate() { <del> if i > 0 { match line_wrapping_indent { None => write!(f, ", ")?, Some(n) => write!(f, ",n{}", Indent(n + 4))?, }; } </del> if let Some(selfty) = input.to_self() { match selfty { clean::SelfValue => {

Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


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. #![crate_name = "foo"] //! Dox // @has src/foo/foo.rs.html // @has foo/index.html '//a/@href' '../src/foo/foo.rs.html' pub mod qux; // @has foo/bar/index.html '//a/@href' '../../src/foo/foo.rs.html' pub mod bar { /// Dox // @has foo/bar/baz/index.html '//a/@href' '../../../src/foo/foo.rs.html' pub mod baz { /// Dox // @has foo/bar/baz/fn.baz.html '//a/@href' '../../../src/foo/foo.rs.html' pub fn baz() { } } /// Dox // @has foo/bar/trait.Foobar.html '//a/@href' '../../src/foo/foo.rs.html' pub trait Foobar { fn dummy(&self) { } } // @has foo/bar/struct.Foo.html '//a/@href' '../../src/foo/foo.rs.html' pub struct Foo { x: i32, y: u32 } // @has foo/bar/fn.prawns.html '//a/@href' '../../src/foo/foo.rs.html' pub fn prawns((a, b): (i32, u32), Foo { x, y }: Foo) { } } /// Dox // @has foo/fn.modfn.html '//a/@href' '../src/foo/foo.rs.html' pub fn modfn() { } </ins>

When visiting a page such as or the link src (for the source code) no longer works. Instead a 404 is returned. This seems to have been broken for several days now.
even before this, many but not all were broken. there may be multiple issues with this symptom.
The links link in the form but it seems like the actual source is being placed in a location in the form For example here's a link from the current docs which will 404: But the following will resolve:
Really annoyed by this. :<


Question: <del> //@ known-bug: #118403 #![feature(generic_const_exprs)] pub struct X<const N: usize> {} impl<const Z: usize> X<Z> { pub fn y<'a, U: 'a>(&'a self) -> impl Iterator<Item = impl Iterator<Item = [u8; Z]> + '_> { (0..1).map(move |_| (0..1).map(move |_| loop {})) } } </del>

<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc


Question: <del> //@ known-bug: #118403 #![feature(generic_const_exprs)] pub struct X<const N: usize> {} impl<const Z: usize> X<Z> { pub fn y<'a, U: 'a>(&'a self) -> impl Iterator<Item = impl Iterator<Item = [u8; Z]> + '_> { (0..1).map(move |_| (0..1).map(move |_| loop {})) } } </del>

<!-- 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 a duplicate of
i think so
I wish there were a "close as duplidate" for this. Ah well.
there is actually, if you click the drop down on the close button
Hunh, they mean to include that in "not planned". Strange.
the "duplicate" issue is closed but this is still failing.
Also ive found that even if you do this without nesting the impl trait it still ICE's.
And if you do it succeeds.


Question: <ins> use std::error::Error; use std::fmt; use super::InterpCx; use crate::interpret::{ConstEvalErr, InterpErrorInfo, Machine}; #[derive(Clone, Debug)] pub enum ConstEvalError { NeedsRfc(String), ConstAccessesStatic, } impl<'tcx> Into<InterpErrorInfo<'tcx>> for ConstEvalError { fn into(self) -> InterpErrorInfo<'tcx> { err_unsup!(Unsupported(self.to_string())).into() } } impl fmt::Display for ConstEvalError { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { use self::ConstEvalError::*; match *self { NeedsRfc(ref msg) => { write!(f, ""{}" needs an rfc before being allowed inside constants", msg) } ConstAccessesStatic => write!(f, "constant accesses static"), } } } impl Error for ConstEvalError {} /// Turn an interpreter error into something to report to the user. /// As a side-effect, if RUSTC_CTFE_BACKTRACE is set, this prints the backtrace. /// Should be called only if the error is actually going to to be reported! pub fn error_to_const_error<'mir, 'tcx, M: Machine<'mir, 'tcx>>( ecx: &InterpCx<'mir, 'tcx, M>, mut error: InterpErrorInfo<'tcx>, ) -> ConstEvalErr<'tcx> { error.print_backtrace(); let stacktrace = ecx.generate_stacktrace(None); ConstEvalErr { error: error.kind, stacktrace, span: ecx.tcx.span } } </ins>

Follow-up to agreed to move to . Generally I propose that should not contain code that is only needed by CTFE. We have and in there are they need some very deep access to Miri engine internals, but at least those are separate modules. Also, has grown pretty messy, and it does not seem like the order of definitions in that file follows any principle. We could split the file into two similar to what I did with Miri: for implementing the machine trait and defining everything that is needed during CTFE execution, and for defining the setup functions and all the glue that connects CTFE with the rest of the compiler.


Question: // Recreate the edges in the graph that are still clean. let mut clean_work_products = FxHashSet(); let mut dirty_work_products = FxHashSet(); // incomplete; just used to suppress debug output <ins> let mut extra_edges = vec![]; </ins> for (source, targets) in &edge_map { for target in targets { <del> // If the target is dirty, skip the edge. If this is an edge // that targets a work-product, we can print the blame // information now. if let Some(blame) = dirty_raw_nodes.get(target) { if let DepNode::WorkProduct(ref wp) = *target { if tcx.sess.opts.debugging_opts.incremental_info { if dirty_work_products.insert(wp.clone()) { // It'd be nice to pretty-print these paths better than just // using the `Debug` impls, but wev. println!("incremental: module {:?} is dirty because {:?}  changed or was removed", wp, blame.map_def(|&index| { Some(directory.def_path_string(tcx, index)) }).unwrap()); } } } continue; } // If the source is dirty, the target will be dirty. assert!(!dirty_raw_nodes.contains_key(source)); // Retrace the source -> target edges to def-ids and then // create an edge in the graph. Retracing may yield none if // some of the data happens to have been removed; this ought // to be impossible unless it is dirty, so we can unwrap. let source_node = retraced.map(source).unwrap(); let target_node = retraced.map(target).unwrap(); let _task = tcx.dep_graph.in_task(target_node); tcx.dep_graph.read(source_node); if let DepNode::WorkProduct(ref wp) = *target { clean_work_products.insert(wp.clone()); } </del> <ins> process_edges(tcx, source, target, &edge_map, &directory, &retraced, &dirty_raw_nodes, &mut clean_work_products, &mut dirty_work_products, &mut extra_edges); </ins> } } <ins> // Subtle. Sometimes we have intermediate nodes that we can't recreate in the new graph. // This is pretty unusual but it arises in a scenario like this: // //     Hir(X) -> Foo(Y) -> Bar // // Note that the `Hir(Y)` is not an input to `Foo(Y)` -- this // almost never happens, but can happen in some obscure // scenarios. In that case, if `Y` is removed, then we can't // recreate `Foo(Y)` (the def-id `Y` no longer exists); what we do // then is to push the edge `Hir(X) -> Bar` onto `extra_edges` // (along with any other targets of `Foo(Y)`). We will then add // the edge from `Hir(X)` to `Bar` (or, if `Bar` itself cannot be // recreated, to the targets of `Bar`). while let Some((source, target)) = extra_edges.pop() { process_edges(tcx, source, target, &edge_map, &directory, &retraced, &dirty_raw_nodes, &mut clean_work_products, &mut dirty_work_products, &mut extra_edges); } </ins> // Add in work-products that are still clean, and delete those that are // dirty. reconcile_work_products(tcx, work_products, &clean_work_products);

Today, nightly crashed on me when compiling my code: https://travis- I don't know what part of the code () is causing this and I don't know how to search for it. Compilation locally works correctly, with yesterday's or today's nightly. I'm trying that new feature. I managed to get this version info from travis in another job: I guess that travis log contains all the relevant information, but if not, please tell me what you need to know.
most likely the cause is . Can you remove the target directory and rebuild without it?
That seems to have helped… I to the job specification and now it passes. I didn't know travis keeps the directories intact between builds. The new log is https://travis- But I guess that makes it even harder to find out what is wrong.
Thanks for the bug report. This seems to be a problem with our new dependency graph reduction algorithm introduced in
I believe this was fixed -- can you verify?
I couldn't reproduce it reliably, it only crashed from time to time, so I have no way to explicitly verify it's fixed. But I haven't seen it crash for quite some time now, so I'd say it's probably solved.
OK, thanks! :)


Question: /// # Examples /// /// ``` <ins> /// #![feature(inner_deref)] </ins> /// let x: Result<String, u32> = Ok("hello".to_string()); /// let y: Result<&str, &u32> = Ok("hello"); /// assert_eq!(x.as_deref(), y);

I would expect the following command to run the libcore doc tests: This used to work, but now all it does it build libcore and its test binaries. No tests are actually being run (which I verified by breaking one of them deliberately). any idea what is happening?
I can confirm, doctests are not being run for std. I think a bigger question is, have they ever worked? Cargo will skip doctests whenever is used, which AFAIK is how std is always built/tested.
I am pretty sure that have used this command before and got test failures when I had screwed up. If you want, I can go back to older versions and verify.
I'll try to figure out what's going on. I tried running with and fortunately nothing looks broken. It's also very possible I am missing something, but I edited some doctests with errors, and a bare doesn't fail.
This was wrong, see below. I'll try to put together a fix.
Ouch. Is there a way we can ensure this does not happen again in the future? Looks like our test suite needs a test suite...
It's pretty hard :/ I guess we can add a dummy doc test that writes some "well known" file and we can assert that the file is present -- perhaps do this per-crate.
OK, it wasn't as bad as I originally reported. This regressed via which is only in 1.45 (beta). I have a fix started at This will require various steps: cargo. to beta. cargo on beta. for new beta release. bootstrap on nightly.
Well, but it does mean that currently on CI we do not run doctests, right? does not change this.
Right, I just mean it hasn't been that long (only about a week).


Question: last = match *token { TtToken(sp, MatchNt(ref name, ref frag_spec, _, _)) => { // ii. If T is a simple NT, look ahead to the next token T' in <del> // M. let next_token = match tokens.peek() { // If T' closes a complex NT, replace T' with F Some(&&TtToken(_, CloseDelim(_))) => follow.clone(), Some(&&TtToken(_, ref tok)) => tok.clone(), Some(&&TtSequence(sp, _)) => { cx.span_err(sp, &format!("`${0}:{1}` is followed by a  sequence repetition, which is not  allowed for `{1}` fragments", name.as_str(), frag_spec.as_str()) </del> <ins> // M. If T' is in the set FOLLOW(NT), continue. Else; reject. if can_be_followed_by_any(frag_spec.as_str()) { continue } else { let next_token = match tokens.peek() { // If T' closes a complex NT, replace T' with F Some(&&TtToken(_, CloseDelim(_))) => follow.clone(), Some(&&TtToken(_, ref tok)) => tok.clone(), Some(&&TtSequence(sp, _)) => { // Be conservative around sequences: to be // more specific, we would need to // consider FIRST sets, but also the // possibility that the sequence occurred // zero times (in which case we need to // look at the token that follows the // sequence, which may itself a sequence, // and so on). cx.span_err(sp, &format!("`${0}:{1}` is followed by a  sequence repetition, which is not  allowed for `{1}` fragments", name.as_str(), frag_spec.as_str()) </ins> ); <del> Eof }, // die next iteration Some(&&TtDelimited(_, ref delim)) => delim.close_token(), // else, we're at the end of the macro or sequence None => follow.clone() }; let tok = if let TtToken(_, ref tok) = *token { tok } else { unreachable!() }; // If T' is in the set FOLLOW(NT), continue. Else, reject. match (&next_token, is_in_follow(cx, &next_token, frag_spec.as_str())) { (_, Err(msg)) => { cx.span_err(sp, &msg); continue </del> <ins> Eof }, // die next iteration Some(&&TtDelimited(_, ref delim)) => delim.close_token(), // else, we're at the end of the macro or sequence None => follow.clone() }; let tok = if let TtToken(_, ref tok) = *token { tok } else { unreachable!() }; // If T' is in the set FOLLOW(NT), continue. Else, reject. match (&next_token, is_in_follow(cx, &next_token, frag_spec.as_str())) { (_, Err(msg)) => { cx.span_err(sp, &msg); continue } (&Eof, _) => return Some((sp, tok.clone())), (_, Ok(true)) => continue, (next, Ok(false)) => { cx.span_err(sp, &format!("`${0}:{1}` is followed by `{2}`, which  is not allowed for `{1}` fragments", name.as_str(), frag_spec.as_str(), token_to_string(next))); continue }, </ins> } <del> (&Eof, _) => return Some((sp, tok.clone())), (_, Ok(true)) => continue, (next, Ok(false)) => { cx.span_err(sp, &format!("`${0}:{1}` is followed by `{2}`, which  is not allowed for `{1}` fragments", name.as_str(), frag_spec.as_str(), token_to_string(next))); continue }, </del> } }, TtSequence(sp, ref seq) => {

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: // In theory, any zero-sized value could be borrowed // mutably without consequences. However, only &mut [] // is allowed right now, and only in functions. <del> if self.const_kind == Some(hir::ConstContext::Static(hir::Mutability::Mut)) { // Inside a `static mut`, &mut [...] is also allowed. match ty.kind() { ty::Array(..) | ty::Slice(_) => {} _ => return Err(Unpromotable), } } else if let ty::Array(_, len) = ty.kind() { </del> <ins> if let ty::Array(_, len) = ty.kind() { </ins> // FIXME(eddyb): We only return `Unpromotable` for `&mut []` inside a // const context which seems unnecessary given that this is merely a ZST. match len.try_eval_usize(self.tcx, self.param_env) {

Consider the following code: This should just work. But instead it throws an error: The reason for this is that gets lifetime extended via promotion, so this reference now points to a separate mutable static -- but mutable statics cannot be mutated during CTFE. I see no way to fix this, other than stopping to promote mutable references -- which we should IMO do anyway, they are a very strange and unprincipled special case. Just imagine doing this in a loop, suddenly all these different and mutable allocations share the same address... Cc
Ugh, that's an ancient rule (believe it or not, it's a workaround for not being able to write and have the length be inferred!) and it was never meant to get this far, I guess I didn't think it through properly when adding the "outermost scope" rule, which is the only position where allowing it makes sense. In the current implementation, it should've never been promoted, only allowed, my bad!


Question: unsafe { Self::from_inner(Box::leak(x).into()) } } <del> /// Constructs a new `Arc<T>` using a closure `data_fn` that has access to /// a weak reference to the constructing `Arc<T>`. </del> <ins> /// Constructs a new `Arc<T>` while giving you a `Weak<T>` to the allocation, /// to allow you to construct a `T` which holds a weak pointer to itself. </ins> /// /// Generally, a structure circularly referencing itself, either directly or <del> /// indirectly, should not hold a strong reference to prevent a memory leak. /// In `data_fn`, initialization of `T` can make use of the weak reference /// by cloning and storing it inside `T` for use at a later time. </del> <ins> /// indirectly, should not hold a strong reference to itself to prevent a memory leak. /// Using this function, you get access to the weak pointer during the /// initialization of `T`, before the `Arc<T>` is created, such that you can /// clone and store it inside the `T`. </ins> /// <del> /// Since the new `Arc<T>` is not fully-constructed until /// `Arc<T>::new_cyclic` returns, calling [`upgrade`] on the weak /// reference inside `data_fn` will fail and result in a `None` value. </del> <ins> /// `new_cyclic` first allocates the managed allocation for the `Arc<T>`, /// then calls your closure, giving it a `Weak<T>` to this allocation, /// and only afterwards completes the construction of the `Arc<T>` by placing /// the `T` returned from your closure into the allocation. /// /// Since the new `Arc<T>` is not fully-constructed until `Arc<T>::new_cyclic` /// returns, calling [`upgrade`] on the weak reference inside your closure will /// fail and result in a `None` value. </ins> /// /// # Panics <ins> /// </ins> /// If `data_fn` panics, the panic is propagated to the caller, and the /// temporary [`Weak<T>`] is dropped normally. /// /// # Example <ins> /// </ins> /// ``` /// #![allow(dead_code)] /// use std::sync::{Arc, Weak};

As I in the i.r-l.o prerelease thread, the documentation of the new(ly stabilized) and method could really use some elaboration before the 1.60 release. I'm quite familiar with refcounting, strong/weak refs, etc. but just from the doc, I have no idea what problem the new method solves exactly, when I should use it, why the closure is needed, how the closure argument seems to come from "thin air", and what the closure should return.
Argh, thanks. Could've sworn I specifically double-checked that I wrote "cyclic"…
Problem the method solves: constructing a which holds a pointer to itself. When you should use it: when you need to do the above. Previously you'd construct with e.g. and then mutate the value (via e.g. ) to fix up the self references. Where the closure argument comes from: essentially, the point of is that the place is allocated first, with strong=0, weak=1. The place has no data yet (you're constructing the value to place there), but is in the "zombie" state where it has weak references but no data. Why the closure is needed: the place needs to be "finished" once the value is created. In theory, you could "recover" any zombie weak, but for the most case, Rust wants to pretend that a "zombie" and a dangling are equivalent. What the closure should return: the closure returns the object to place in the reference counted place. After you've constructed the object, the reference count is "activated" and the object is accessable by (clones of) the weak pointer given to the constructor closure. For the most part, exists to construct style objects more easily, which is what the example demonstrates. It can be used for other use cases, but this is the primary motivating example. I'm biased because I know what is used for, so the existing documentation is enough. The docs aren't going to be changed for 1.60, but if you (or anyone) can improve the docs (with the above information or otherwise), PRs to do so are welcome!
I agree I had to read the documentation a few times to understand what this does.
Hi!


Question: unsafe { Self::from_inner(Box::leak(x).into()) } } <del> /// Constructs a new `Arc<T>` using a closure `data_fn` that has access to /// a weak reference to the constructing `Arc<T>`. </del> <ins> /// Constructs a new `Arc<T>` while giving you a `Weak<T>` to the allocation, /// to allow you to construct a `T` which holds a weak pointer to itself. </ins> /// /// Generally, a structure circularly referencing itself, either directly or <del> /// indirectly, should not hold a strong reference to prevent a memory leak. /// In `data_fn`, initialization of `T` can make use of the weak reference /// by cloning and storing it inside `T` for use at a later time. </del> <ins> /// indirectly, should not hold a strong reference to itself to prevent a memory leak. /// Using this function, you get access to the weak pointer during the /// initialization of `T`, before the `Arc<T>` is created, such that you can /// clone and store it inside the `T`. </ins> /// <del> /// Since the new `Arc<T>` is not fully-constructed until /// `Arc<T>::new_cyclic` returns, calling [`upgrade`] on the weak /// reference inside `data_fn` will fail and result in a `None` value. </del> <ins> /// `new_cyclic` first allocates the managed allocation for the `Arc<T>`, /// then calls your closure, giving it a `Weak<T>` to this allocation, /// and only afterwards completes the construction of the `Arc<T>` by placing /// the `T` returned from your closure into the allocation. /// /// Since the new `Arc<T>` is not fully-constructed until `Arc<T>::new_cyclic` /// returns, calling [`upgrade`] on the weak reference inside your closure will /// fail and result in a `None` value. </ins> /// /// # Panics <ins> /// </ins> /// If `data_fn` panics, the panic is propagated to the caller, and the /// temporary [`Weak<T>`] is dropped normally. /// /// # Example <ins> /// </ins> /// ``` /// #![allow(dead_code)] /// use std::sync::{Arc, Weak};

Just a quick note that changing the documentation for the Rust 1.60.0 release itself will likely not be possible, that'd require a full release rebuild.
I'm sending a PR with explanations provided by so that it'll at least be in the next release. Why do you need a full release rebuild btw? Isn't it possible to regen the docs without rebuilding everything like the option on rustc?
I opened Feedback is very welcome. :)
Our release tooling only supports building everything at the same time.
Well, at least it'll be present in the next release with a beta backport.


Question: <ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:derive-two-attrs.rs #![feature(use_extern_macros)] extern crate derive_two_attrs as foo; use foo::A; #[derive(A)] #[b] #[b] struct B; fn main() {} </ins>

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: <ins> error[E0308]: mismatched types --> $DIR/issue-90213-expected-boxfuture-self-ice.rs:9:19 | LL |         Self::foo(None) |                   ^^^^ expected struct `Box`, found enum `Option` | = note: expected struct `Box<Option<S>>` found enum `Option<_>` = note: for more on the distinction between the stack and the heap, read https://doc.rust-lang.org/book/ch15-01-box.html, https://doc.rust-lang.org/rust-by-example/std/box.html, and https://doc.rust-lang.org/std/boxed/index.html help: store this in the heap by calling `Box::new` | LL |         Self::foo(Box::new(None)) |                   +++++++++    + error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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. -- On stable the code produces the following error as expected: <details<summary<strongExpected result</strong</summary<p</p</details<!-- 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</detailssearched nightlies: from nightly-2021-10-04 to nightly-2021-10-23 regressed nightly: nightly-2021-10-16 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Also ICEs on beta. label regression-from-stable-to-beta
Interesting, this is rustc now, right? There has been as similar rustdoc ice:
Yes, this can be hit with or for example. I tried running the code in , but it seems to have been fixed by now.
claim I'll try to take a look at this.