Rollup of 8 pull requests #95702
Merged
Rollup of 8 pull requests #95702
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use the proc-macro descr to track their individual expansions with self-profiling events. This will help diagnose performance issues with slow proc-macros.
ScmCredentials netbsd implementation.
track individual proc-macro expansions in the self-profiler As described in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Macro.20expansion.20performance.20on.20complex.20macros/near/275063190), users don't currently have a lot of information to diagnose macro expansion performance issues. That comment suggests using the macro names to add further timing information. This PR starts to do this for proc-macros which have the same issue, and performance problems happening in the wild in [this other zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns) could be helped by such information. It uses the available proc-macro name to track their individual expansions with self-profiling events. r? `@Aaron1011` who mentioned this idea originally
…tmcm caution against ptr-to-int transmutes I don't know how strong of a statement we want to make here, but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`. Examples [like this](rust-lang/unsafe-code-guidelines#286 (comment)) show that ptr-to-int transmutes are deeply suspicious -- they are either UB, or they don't round-trip properly, or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed'). Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this. Cc `@rust-lang/lang`
Explain why `&T` is cloned when `T` is not `Clone` Fixes rust-lang#95535
Use revisions to track NLL test output (part 1) The idea here is 2 fold: 1) When we eventually do make NLL default on, that PR should be systematic in "delete revisions and corresponding error annotations" 2) This allows us to look at test NLL outputs in chunks. (Though, I've opted here not to "mark" these tests. There are some tests with NLL revisions *now* that will be missed. I expect we do a second pass once we have all the tests with NLL revisions; these tests should be easy enough to eyeball.) The actual review here should be "easy", but a bit tedious. I expect we should manually go through each test output and confirm it's okay. The majority of these are either: 1) Only span change (the one I see most common is highlighting an entire function call, rather than just the function name in that call) 2) "E0308 mismatched types" -> "lifetime does not live long enough" 3) "E0495 cannot infer an appropriate lifetime for lifetime parameter" -> "lifetime does not live long enough" 4) "E0312 lifetime of reference outlives lifetime of borrowed content" -> "lifetime does not live long enough" 5) "E0759 `XXX` has an anonymous lifetime `'_` but it needs to satisfy a `'static` lifetime requirement" -> "lifetime does not live long enough" 6) "E0623 lifetime mismatch" -> "lifetime does not live long enough" Other than the now lack of an error code, most of these look fine (with most giving more helpful suggestions now). `rfc1623` output isn't great. cc ``@marmeladema`` if you want to look through these Let's r? ``@oli-obk`` since you've commented on the Zulip thread ;)
…re, r=compiler-errors diagnostics: give a special note for unsafe fn / Fn/FnOnce/FnMut Fixes rust-lang#90073
…=lnicola ⬆️ rust-analyzer r? ``@ghost``
resolve: Fix resolution of empty paths passed from rustdoc Fixes rust-lang#95337 (comment)
rustbot
added
T-compiler
|
@bors r+ rollup=never p=5 |
1 similar comment
|
@bors r+ rollup=never p=5 |
|
📌 Commit 728f263 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (bbe9d27): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
&Tis cloned whenTis notClone#95585 (Explain why&Tis cloned whenTis notClone)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup