-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #118602
Rollup of 5 pull requests #118602
Conversation
`DefPathData::(ClosureExpr,ImplTrait)` are renamed to match `DefKind::(Closure,OpaqueTy)`. `DefPathData::ImplTraitAssocTy` is replaced with `DefPathData::TypeNS(kw::Empty)` because both correspond to `DefKind::AssocTy`. It's possible that introducing `(DefKind,DefPathData)::AssocOpaqueTy` could be a better solution, but that would be a much more invasive change. Const generic parameters introduced for effects are moved from `DefPathData::TypeNS` to `DefPathData::ValueNS`, because constants are values. `DefPathData` is no longer passed to `create_def` functions to avoid redundancy.
Now using a window of 3 instead 2 because it removes any confusion about exactly how consecutive windows overlap
…` format strings This commit restricts what symbols can be used in a format string for any option of the `diagnostic::on_unimplemented` attribute. We previously allowed all the ad-hoc options supported by the internal `#[rustc_on_unimplemented]` attribute. For the stable attribute we only want to support generic parameter names and `{Self}` as parameters. For any other parameter an warning is emitted and the parameter is replaced by the literal parameter string, so for example `{integer}` turns into `{integer}`. This follows the general design of attributes in the `#[diagnostic]` attribute namespace, that any syntax "error" is treated as warning and subsequently ignored.
…mented, r=compiler-errors Restrict what symbols can be used in `#[diagnostic::on_unimplemented]` format strings This commit restricts what symbols can be used in a format string for any option of the `diagnostic::on_unimplemented` attribute. We previously allowed all the ad-hoc options supported by the internal `#[rustc_on_unimplemented]` attribute. For the stable attribute we only want to support generic parameter names and `{Self}` as parameters. For any other parameter an warning is emitted and the parameter is replaced by the literal parameter string, so for example `{integer}` turns into `{integer}`. This follows the general design of attributes in the `#[diagnostic]` attribute namespace, that any syntax "error" is treated as warning and subsequently ignored. r? `@compiler-errors`
…TaKO8Ki codegen, miri: fix computing the offset of an unsized field in a packed struct `#[repr(packed)]` strikes again. Fixes rust-lang#118537 Fixes rust-lang/miri#3200 `@bjorn3` I assume cranelift needs the same fix.
…iler-errors more targeted errors when extern types end up in places they should not Cc rust-lang#115709 -- this does not fix that bug but it makes the panics less obscure and makes it more clear that this is a deeper issue than just a little codegen oversight. (In rust-lang#116115 we decided we'd stick to causing ICEs here for now, rather than nicer errors. We can't currently show any errors pre-mono and probably we don't want post-mono checks when this gets stabilized anyway.)
rustc: Harmonize `DefKind` and `DefPathData` Follow up to rust-lang#118188. `DefPathData::(ClosureExpr,ImplTrait)` are renamed to match `DefKind::(Closure,OpaqueTy)`. `DefPathData::ImplTraitAssocTy` is replaced with `DefPathData::TypeNS(kw::Empty)` because both correspond to `DefKind::AssocTy`. It's possible that introducing `(DefKind,DefPathData)::AssocOpaqueTy` instead could be a better solution, but that would be a much more invasive change. Const generic parameters introduced for effects are moved from `DefPathData::TypeNS` to `DefPathData::ValueNS`, because constants are values. `DefPathData` is no longer passed to `create_def` functions to avoid redundancy.
…mple, r=thomcc Improve example in `slice::windows()` doc Fixes rust-lang#118571 Now using a window of 3 instead 2 because it removes any confusion about exactly how consecutive windows overlap
@bors r+ rollup=never p=5 |
🌲 The tree is currently closed for pull requests below priority 10. This pull request will be tested once the tree is reopened. |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 0a83e43f28 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (e281163): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 673.138s -> 674.521s (0.21%) |
Successful merges:
#[diagnostic::on_unimplemented]
format strings #118495 (Restrict what symbols can be used in#[diagnostic::on_unimplemented]
format strings)DefKind
andDefPathData
#118573 (rustc: HarmonizeDefKind
andDefPathData
)slice::windows()
doc #118586 (Improve example inslice::windows()
doc)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup