jiebi/CodeConvo huggingface dataset:
Code change:
pub fn normal_test_fn() { #[expect(unused_mut, reason = "this expectation will create a diagnostic with the default lint level")] //~^ WARNING this lint expectation is unfulfilled <ins> //~| WARNING this lint expectation is unfulfilled </ins> //~| NOTE this expectation will create a diagnostic with the default lint level <ins> //~| NOTE this expectation will create a diagnostic with the default lint level //~| NOTE duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` </ins> let mut v = vec![1, 1, 2, 3, 5]; v.sort(); // Check that lint lists including `unfulfilled_lint_expectations` are also handled correctly #[expect(unused, unfulfilled_lint_expectations, reason = "the expectation for `unused` should be fulfilled")] //~^ WARNING this lint expectation is unfulfilled <ins> //~| WARNING this lint expectation is unfulfilled //~| NOTE the expectation for `unused` should be fulfilled </ins> //~| NOTE the expectation for `unused` should be fulfilled //~| NOTE the `unfulfilled_lint_expectations` lint can't be expected and will always produce this message <ins> //~| NOTE the `unfulfilled_lint_expectations` lint can't be expected and will always produce this message //~| NOTE duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no` </ins> let value = "I'm unused"; }

Related discussion:
text: are present for more than one HIR node in the and if one node is the (direct or indirect) parent of the other node, then add the level only_ for parent node. This will take care of any lints on the child (since we always walk up the HIR hierachy as mentioned earlier) as well as the parent and it will not cause any warnings about missed expectations. I am new to this area so if someone can review this idea or suggest alternatives that will be great. since you seemed to have worked in this area recently, can you please weigh in?
Your investigation is accurate, and the fix is simple: visit the statement node when building lint levels. Do you mind making such a pr ? I don't think we need any special adjustment for cases, duplicated attributes are already taken into account, but a test won't hurt.
Thanks . Yes, I'll put together a PR. My only concern is if all we do is add the level at , although it will work perfectly for , etc., in the case of we will end up with an unfulfilled expectation on the node which will appear to the user as a warning. But anyway let me have a go and see what happens.
Opened draft PR that adds the lint on . It does suffer from the extra warning problem.
Code change:
} if (*task).unwinder.unwinding { <del> rtabort!("unwinding again"); </del> <ins> // If a task fails while it's already unwinding then we // have limited options. Currently our preference is to // just abort. In the future we may consider resuming // unwinding or otherwise exiting the task cleanly. rterrln!("task failed during unwinding (double-failure - total drag!)") rterrln!("rust must abort now. so sorry."); intrinsics::abort(); </ins> } }

Related discussion:
text: Currently there are no landing pads generated for resource destructors so they are leaky when they fail. We don't have the same tricky situation that C++ has with throwing destructors but I haven't thought through how it should work yet. Edit: This issue has changed into what to do after a dtor fails during unwinding. The previous issue of dtor failure not working at all has been resolved.
There's a failing test in run-fail/unwind-resource-
And another in run-fail/unwind-resource-
The language reference is actually quite explicit about this: "A task may transition to the failing state at any time, due to an un-trapped signal or the evaluation of a fail expression. Once failing, a task unwinds its stack and transitions to the dead state. Unwinding the stack of a task is done by the task itself, on its own control stack. If a value with a destructor is freed during unwinding, the code for the destructor is run, also on the task's control stack. Running the destructor code causes a temporary transition to a running state, and allows the destructor code to cause any subsequent state transitions. The original task of unwinding and failing thereby may suspend temporarily, and may involve (recursive) unwinding of the stack of a failed destructor. Nonetheless, the outermost unwinding activity will continue until the stack is unwound and the task transitions to the dead state. There is no way to “recover” from task failure. Once a task has temporarily suspended its unwinding in the failing state, failure occurring from within this destructor results in hard failure. The unwinding procedure of hard failure frees resources but does not execute destructors. The original (soft) failure is still resumed at the point where it was temporarily suspended. "
Yeah. The hard/soft thing has never been implemented, as far as I know, but I think it's the best we can do: retain correctness of our memory model and try to retain correctness of user code, but not at the cost of infinite-recursion. If their dtor itself fails, just unwind that sub-failure w/o the opportunity for sub-sub-failures.
It would be good to revise the title of this bug to reflect what the task is.
Code change:
} if (*task).unwinder.unwinding { <del> rtabort!("unwinding again"); </del> <ins> // If a task fails while it's already unwinding then we // have limited options. Currently our preference is to // just abort. In the future we may consider resuming // unwinding or otherwise exiting the task cleanly. rterrln!("task failed during unwinding (double-failure - total drag!)") rterrln!("rust must abort now. so sorry."); intrinsics::abort(); </ins> } }

Related discussion:
text: (From the comments thus far, it sounds like the task is to implement the hard/sort failure unwindin protocol; but it might also be useful to clean up the docs here.)
Not critical for 0.6; de-milestoning
confirmed again; current code that can crash is as follows: If my idea for an effect system goes through, we might make this sound again by simply requiring no failure in destructors, e.g. .
nominating for well-defined milestone
there is language about this in the manual already in the task section, so I think it's well defined already. just not implemented. feature completeness issue.
accepted for feature-complete milestone
Triage: the updated version of example still crashes:
0 backcompat
This not only applies to destructors failing while failing, but this appears to also apply to linked failure as well. A program may only contain one statement, but it may still leak due to linked failure. An example of this would be: The destructor for never runs in this program because the call to invokes scheduler business which will realize that it needs to fail due to linked failure. It seems odd to me that if a task only contains one source of failure then we can still leak. This specific use case may not entirely fall under this issue, but it seems fairly serious.
The scheduler does have logic for not failing from linked failure when a task is already failing. So if, for example, the sleeping destructor here were to happen during unwinding, I think it should be fine. But if it happens normally you could still get failure.
I've updated the title to reflect what we're currently talking about. My understanding is that it is just impossible to throw from a landing pad because it will potentially corrupt the unwinder and our three options are: abort - this is what C++ does resume unwinding without completing the landing pad - this is what Ada does and we haven't discussed this option abort the task without completing unwinding - this is "hard" failure we've talked about The "hard" failure is made more difficult by tasks that are not simply green threads. For example, we have use cases where we want to run in a 'task context', on the current thread, and then be told whether the task succeeded or failed, all on the same thread. There's no way in that scenario to just terminate the task cleanly.
Code change:
} if (*task).unwinder.unwinding { <del> rtabort!("unwinding again"); </del> <ins> // If a task fails while it's already unwinding then we // have limited options. Currently our preference is to // just abort. In the future we may consider resuming // unwinding or otherwise exiting the task cleanly. rterrln!("task failed during unwinding (double-failure - total drag!)") rterrln!("rust must abort now. so sorry."); intrinsics::abort(); </ins> } }

Related discussion:
text: My current opinion is that, for 1.0 we should take the most conservative approach and abort. For future versions we should consider trying to do what Ada does and skip a single landing pad, but still proceed to catch the exception.
I agree with double-abort for 1.0. Thinking about the other two schemes in terms of how RWARCs (or whatever they're called these days) behave, aborting just a single task strikes me as risky in terms of unexpected behaviour befalling the user. If a double-failure occurs inside an access to a RWARC, it won't be automatically unlocked during unwinding, and other contending tasks will block forever. I think that resuming the unwinding and skipping the one landing pad still makes sense, though. If double-failure occurs in a user-provided destructor (or in the destructor of some buggy library), skipping the rest of the destructor can only "surprise" other code directly associated with the faulty destructor.
I agree too.
Code change:
// Verify that '>' is not both expected and found at the same time, as it used // to happen in #24780. For example, following should be an error: <del> // expected one of ..., `>`, ... found `>`. No longer exactly this, but keeping for posterity. </del> <ins> // expected one of ..., `>`, ... found `>`. </ins> <del> fn foo() -> Vec<usize>> { //~ ERROR unmatched angle bracket </del> <ins> fn foo() -> Vec<usize>> { //~ ERROR expected one of `!`, `+`, `::`, `;`, `where`, or `{`, found `>` </ins> Vec::new() }

Related discussion:
text: Alternate title: "Rust is literally C++" As of nightly-2020-10-29, rustc fails to parse the following code. The previous nightly and all past stable releases since 1.0.0 are not affected. The relevant commit range is
Mentioning because "Tweak invalid  header and body parsing" sounds extremely relevant.
Assigning and removing as in the prioritization working group.
searched nightlies: from nightly-2020-10-27 to nightly-2020-10-29 regressed nightly: nightly-2020-10-29 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </detailsYeah, seems likely that is the culprit.
Yep, this was me :-/ I'll have a PR up in the next hour.
Code change:
.emit(); } <del> if has_trait_upcasting_coercion && !self.tcx().features().trait_upcasting { feature_err( </del> <ins> if let Some((sub, sup)) = has_trait_upcasting_coercion && !self.tcx().features().trait_upcasting { // Renders better when we erase regions, since they're not really the point here. let (sub, sup) = self.tcx.erase_regions((sub, sup)); let mut err = feature_err( </ins> &self.tcx.sess.parse_sess, sym::trait_upcasting, self.cause.span, <del> "trait upcasting coercion is experimental", ) .emit(); </del> <ins> &format!("cannot cast `{sub}` to `{sup}`, trait upcasting coercion is experimental"), ); err.note(&format!("required when coercing `{source}` into `{target}`")); err.emit(); </ins> } Ok(coercion)

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

Related discussion:
text: Currently (something after 0.5) rustc (IIUIC) is using rpaths to point libs and binaries to the appropriate locations. This is problematic when rustc and the other libs/bins are package e.g. for Fedora. The rpath usage should be made optional - can be used instead - and LDLIBRARYPATH.
Why is this problematic for packaging? Is it because the rpath values end up with the wrong values? Each crate's rpath has several values, one of which is supposed to be the final installation location (controlled with ). Can we just provide more control over which locations are used during rpathing?
In general Fedora recommends to not use rpaths [0], because the paths are hardcoded in the binary. Fedora preferres to point the dynamic linker to the appropriate paths [1]. But yes, we are more flexible about internal libraries - which the case is here. So yes, it would also help us if we could controll the rpath path (which goes a bit into the direction if issue ) [0] [1]
The following rpath is used in e.g. the cargo binary: The rpath referres to rpm's buildroot, where the lib won't stay (it will be instaled to ) Maybe the problem could adressed if the rpath would respect - but this could lead to problems at build time. Maybe LDLIBRARYPATH can be used to point to the correct dir's at build time, and the rpath can be used to point to the correct dir's at runtime. Just my 2ct - but you ar ethe expert :)
Thanks for those links. We do generate rpaths with the expectation that some of them will be invalidated by moving the binaries around. It's possible we could consider removing rpath, but it sure is nice to not think about dynamic loading when running binaries out of my build directory. We could easily add a flag to the configure script, to turn off the rpath for all the rust-provided libraries, with the assumption that package managers would modify during install. If we did that I feel like we would still want the installed rustc to generate rpaths with user-built libraries - otherwise the experience would be different depending on the rust installation. We could also just remove rpath completely - it doesn't work on windows anyway.
Code change:
ifdef TRACE CFG_RUSTC_FLAGS += -Z trace endif <ins> ifdef DISABLE_RPATH # NOTE: make this CFG_RUSTC_FLAGS after stage0 snapshot RUSTFLAGS_STAGE1 += --no-rpath RUSTFLAGS_STAGE2 += --no-rpath RUSTFLAGS_STAGE3 += --no-rpath endif </ins> # The executables crated during this compilation process have no need to include # static copies of libstd and libextra. We also generate dynamic versions of all

Related discussion:
text: Another thing to consider is that, if we just used rustpkg for all builds, and let rustpkg install all libraries at a known location, then we might be able to conveniently not use rpath while still doing the right thing at load time. Can user directories like be put into ?
Yes - I can fully understand how easy running rust in the build directory is when using rpaths :) For the build directory use case it should be possible to create wrappers for rustc and friends which use to point to the correct dirs. You mention thet some libs might reside in , could you explain the overall concept you are following with this? In general I'd expect libraries to appear in /lib, /usr/lib some and some private /usr/lib/myapp. There are also some xdg specs that specify and - but let usfirst see what you say about ~/.rustpkg. Oh, I don't think that ~/.rustpkg would be expanded correctly if put into
Just to summarize my thoughts: If rpath is used, the rpath path beeing used should only use directories below (to point to non-standard dirs containing libs relevant for a rust component). The rpath path should not point to any build-time dir. To include libraries at buildtime or when using the binaries in the build directory I'd suggest using wrappers (isn't autotools doing it like this?) which set appropriately.
Any follow up thoughts?
Our package manager will by default not be installing libraries to a system location and will instead put them in the user's directory, . This doesn't seem out of the ordinary to me; consider cabal, etc. The behavior you recommend requires some deep changes to how Rust works, so need to be considered carefully. Does the current behavior prevent packaging in Fedora, and is there a minimal change we can make to unblock packaging? You'll probably be interested in this subject.
Thanks for the rustpkg explanation. Do I understand that rustpkg will create binaries and libs with rpaths pointing to the user's specific rustpkg dir ? My feeling is that this user specific rpaths should be configurable at build time. The use case is obviously when the binary or lib is going to be installed systemwide. The only rpath exception is the rpath pointing to the system wide package specific libdir (e.g. ).
Code change:
ifdef TRACE CFG_RUSTC_FLAGS += -Z trace endif <ins> ifdef DISABLE_RPATH # NOTE: make this CFG_RUSTC_FLAGS after stage0 snapshot RUSTFLAGS_STAGE1 += --no-rpath RUSTFLAGS_STAGE2 += --no-rpath RUSTFLAGS_STAGE3 += --no-rpath endif </ins> # The executables crated during this compilation process have no need to include # static copies of libstd and libextra. We also generate dynamic versions of all

Related discussion:
text: I think that I'll spend a bit more time with looking at and and might get a better feeling for the problem. Btw.: I noted that the libdir isn't configurabel. Fedora for example keeps x86_64 libs in (/usr)?/lib64, and i686 in (/usr)/lib. IIUIC this is currently not possible with rust as the libs will be installed to /usr/lib/arch-specific-path
The point about libdir is well taken and I updated . I am not entirely sure how rustpkg does it's build now or how and intend for it to work, but based on the current language design I would expect that, yes, binaries installed to would have rpaths pointing there. Currently there are several rpaths configured for each linked library so that they hopefully fall back to something useful when the libraries are moved around during install or during the bootstrapping process, something like: The relative path to the library The absolute path to where the library was at build time The system installation path Under this scheme I would expect that would, when linking against libraries in , create rpaths to .
Yes, there are several rpaths used (seen in and ) and I'd say - even with looking at rust itself, without the packaging glasses on - that it should be configurable what rpaths are used. Maybe it should be an option of . As said, system wide binaries are the best example for binaries where you don't want to many rpaths - including no rpaths pointing to some user dir.
Please don't tag TJC :(
Sorry, TJC! Maybe it's time to give in and start working on Rust :) Seriously though, sorry. I'm sure it's a real PITA.
mentioned that this is a security issue, which I didn't realize. Debian also says .
By the way, it's possible to strip this with but it would be much nicer to not require a third party tool.
I generally wonder why you don't add a user-specific to to point to the user specific rustpkg dir instead of using rpath. That makes it much easier to cope with - and that would also be in par with (at least) the Fedora guidelines. And I suppose with Debian's too, as it's the common way. (See 3rd party java binaries. They modify the to point to some hidden dir in the userdir.)
We used to.
Code change:
ifdef TRACE CFG_RUSTC_FLAGS += -Z trace endif <ins> ifdef DISABLE_RPATH # NOTE: make this CFG_RUSTC_FLAGS after stage0 snapshot RUSTFLAGS_STAGE1 += --no-rpath RUSTFLAGS_STAGE2 += --no-rpath RUSTFLAGS_STAGE3 += --no-rpath endif </ins> # The executables crated during this compilation process have no need to include # static copies of libstd and libextra. We also generate dynamic versions of all

Related discussion:
text: Users kept forgetting and/or getting annoyed having to adjust it when running from a build dir. Rpaths made it possible to run foo/bar/rustc no matter which rustc you chose.
right. IIUIC - I always feel like a noob when it comes to autotools - autotools are generating wrappers for binaries which are created during a build process and moves the original binaries to hiddend irectories. The wrappers are then modifying the environment (setting env vars etc) to achieve the same goal (so e.g. that rustc can be run from the dev directory without messing with the env vars yourself). I wonder if this could help.
Okay, it's actually not autools which creates these wrappers but libtool:
Sorry, I didn't mean to imply a disinterest in fixing this better, just noting how it came to be. Also strongly disinterested in using libtool. Would prefer going back to telling users to set env vars.
How about defaulting to static linking (when it works)? Dynamic linking is valuable, but mostly for global installs handled by a package manager. Of course, if we end up with a bunch of tools using that would be wasteful. I think RPATH will just lead to confusion, and it's an easy security hole to leave open.
I would be very happy to get static linking working well enough to make it a default in many such cases. But we ought to do the right thing when linking dynamically too. Is rpath-using- considered acceptable? I.e. is it just the absolute paths that are problematic?
The absolute paths are the ones that can easily be a security issue, so isn't that bad. I would still rather avoid it for a globally installed package but it's easy enough to strip for people who don't need it and won't be an issue if you don't know about it (like the absolute path could be). Using the rpath could be a flag, but the absolute path should never be there.
Nominating for milestone 2: backwards compatible. (The choice of whether one needs to put a setting in or use some configure flag for certain systems, etc, seems like a backwards compatibility issue. Though maybe I misunderstand and these are issues only for people developing itself, not for clients of ?) It also could well be that this is more appropriately assocated with milestone 1: well-defined.