| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Update x86_64-linux host compiler to LLVM 19 rc 3
|
|
Rollup of 8 pull requests
Successful merges:
- #129152 (custom/external clippy support for bootstrapping)
- #129311 (don't copy `.rustc-dev-contents` from CI rustc)
- #129800 (Move the Windows remove_dir_all impl into a module and make it more race resistant)
- #129860 (update `object` dependency to remove duplicate `wasmparser`)
- #129885 (chore: remove repetitive words)
- #129913 (Add missing read_buf stub for x86_64-unknown-l4re-uclibc)
- #129916 (process.rs: remove "Basic usage" text where not useful)
- #129917 (Fix parsing of beta version in dry-run mode)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix parsing of beta version in dry-run mode
This was blocking beta release.
r? `@BoxyUwU`
|
|
process.rs: remove "Basic usage" text where not useful
Is not useful because just a single example is given.
|
|
Add missing read_buf stub for x86_64-unknown-l4re-uclibc
Before this PR, `x check library/std --target x86_64-unknown-l4re-uclibc` will fail with
```
error[E0599]: no method named `read_buf` found for struct `Socket` in the current scope
--> std/src/os/unix/net/stream.rs:598:16
|
598 | self.0.read_buf(buf)
| ^^^^^^^^
|
::: std/src/sys/pal/unix/l4re.rs:23:5
|
23 | pub struct Socket(FileDesc);
| ----------------- method `read_buf` not found for this struct
|
= help: items from traits can only be used if the trait is implemented and in scope
```
This target doesn't have a maintainer to cc.
|
|
chore: remove repetitive words
|
|
update `object` dependency to remove duplicate `wasmparser`
``@alexcrichton`` in #129762 you bumped a few wasm-related dependencies and tried to avoid duplicates.
If I understand correctly, `object` 0.36.4 wasn't yet released at the time, and therefore #129762 ended up duplicating `wasmparser`. Now that the release happened, we can remove the duplicate.
r? ``@alexcrichton``
|
|
Move the Windows remove_dir_all impl into a module and make it more race resistant
This attempts to make the Windows implementation of `remove_dir_all` easier to understand and work with by separating out different concerns into their own functions. The code is mostly the same as before just moved around. There are some changes to make it more robust against races (e.g. two calls to `remove_dir_all` running concurrently). The module level comment explains the issue.
try-job: x86_64-msvc
try-job: i686-msvc
|
|
don't copy `.rustc-dev-contents` from CI rustc
Since https://github.com/rust-lang/rust/pull/127188, copying files from `.rustc-dev-contents` regressed https://github.com/rust-lang/rust/issues/108767 again. Since `rustc-src` is already included in the CI rustc sysroot, we don't need to copy these files to have `rustc-src` component.
Blocker for #122709
|
|
custom/external clippy support for bootstrapping
Similar to cargo, rustc, and rustfmt, this adds the support of using custom clippy on bootstrap. It’s designed for those who want to test their own clippy builds or avoid downloading the stage0 clippy.
Closes #121518
|
|
Add `unreachable_pub`, round 4
A follow-up to #129732.
r? `@Urgau`
|
|
Rollup of 12 pull requests
Successful merges:
- #129748 (Box validity: update for new zero-sized rules)
- #129829 (Make decoding non-optional `LazyArray` panic if not set)
- #129856 (compiler_fence documentation: emphasize synchronization, not reordering)
- #129868 (Remove kobzol vacation status)
- #129875 (chore: Fix typos in 'compiler' (batch 1))
- #129877 (chore: Fix typos in 'compiler' (batch 2))
- #129878 (chore: Fix typos in 'compiler' (batch 3))
- #129890 (Remove stray word in a comment)
- #129892 (Clarify language around ptrs in slice::raw)
- #129905 (mailmap: add new email for davidtwco)
- #129906 (mailmapper?)
- #129907 (Fix compile error in solid's remove_dir_all)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Is not useful because just a single example is given.
|
|
Fix compile error in solid's remove_dir_all
Before this PR, `x check library/std --target=aarch64-kmc-solid_asp3` will fail with:
```
error[E0382]: use of partially moved value: `result`
--> std/src/sys/pal/solid/fs.rs:544:20
|
541 | if let Err(err) = result
| --- value partially moved here
...
544 | return result;
| ^^^^^^ value used here after partial move
|
= note: partial move occurs because value has type `io::error::Error`, which does not implement the `Copy` trait
help: borrow this binding in the pattern to avoid moving the value
|
541 | if let Err(ref err) = result
| +++
```
cc `@kawadakk` I think this will clear up https://solid-rs.github.io/toolstate/ :)
|
|
mailmapper?
I think I have done this right? lol
|
|
mailmap: add new email for davidtwco
|
|
Clarify language around ptrs in slice::raw
More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs.
We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold.
Finally we change `data` in the range functions to `start`, which seems like a typo to me.
Touches docs for #89792
r? RalfJung
|
|
Remove stray word in a comment
|
|
chore: Fix typos in 'compiler' (batch 3)
Batch 3/3: Fixes typos in `compiler`
(See [issue](https://github.com/rust-lang/rust/issues/129874) tracking all PRs with typos fixes)
|
|
chore: Fix typos in 'compiler' (batch 2)
Batch 2/3: Fixes typos in `compiler`
(See [issue](https://github.com/rust-lang/rust/issues/129874) tracking all PRs with typos fixes)
|
|
r=compiler-errors,jieyouxu
chore: Fix typos in 'compiler' (batch 1)
Batch 1/3: Fixes typos in `compiler`
(See [issue](https://github.com/rust-lang/rust/issues/129874) tracking all PRs with typos fixes)
|
|
Remove kobzol vacation status
Conflicts with https://github.com/rust-lang/rust/pull/129843, so should be merged after it.
|
|
compiler_fence documentation: emphasize synchronization, not reordering
Our `fence` docs have at some point been update to explain that they are about synchronization, not about "preventing reordering". This updates the `compiler_fence` docs n the same vein, mostly by referring to the `fence` docs.
The old docs make it sound like I can put a compiler_fence in the middle of a bunch of non-atomic operations and that would achieve any kind of guarantee. It does not, atomic operations are still required to do synchronization.
I also slightly tweaked the `fence` docs, to put the synchronization first and the "prevent reordering" second.
Cc `@rust-lang/opsem` `@chorman0773` `@m-ou-se`
Fixes https://github.com/rust-lang/rust/issues/129189
Fixes https://github.com/rust-lang/rust/issues/54962
|
|
Make decoding non-optional `LazyArray` panic if not set
Tables may be [defined](https://github.com/rust-lang/rust/blob/9649706eada1b2c68cf6504356efb058f68ad739/compiler/rustc_metadata/src/rmeta/mod.rs#L377) as `optional:` or `defaulted:`. If optional, if we try to read a value from a key that was never encoded, we should panic. This has high value in ensuring correctness over a defaulted table, so the tradeoff is worth considering, since it signals the compiler has a buggy encode impl, rather than just defaulting to a value.
HOWEVER, `optional:` arrays were side-stepping this. So this PR fixes that, and makes `optional:` tables of `LazyArray` act like `LazyValue`, and panic if it's not assigned a value during encoding.
During this PR, I found that `deduced_param_attrs` has buggy (?? i think??) implementation where it will refuse to encode cross-crate `deduced_param_attrs` unless we're codegening, we're optimizing the library, and incremental is disabled. This seems incredibly wrong, but I don't want to fix it in this PR.
https://github.com/rust-lang/rust/blob/9649706eada1b2c68cf6504356efb058f68ad739/compiler/rustc_metadata/src/rmeta/encoder.rs#L1733-L1747
|
|
Box validity: update for new zero-sized rules
Fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/529
Cc `@joshlf` `@rust-lang/opsem`
|
|
|
|
|
|
|
|
|
|
Signed-off-by: David Wood <david@davidtw.co>
|
|
Use equality when relating formal and expected type in arg checking
#129059 uncovered an interesting issue in argument checking. When we check arguments, we create three sets of types:
* Formals
* Expected
* Actuals
The **actuals** are the types of the argument expressions themselves. The **formals** are the types from the signature that we're checking. The **expected** types are the formal types, but passed through `expected_inputs_for_expected_outputs`:
https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs#L691-L725
This method attempts to constrain the formal inputs by relating the [expectation](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/expectation/enum.Expectation.html) of the call expression and the formal output.
When we check an argument, we get the expression's actual type, and then we first attempt to coerce it to the expected type:
https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs#L280-L293
Then we subtype the expected type and the formal type:
https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs#L299-L305
However, since we are now recording the right coercion target (since #129059), we now end up recording the expected type to the typeck results, rather than the actual.
Since that expected type was [fudged](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.fudge_inference_if_ok), it has fresh variables. And since the expected type is only subtyped against the formal type, if that expected type has a bivariant parameter, it will likely remain unconstrained since `Covariant * Bivariant = Bivariant` according to [xform](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.Variance.html#method.xform). This leads to an unconstrained type variable in writeback.
AFAICT, there's no reason for us to be using subtyping here, though. The expected output is already related to the expectation by subtyping:
https://github.com/rust-lang/rust/blob/a971212545766fdfe0dd68e5d968133f79944a19/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs#L713
So the formals don't need "another" indirection of subtyping in the argument checking... So I've changed it to use equality here. We could alternatively fix this by requiring WF for all the expected types to constrain their bivariant parameters, but this seems a bit overkill.
Fixes #129286
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #127474 (doc: Make block of inline Deref methods foldable)
- #129678 (Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver)
- #129738 (`rustc_mir_transform` cleanups)
- #129793 (add extra linebreaks so rustdoc can identify the first sentence)
- #129804 (Fixed some typos in the standard library documentation/comments)
- #129837 (Actually parse stdout json, instead of using hacky contains logic.)
- #129842 (Fix LLVM ABI NAME for riscv64imac-unknown-nuttx-elf)
- #129843 (Mark myself as on vacation for triagebot)
- #129858 (Replace walk with visit so we dont skip outermost expr kind in def collector)
Failed merges:
- #129777 (Add `unreachable_pub`, round 4)
- #129868 (Remove kobzol vacation status)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Signed-off-by: cuishuang <imcusg@gmail.com>
|
