| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Error on some invalid flag combinations
|
|
guarding just against that
|
|
|
|
strict provenance + native calls
|
|
Implement many-seeds mode directly in the driver
|
|
|
|
|
|
in the same thread
|
|
|
|
|
|
|
|
Provide a way to compare benchmark results with baseline
|
|
|
|
|
|
|
|
remove an unused helper method
|
|
|
|
add more tests for SC access/fence consistency
|
|
Automatic Rustup
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #123604 (Abstract `ProcThreadAttributeList` into its own struct)
- #128780 (Add `--doctest-compilation-args` option to add compilation flags to doctest compilation)
- #133782 (Precedence improvements: closures and jumps)
- #134509 (Arbitrary self types v2: niche deshadowing test)
- #134524 (Arbitrary self types v2: no deshadow pre feature.)
- #134539 (Restrict `#[non_exaustive]` on structs with default field values)
- #134586 (Also lint on option of function pointer comparisons)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Also lint on option of function pointer comparisons
This PR is the first part of #134536, ie. the linting on `Option<{fn ptr}>` in the `unpredictable_function_pointer_comparisons` lint, which isn't part of the lang nomination that the second part is going trough, and so should be able to be approved independently.
Related to https://github.com/rust-lang/rust/issues/134527
r? `@compiler-errors`
|
|
Restrict `#[non_exaustive]` on structs with default field values
Do not allow users to apply `#[non_exaustive]` to a struct when they have also used default field values.
|
|
Arbitrary self types v2: no deshadow pre feature.
The arbitrary self types v2 work introduces a check for shadowed methods, whereby a method in some "outer" smart pointer type may called in preference to a method in the inner referent. This is bad if the outer pointer adds a method later, as it may change behavior, so we ensure we error in this circumstance.
It was intended that this new shadowing detection system only comes into play for users who enable the `arbitrary_self_types` feature (or of course everyone later if it's stabilized). It was believed that the new deshadowing code couldn't be reached without building the custom smart pointers that `arbitrary_self_types` enables, and therefore there was no risk of this code impacting existing users.
However, it turns out that cunning use of `Pin::get_ref` can cause this type of shadowing error to be emitted now. This commit adds a test for this case.
As we want this test to pass without arbitrary_self_types, but fail with it, I've split it into two files (one with run-pass and one without). If there's a better way I can amend it.
Part of #44874
r? ```@wesleywiser```
|
|
Arbitrary self types v2: niche deshadowing test
Arbitrary self types v2 attempts to detect cases where methods in an "outer" type (e.g. a smart pointer) might "shadow" methods in the referent.
There are a couple of cases where the current code makes no attempt to detect such shadowing. Both of these cases only apply if other unstable features are enabled.
Add a test, mostly for illustrative purposes, so we can see the shadowing cases that can occur.
Part of #44874
r? ```@wesleywiser```
|
|
Precedence improvements: closures and jumps
This PR fixes some cases where rustc's pretty printers would redundantly parenthesize expressions that didn't need it.
<table>
<tr><th>Before</th><th>After</th></tr>
<tr><td><code>return (|x: i32| x)</code></td><td><code>return |x: i32| x</code></td></tr>
<tr><td><code>(|| -> &mut () { std::process::abort() }).clone()</code></td><td><code>|| -> &mut () { std::process::abort() }.clone()</code></td></tr>
<tr><td><code>(continue) + 1</code></td><td><code>continue + 1</code></td></tr>
</table>
Tested by `echo "fn main() { let _ = $AFTER; }" | rustc -Zunpretty=expanded /dev/stdin`.
The pretty-printer aims to render the syntax tree as it actually exists in rustc, as faithfully as possible, in Rust syntax. It can insert parentheses where forced by Rust's grammar in order to preserve the meaning of a macro-generated syntax tree, for example in the case of `a * $rhs` where $rhs is `b + c`. But for any expression parsed from source code, without a macro involved, there should never be a reason for inserting additional parentheses not present in the original.
For closures and jumps (return, break, continue, yield, do yeet, become) the unneeded parentheses came from the precedence of some of these expressions being misidentified. In the same order as the table above:
- Jumps and closures are supposed to have equal precedence. The [Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence) says so, and in Syn they do. There is no Rust syntax that would require making a precedence distinction between jumps and closures. But in rustc these were previously 2 distinct levels with the closure being lower, hence the parentheses around a closure inside a jump (but not a jump inside a closure).
- When a closure is written with an explicit return type, the grammar [requires](https://doc.rust-lang.org/1.83.0/reference/expressions/closure-expr.html) that the closure body consists of exactly one block expression, not any other arbitrary expression as usual for closures. Parsing of the closure body does not continue after the block expression. So in `|| { 0 }.clone()` the clone is inside the closure body and applies to `{ 0 }`, whereas in `|| -> _ { 0 }.clone()` the clone is outside and applies to the closure as a whole.
- Continue never needs parentheses. It was previously marked as having the lowest possible precedence but it should have been the highest, next to paths and loops and function calls, not next to jumps.
|
|
Add `--doctest-compilation-args` option to add compilation flags to doctest compilation
Fixes #67533.
Tracking issue: https://github.com/rust-lang/rust/issues/134172
It's been something I meant to take a look at for a long time and actually completely forgot... The idea is to allow to give more control over how doctests are compiled to users. To do so, this PR adds a new `--doctest-compilation-args` option which provides extra compilation flags.
r? `@notriddle`
|
|
r=ChrisDenton
Abstract `ProcThreadAttributeList` into its own struct
As extensively discussed in issue #114854, the current implementation of the unstable `windows_process_extensions_raw_attribute` features lacks support for passing a raw pointer.
This PR wants to explore the opportunity to abstract away the `ProcThreadAttributeList` into its own struct to for one improve safety and usability and secondly make it possible to maybe also use it to spawn new threads.
try-job: x86_64-mingw
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #134556 ([tiny] fix missing ns units in bootstrap's benchmark rendering)
- #134560 (mri: add track_caller to thread spawning methods for better backtraces)
- #134561 (Reduce the amount of explicit FatalError.raise())
- #134562 (tests/codegen/asm: Remove uses of rustc_attrs and lang_items features by using minicore)
- #134567 (Remove some dead code around import library generation)
- #134570 (remove reference to dangling from slice::Iter)
- #134573 (unimplement `PointerLike` for trait objects)
- #134574 (next-solver: disable unnecessary hack)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
next-solver: disable unnecessary hack
the new solver never constrains inference variables to normalizeable aliases, so this is no longer necessary.
|
|
unimplement `PointerLike` for trait objects
Values of type `dyn* PointerLike` or `dyn PointerLike` are not pointer-like so these types should not implement `PointerLike`.
After https://github.com/rust-lang/rust/pull/133226, `PointerLike` allows user implementations, so we can't just mark it with `#[rustc_deny_explicit_impl(implement_via_object = false)]`. Instead, this PR splits the `#[rustc_deny_explicit_impl(implement_via_object = ...)]` attribute into two separate attributes `#[rustc_deny_explicit_impl]` and `#[rustc_do_not_implement_via_object]` so that we opt out of the automatic `impl PointerLike for dyn PointerLike` and still allow user implementations.
For traits that are marked with `#[do_not_implement_via_object]` but not `#[rustc_deny_explicit_impl]` I've also made it possible to add a manual `impl Trait for dyn Trait`. There is no immediate need for this, but it was one line to implement and seems nice to have.
fixes https://github.com/rust-lang/rust/issues/134545
fixes https://github.com/rust-lang/rust/issues/134543
r? `@compiler-errors`
|
|
remove reference to dangling from slice::Iter
This aligns the comment with reality and with IterMut. Also dangling does not seem to take any arguments.
|
|
Remove some dead code around import library generation
This was missed when replacing the usage of LLVM for generating import libraries.
``@bors`` rollup
|
|
tests/codegen/asm: Remove uses of rustc_attrs and lang_items features by using minicore
Similar to https://github.com/rust-lang/rust/pull/134385 (for tests/ui/asm) and https://github.com/rust-lang/rust/pull/134436 (for tests/assembly/asm), but for tests/codegen/asm.
r? jieyouxu
|
|
Reduce the amount of explicit FatalError.raise()
Instead use dcx.abort_if_error() or guar.raise_fatal() instead. These guarantee that an error actually happened previously and thus we don't silently abort.
|
|
mri: add track_caller to thread spawning methods for better backtraces
This is in preparation for https://github.com/rust-lang/miri/pull/4093
|
|
[tiny] fix missing ns units in bootstrap's benchmark rendering
|
|
Revert "Auto merge of #133809 - mrkajetanp:ci-aarch64-dist, r=Kobzol"
This reverts https://github.com/rust-lang/rust/pull/133809, as it produced broken aarch64 artifacts (https://github.com/rust-lang/rust/issues/134563).
`@bors` p=1
|
|
|
|
This aligns the comment with reality and with IterMut. Also dangling does not seem to take any arguments.
|
|
Do not allow users to apply `#[non_exaustive]` to a struct when they have also used default field values.
|
|
|
