| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rename `cfg_match!` to `cfg_select!`
[`@Nemo157` pointed out](https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605) that `cfg_match!` syntax does not actually align well with match syntax, which is a possible source of confusion. The comment points out that usage is instead more similar to ecosystem `select!` macros. Rename `cfg_match!` to `cfg_select!` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/115585
[1]: https://github.com/rust-lang/rust/issues/115585#issuecomment-2346307605
|
|
Rollup of 8 pull requests
Successful merges:
- #140526 (docs: Specify that common sort functions sort in an ascending direction)
- #141230 (std: fix doctest and explain for `as_slices` and `as_mut_slices` in `VecDeque`)
- #141341 (limit impls of `VaArgSafe` to just types that are actually safe)
- #141347 (incorrectly prefer builtin `dyn` impls :3)
- #141351 (Move -Zcrate-attr injection to just after crate root parsing)
- #141356 (lower bodies' params to thir before the body's value)
- #141357 (`unpretty=thir-tree`: don't require the final expr to be the body's value)
- #141363 (Document why we allow escaping bound vars in LTA norm)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Document why we allow escaping bound vars in LTA norm
r? lcnr
followup from the const normalization PR. I think I now understand why free alias norm is funny about binders
|
|
r=compiler-errors
`unpretty=thir-tree`: don't require the final expr to be the body's value
Two motivations for this:
- I couldn't find a comment motivating this hard-coding. I can imagine it might be easier to read `unpretty=thir-flat` output if the final expression in the THIR is always the body's value, but if that's the reason, that should be the justification in the source. I can also imagine it's meant to check that all expressions will be visited by the pretty-printer, but the existing check doesn't quite do that either.
- Guard patterns (#129967) contain expressions, so lowering params containing guard patterns may add more expressions to the THIR. Currently a body's params are lowered after its expression, so guard expressions in params would end up last, breaking this. As an alternative, the params could be lowered first (#141356).
|
|
r=compiler-errors
lower bodies' params to thir before the body's value
Two motivations for this:
- Lowering params first means errors from lowering the params are emitted before errors from lowering the body's expression. This comes up in [tests/ui/associated-consts/associated-const-type-parameter-pattern.stderr](https://github.com/rust-lang/rust/compare/master...dianne:rust:thir-lower-params-before-body-expr?expand=1#diff-acac6ea10e991af0da91633e08b2739f9f9ca0c8f826401b6ba829914d0806f2), where both the params and expression encounter errors in translating consts to patterns. This change puts the errors in the order they appear in the source file.
- Guard patterns (#129967) contain expressions, so lowering params containing guard patterns may add more expressions to the THIR. However, there's a check for `-Zunpretty=thir-tree` that the final expression in the THIR corresponds to its value [(link)](https://github.com/rust-lang/rust/blob/c43786c9b7b8d8dcc3f9c604e0e3074c16ed69d3/compiler/rustc_mir_build/src/builder/mod.rs#L453-L455); lowering params last would break this. As an alternative way to get guard patterns to work, I think the pretty-printer could use the expression returned by `thir_body` and the check could be removed or changed (#141357).
|
|
Move -Zcrate-attr injection to just after crate root parsing
This way `after_crate_root_parsing` and `-Zpretty` will see them.
|
|
incorrectly prefer builtin `dyn` impls :3
This makes #57893 slightly more exploitable with the new solver. It's still strictly better than the old solver and the underlying unsoundness persists in the new one even without this preference.
Properly fixing #57893 is something we've been looking at more deeply recently and discussed at the [Types Meetup during the All-Hands](https://hackmd.io/rz-4ghMzTb2wXOkdLKHaHw#Dyn-traits). Whatever approach we'll end up deciding on will likely require a fairly long transition period and some significant further design work. This should not block `-Znext-solver`.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/183
r? `@compiler-errors` cc `@rust-lang/types`
|
|
limit impls of `VaArgSafe` to just types that are actually safe
tracking issue: https://github.com/rust-lang/rust/issues/44930
Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See https://github.com/rust-lang/rust/issues/61275#issuecomment-2193942535 for more detail.
This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB.
r? `@workingjubilee`
|
|
std: fix doctest and explain for `as_slices` and `as_mut_slices` in `VecDeque`
Fixes #141217
r? libs
|
|
docs: Specify that common sort functions sort in an ascending direction
From [forum discussion](https://users.rust-lang.org/t/is-there-a-way-to-sort-a-slice-in-specifically-ascending-or-descending-order/128998?u=natr1x) it seems like the sorting direction can be expected to always be ascending (in terms of `cmp::Ordering`).
If this is the case then it would be nice to have this stated in the documentation.
|
|
Clippy subtree update
Out of cycle sync to fix an ICE that was reported twice already: https://github.com/rust-lang/rust-clippy/issues/14828
r? `@Manishearth`
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #141267 (only resolve top-level guard patterns' guards once)
- #141280 (Use Docker cache from the current repository)
- #141296 (Async drop fix for 'broken mir, place has deref as later projection')
- #141328 (When AsyncDrop impl is empty, sync drop generated in elaborator)
- #141332 (Do not eagerly fold consts in `normalize_param_env_or_error` if new solver)
- #141333 (Use `DeepRejectCtxt` in `assemble_inherent_candidates_from_param`)
- #141334 (eagerly check nested obligations when coercing fndefs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
This way after_crate_root_parsing and -Zpretty will see them.
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
eagerly check nested obligations when coercing fndefs
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/212
r? `@compiler-errors`
|
|
Use `DeepRejectCtxt` in `assemble_inherent_candidates_from_param`
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/214
We were not properly considering unnormalized param-env candidates in `assemble_inherent_candidates_from_param`.
r? lcnr
|
|
Do not eagerly fold consts in `normalize_param_env_or_error` if new solver
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/213
Given:
```
trait Trait: Deref<Target = [u8; { 1 + 1 }]> {}
```
when elaborating param env for `Trait`, we have `Self: Trait`, `Self: Deref<Target = [u8; {anon const}]>`.
Before this PR, we would fold the anon consts away *before* elaborating. However, we end up getting another *un-folded* copy of the anon const from elaborating `Self: Trait`. This leads to normalization ambiguity.
r? lcnr
|
|
r=oli-obk
When AsyncDrop impl is empty, sync drop generated in elaborator
Fixes #140974.
|
|
azhogin:azhogin/async-drop-broken-mir-place-deref-fix, r=oli-obk
Async drop fix for 'broken mir, place has deref as later projection'
fixes #140975
Problem in codegen fixed with an additional temporary local.
|
|
Use Docker cache from the current repository
This is needed to make the cache work after moving CI from the `rust-lang-ci` org to `rust-lang`. Shouldn't be merged until we actually move bors.
Context: https://github.com/rust-lang/infra-team/issues/188
r? `@marcoieni`
|
|
only resolve top-level guard patterns' guards once
We resolve guard patterns' guards in `resolve_pattern_inner`, so to avoid resolving them multiple times, we must avoid doing so earlier. To accomplish this, `LateResolutionVisitor::visit_pat` contains a case for guard patterns that avoids visiting their guards while walking patterns.
This PR fixes #141265, which was due to `visit::walk_pat` being used instead; this meant guards at the top level of a pattern would be visited twice. e.g. it would ICE on `for x if x in [] {}`, but not `for (x if x) in [] {}`. `visit_pat` was already used for the guard pattern in the second example, on account of the top-level pattern being parens.
|
|
8 and 16-bit integers are subject to upcasting in C, and hence are not reliably safe. users should perform their own casting and deal with the consequences
|
|
Match on lang item kind instead of using an if/else chain
Similar to how the new solver does this. Just noticed while I was adding a new entry to the chain 😆
|
|
|
|
clippy-subtree-update
|
|
r? @ghost
Quick out-of cycle sync to fix an ICE that was already reported twice
changelog: none
|
|
|
|
|
|
projection' (#140975)
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #137759 (Add `std::os::unix::process::CommandExt::chroot` to safely chroot a child process)
- #140994 (replace `cc_detect::cc2ar` with `cc::try_get_archiver`)
- #141213 (Suggest use "{}", self.x instead of {self.x} when resolve x as field of `self`)
- #141283 (Allow `x perf` to find rustc.exe on Windows)
- #141284 (Allow trailing comma after argument in query definition)
- #141317 (typeck: catch `continue`s pointing to blocks)
- #141318 (Avoid creating an empty identifer in `Symbol::to_ident_string`.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Avoid creating an empty identifer in `Symbol::to_ident_string`.
Because that causes an assertion failure in debug builds.
Fixes #140884.
r? `@oli-obk`
|
|
typeck: catch `continue`s pointing to blocks
This taints the typeck results with errors if a `continue` is found not pointing to a loop.
A few things were going wrong here. First, since this wasn't caught in typeck, we'd end up building the THIR and then running liveness lints on ill-formed HIR. Since liveness assumes all `continue`s point to loops, it wasn't setting a live node for the `continue`'s destination. There was a fallback for if it couldn't retrieve that live node, but it was faulty; it would create a new live node to represent an erroneous state after the analysis's RWU table had already been built. This would ICE if the new live node was used in operations, such as merging results from the arms of a match. I've removed this error-recovery since it was buggy, and we should really catch bad labels before liveness.
I've also replaced an outdated comment about when liveness lints are run. At this point, I think the call to `check_liveness` could be moved elsewhere, but if it can be run when the typeck results are tainted by errors, it'll need some slight refactoring so it can bail out in that case. In lieu of that, I've added an assert.
Fixes #113379
Fixes #121623
|
|
Allow trailing comma after argument in query definition
Don't catastrophically fail the query macro if you put a comma after your query key!
r? oli-obk
|
|
Allow `x perf` to find rustc.exe on Windows
Related issue: #141281
|
|
Suggest use "{}", self.x instead of {self.x} when resolve x as field of `self`
Fixes #141136
Changes can be seen in the second commit: https://github.com/rust-lang/rust/commit/9de7fff0d8ab72fb57dea6255fc10fe35219db72
r? compiler
|
|
replace `cc_detect::cc2ar` with `cc::try_get_archiver`
~~Awaiting new release of [cc](https://crates.io/crates/cc) version with https://github.com/rust-lang/cc-rs/pull/1456 to bump the version.~~
~~Blocked by https://github.com/rust-lang/cc-rs/pull/1456.~~
Kind a self-explanatory.
try-job: dist-android
|
|
Add `std::os::unix::process::CommandExt::chroot` to safely chroot a child process
This adds a `chroot` method to the `CommandExt` extension trait for the
`Command` builder, to set a directory to chroot into. This will chroot
the child process into that directory right before calling chdir for the
`Command`'s working directory.
To avoid allowing a process to have a working directory outside of the
chroot, if the `Command` does not yet have a working directory set,
`chroot` will set its working directory to "/".
---
ACP: https://github.com/rust-lang/libs-team/issues/551
This PR currently has the tracking issue set to "none"; if the ACP is approved,
I'll file a tracking issue and update the PR.
|
|
|
|
Because that causes an assertion failure in debug builds.
Fixes #140884.
|
|
optimize expression
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #140981 (Add match guard let chain drop order and scoping tests)
- #141042 (ci: split powerpc64le-linux job)
- #141078 (ci: split dist-arm-linux job)
- #141222 (Implement `ptr::try_cast_aligned` and `NonNull::try_cast_aligned`.)
- #141308 (Do not call name() on rpitit assoc_item)
- #141316 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
