Suggests compiler to update if on older version when using unstable feature

[Rajveer100]

Part of Issue #117318

Added additional note suggesting compiler update in the .ftl file when calling unstable feature error diagnostic in either case of Some or None.

Potential addition would be to check the system time and compare with the last successful build.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[Rajveer100]

@rustbot +S-waiting-on-review

[Rajveer100]

@lcnr
Let me know your thoughts and suggestions.

[Noratrieb]

This is not quite the right place to put it. It's just about unstable trait items, while the note should be for all unstable features, language features an library. For example, it should show up for let_chains.

Putting it here isn't wrong (though I'm not sure whether it will actually show up, you may need to also mention it in the diagnostics struct), but it just needs more places as well.

When you get hundreds of test failures, you've done it correctly (and then can --bless them).

[lcnr]

r? @Nilstrieb feel free to reassign

[Rajveer100]

@Nilstrieb
I am actually facing this issue which showed up recently (not related to this PR):

dyld[33699]: Library not loaded: @rpath/libunwind.1.dylib
  Referenced from: <E1638B0C-A3EC-382E-AD9A-5AA346E830F0> .../rust-project/rust/build/bootstrap/debug/bootstrap
  Reason: no LC_RPATH's found

I did research across places but didn't seem to have found the solution. This exact issue had also occurred in RustRover IDE (only in debug mode), which I fixed by adding an environment variable this way:

DYLD_LIBRARY_PATH=/usr/local/lib

[Noratrieb]

I have no clue as I don't know much about MacOS. Ask on Zulip instead. Maybe delete your build directory and try again?

[Rajveer100]

I have put a topic on zulip, although haven't received any fix yet. Will try figuring it out in the meantime.

[Rajveer100]

@Nilstrieb
The issue is now resolved! For people who do encounter this in the future, in my case this was caused due to some issues during libc++ trunk installation for llvm, I just deleted all files with lib* in /usr/local/lib and it's fixed. This was due to system searching for libunwind.1.dylib in wrong places instead OS default.

I will do the changes for next review!

[Rajveer100]

Regarding tests, I currently see over 15000+ which I presume isn't intended , do you have any suggestions to which ones I can target locally?

Also, while testing, what do the i and . symbols mean?

[Noratrieb]

Running all 15000 is correct, but only a few of them should fail. i means the test was ignored, . Means it passed

[Rajveer100]

How do I specify the ./x test --bless to use lldb instead of gdb as my system is based on arm architecture and gdb is for x86? (102 tests currently fail)

[Noratrieb]

Uh I think there should be a property in config.toml. alternatively just run x test tests/ui to only test UI tests, that should be enough and doesn't run the annoying debuginfo tests.

[Rajveer100]

While testing, is there an option to specify an older version of rust to test unstable library features which are currently stable? Also, regarding few among them like as you pointed about if let chains, it's a different diagnostic message which does not used parameters like %0 or %1 for generics and also does not have a similar .ftl based file, instead I see a gate_all! macro which I guess acts as a print!.

I presume there would be a lot more as such and they don't have a global callers or trigger to detect them at one place, instead of changing every sort of diagnostic.

[Noratrieb]

You can look through the change log to find things that were stabilized.
I recommend asking questions on Zulip, as there other people can answer faster instead of waiting for me^^

[Rajveer100]

@Nilstrieb
I am closing this PR, @George-lewis has opened a PR for this issue, and I would be more than happy to learn from that, looking through other issues in the meantime.