Rollup of 9 pull requests #108488
Rollup of 9 pull requests #108488
Conversation
The point of these is to be seen lexically in the docs, so they should always be passed as the correct literal, not as an expression. (Otherwise we could just compute `Min`/`Max` from `BITS`, for example.)
This resolves an inconsistency in naming style for functions on the parser, between functions parsing specific kinds of items and those for expressions, favoring the parse_item_[sth] style used by functions for items. There are multiple advantages of that style: * functions of both categories are collected in the same place in the rustdoc output. * it helps with autocompletion, as you can narrow down your search for a function to those about expressions. * it mirrors rust's path syntax where less specific things come first, then it gets more specific, i.e. std::collections::hash_map::Entry The disadvantage is that it doesn't "read like a sentence" any more, but I think the advantages weigh more greatly. This change was mostly application of this command: sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs Plus very minor fixes outside of rustc_parse, and an invocation of x fmt.
This adds both a test specific to rust-lang#108453 as well as an exhaustive test that goes through all possible combinations of head index, length and target capacity for a deque with capacity 16.
It was probably a leftover from the old `?` desugaring but anyways, it's unused now except for clippy, which can just use a diagnostics item.
…or-auto, r=lcnr Treat `str` as containing `[u8]` for auto trait purposes Wanted to gauge ``@rust-lang/lang`` and ``@rust-lang/types`` teams' thoughts on treating `str` as "containing" a `[u8]` slice for auto-trait purposes. ``@dtolnay`` brought this up in rust-lang#13231 (comment) as a blocker for future `str` type librarification, and I think it's both a valid concern and very easy to fix. I'm interested in actually doing that `str` type librarification (rust-lang#107939), but this probably should be considered in the mean time regardless of that PR. r? types for the impl, though this definitely needs an FCP.
Require `literal`s for some `(u)int_impl!` parameters The point of these is to be seen *lexically* in the docs, so they should always be passed as the correct literal, not as an expression. (Otherwise we could just compute `Min`/`Max` from `BITS`, for example.) r? Nilstrieb
…, r=cjgillot hir-analysis: make a helpful note
…ed, r=cjgillot
Add `ErrorGuaranteed` to `hir::{Expr,Ty}Kind::Err` variants
First step in making the `Err` variants of `ExprKind` and `TyKind` require an `ErrorGuaranteed` during parsing. Making the corresponding AST versions require `ErrorGuaranteed` is a bit harder, whereas it was pretty easy to do this for HIR, so let's do that first.
The only weird thing about this PR is that `ErrorGuaranteed` is moved to `rustc_span`. This is *certainly* not the right place to put it, but `rustc_hir` cannot depend on `rustc_error` because the latter already depends on the former. Should I just pull out some of the error machinery from `rustc_error` into an even more minimal crate that `rustc_hir` can depend on? Advice would be appreciated.
…strieb Replace parse_[sth]_expr with parse_expr_[sth] function names This resolves an inconsistency in naming style for functions on the parser, where: * functions parsing specific kinds of items are named `parse_item_[sth]` and * functions parsing specific kinds of *expressions* are named `parse_[sth]_expr` favoring the style used by functions for items. There are multiple advantages of that style: * functions of both categories are collected in the same place in the [rustdoc output](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html). * it helps with autocompletion, as you can narrow down your search for a function to those about expressions. * it mirrors rust's path syntax where less specific things come first, then it gets more specific, i.e. `std::collections::hash_map::Entry`. The disadvantage is that it doesn't "read like a sentence" any more. But I think the advantages weigh more greatly. This change was mostly application of this command: ``` sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs ``` Plus very minor fixes outside of `rustc_parse`, and an invocation of `x fmt`.
…ompiler-errors rustc_infer: Consolidate obligation elaboration de-duplication # Explanation The obligations `Elaborator` is doing de-duplication of obligations in 3 different locations. 1 off which has a comment. This PR consolidates the functionality and comment to a single function.
Fix `VecDeque::shrink_to` and add tests. Fixes rust-lang#108453. Also adds both a specific test with the code from rust-lang#108453 and an exhaustive test that checks all possible head positions, lengths and target capacities for deques with capacity 16. cc `@trinity-1686a` `@scottmcm`
…aumeGomez statically guarantee that current error codes are documented Closes rust-lang#61137 (that's right!) Pretty simple refactor (often just a change from `Result<Option<&str>>` to `Result<&str>`) r? `@GuillaumeGomez` (could you specially look at 5304415? I believe you wrote that in the first place, just want to make sure you're happy with the change)
…as From˂˂LangItemFromFn˃˃˃꞉꞉from, r=cjgillot Remove `from` lang item It was probably a leftover from the old `?` desugaring but anyways, it's unused now except for clippy, which can just use a diagnostics item.
rustbot
added
A-testsuite
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR: previous master: 43ee4d15bf In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (c4e0cd9): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
|
These are doc benchmarks regressions, and nothing obviously rustdoc jumps out. Maybe it's noise but we don't seem to show rustdoc benchmark graphs on perf.rlo. Just for peace of mind, let's see if #108299 is related since it seems to be about doc comments. @rust-timer build 43795ad03b0e98aea2c37fb5869a824d501124f6 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (43795ad03b0e98aea2c37fb5869a824d501124f6): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
|
@rust-timer build 425b8cfc33a2518b3d8107cc31be92ae5ec8a999 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (425b8cfc33a2518b3d8107cc31be92ae5ec8a999): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. |
|
The regression here seems limited in scope. It is unfortunate, but I do not think the 2% regression to building docs for hyper on its own warrants trying to dissect what happened here. I do think we should probably add some way to see graphs of the doc-build time data. I'll go file an issue for that rustc-perf. (Also, it seems bad that the runs on the individual commits are removing the perf-regression label here... -- or ... is that happening? Why don't I see the label modifications that I would expect in response to the rust-timer comment above...?) @rustbot label: +perf-regression +perf-regression-triaged |
rustbot
added
perf-regression
The perf-regression removal happens when a perf run is made and no regressions are detected. That works fine in the normal case, but here when doing perf runs on individual commits within a rollup it can lead to the overall PR being marked as a non-regression simply because a single perf run was non-regressing. Fixing it would probably require teaching rustc-perf to handle individual runs within rollups separately. |
Yes, this is along the lines of what I was thinking |
This now works: #108747 (comment) |
Successful merges:
stras containing[u8]for auto trait purposes #107941 (Treatstras containing[u8]for auto trait purposes)literals for some(u)int_impl!parameters #108299 (Requireliterals for some(u)int_impl!parameters)ErrorGuaranteedtohir::{Expr,Ty}Kind::Errvariants #108379 (AddErrorGuaranteedtohir::{Expr,Ty}Kind::Errvariants)VecDeque::shrink_toand add tests. #108475 (FixVecDeque::shrink_toand add tests.)fromlang item #108484 (Removefromlang item)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup