| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Begin to implement type system layer of unsafe binders
Mostly TODOs, but there's a lot of match arms that are basically just noops so I wanted to split these out before I put up the MIR lowering/projection part of this logic.
r? oli-obk
Tracking:
- https://github.com/rust-lang/rust/issues/130516
|
|
check API.
For Windows, this removes the need to add a breakpoint and modify a value to exit the debugger wait loop.
As a ridealong, this adds a 100ms sleep for all platforms such that waiting for the debugger doesn't hog the CPU thread.
|
|
Rollup of 5 pull requests
Successful merges:
- #134363 (Use `#[derive(Default)]` instead of manual `impl` when possible)
- #134517 (Add tests for coverage attribute on trait functions)
- #134528 (opt-dist: propagate channel info to bootstrap)
- #134669 (Document the `--dev` flag for `src/ci/docker/run.sh`)
- #134680 (Clean up a few rmake tests )
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
in the same thread
|
|
opt-dist: propagate channel info to bootstrap
Fixes #133503.
Previously, `tests/ui/bootstrap/rustc_bootstap.rs` [sic] failed during [beta bump](https://github.com/rust-lang/rust/pull/133447#issuecomment-2501298794) in opt-dist tests. This is because:
- `opt-dist` tried to run `./x test` against beta-channel dist `rustc` through `bootstrap`.
- The dist build produced during the beta bump produces a `rustc` which correctly thinks that it is a beta compiler based on `src/ci/channel` info.
- `opt-dist` tries to run `./x test` on the beta `rustc` from the dist build, but without specifying channel through a synthetic `config.toml`, so `bootstrap` tells `compiletest` that we're on the `nightly` channel (by default).
- Now there's a channel mismatch: `compiletest` believes the `rustc` under test is a *nightly* rustc, but the `rustc` under test actually considers itself a *beta* rustc. This means that `//@ only-nightly` will be satisfied yet the test will fail as the *beta* rustc is not a *nightly* rustc.
This PR:
- Fixes the test failure during beta bump (i.e. #133503) by having `opt-dist` faithfully report the channel of the dist `rustc` being tested (i.e. "beta" in a beta bump PR). This will properly make the test be ignored during beta bump as the `rustc` under test is not a *nightly* rustc.
- Fixes the test name `rustc_bootstap.rs` -> `rustc_bootstrap.rs`. No more stapping.
- Slightly adjusts the doc comment in the test to make it more clear.
I ran a try-job against the beta branch (explicitly running the opt-dist tests by modifying the job definition) with these changes in #134131, and it appears that the try-job was [successful](https://github.com/rust-lang/rust/pull/134131#issuecomment-2555492215). The two commits in this PR are cherry-picked from #134131, with the test commit slightly modified (to also adjust the test comments).
r? `@Kobzol` (or compiler or bootstrap or infra I guess?)
|
|
|
|
|
|
|
|
The Makefile version seems to contain a bug. Over the years, the
directory structure of the `rust-src` component changed as the source
tree directory structure changed. `libstd` is no longer a thing directly
under `root/lib/rustlib/src/rust/src/`, it is moved to
`root/lib/rustlib/src/rust/library/std`.
Co-authored-by: Oneirical <manchot@videotron.ca>
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
|
|
|
|
|
|
Revert stabilization of the `#[coverage(..)]` attribute
Due to a process mixup, the PR to stabilize the `#[coverage(..)]` attribute (#130766) was merged while there are still outstanding concerns. The default action in that situation is to revert, and the feature is not sufficiently urgent or uncontroversial to justify special treatment, so this PR reverts that stabilization.
---
- A key point that came up in offline discussions is that unlike most user-facing features, this one never had a proper RFC, so parts of the normal stabilization process that implicitly rely on an RFC break down in this case.
- As the implementor and de-facto owner of the feature in its current form, I would like to think that I made good choices in designing and implementing it, but I don't feel comfortable proceeding to stabilization without further scrutiny.
- There hasn't been a clear opportunity for T-compiler to weigh in or express concerns prior to stabilization.
- The stabilization PR cites a T-lang FCP that occurred in the tracking issue, but due to the messy design and implementation history (and lack of a clear RFC), it's unclear what that FCP approval actually represents in this case.
- At the very least, we should not proceed without a clear statement from T-lang or the relevant members about the team's stance on this feature, especially in light of the other concerns listed here.
- The existing user-facing documentation doesn't clearly reflect which parts of the feature are stable commitments, and which parts are subject to change. And there doesn't appear to be a clear consensus anywhere about where that line is actually drawn, or whether the chosen boundary is acceptable to the relevant teams and individuals.
- For example, the [stabilization report comment](https://github.com/rust-lang/rust/issues/84605#issuecomment-2166514660) mentions that some aspects are subject to change, but that text isn't consistent with my earlier comments, and there doesn't appear to have been any explicit discussion or approval process.
- [The current reference text](https://github.com/rust-lang/reference/blob/4dfaa4f/src/attributes/coverage-instrumentation.md) doesn't mention this distinction at all, and instead simply describes the current implementation behaviour.
- When the implementation was changed to its current form, the associated user-facing error messages were not updated, so they still refer to the attribute only being allowed on functions and closures.
- On its own, this might have been reasonable to fix-forward in the absence of other concerns, but the fact that it never came up earlier highlights the breakdown in process that has occurred here.
---
Apologies to everyone who was excited for this stabilization to land, but unfortunately it simply isn't ready yet.
|
|
Make sure we don't lose default struct value when formatting struct
The reason why https://github.com/rust-lang/rustfmt/issues/6424 broke when https://github.com/rust-lang/rust/pull/129514 landed is because the parser now *successfully* parses default struct values. That means that where we used to fail in `rewrite_macro_inner`:
https://github.com/rust-lang/rust/blob/e108481f74ff123ad98a63bd107a18d13035b275/src/tools/rustfmt/src/macros.rs#L263-L267
... we now succeed, and we now proceed to format the inner struct as a macro arg. Since formatting was never implemented for default struct values, this means that we’ll always rewrite the struct to exclude the default value.
This PR makes it so that we simply don’t rewrite struct fields if they have a default value.
r? `@ytmimi`
|
|
test-infra: improve compiletest and run-make-support symlink handling
I was trying to implement #134656 to port `tests/run-make/incr-add-rust-src-component.rs`, but found some blockers related to symlink handling, so in this PR I tried to resolve them by improving symlink handling in compiletest and run-make-support (particularly for native windows msvc environment).
Key changes:
- I needed to copy symlinks (duplicate a symlink pointing to the same file), so I pulled out the copy symlink logic and re-exposed it as `run_make_support::rfs::copy_symlink`. This helper correctly accounts for the Windows symlink-to-file vs symlink-to-dir distinction (hereafter "Windows symlinks") when copying symlinks.
- `recursive_remove`:
- I needed a way to remove symlinks themselves (no symlink traversal). `std::fs::remove_dir_all` handles them, but only if the root path is a directory. So I wrapped `std::fs::remove_dir_all` to also handle when the root path is a non-directory entity (e.g. file or symlink). Again, this properly accounts for Windows symlinks.
- I wanted to use this for both compiletest and run-make-support, so I put the implementation and accompanying tests in `build_helper`.
- In this sense, it's a reland of #129302 with proper test coverage.
- It's a thin wrapper around `std::fs::remove_dir_all` (`remove_dir_all` correctly handles read-only entries on Windows). The helper has additional permission-setting logic for when the root path is a non-dir entry on Windows to handle read-only non-dir entry.
Fixes #126334.
|
|
r=wesleywiser"
This reverts commit 1d35638dc38dbfbf1cc2a9823135dfcf3c650169, reversing
changes made to f23a80a4c2fbca593b64e70f5970368824b4c5e9.
|
|
Rollup of 6 pull requests
Successful merges:
- #130289 (docs: Permissions.readonly() also ignores root user special permissions)
- #134583 (docs: `transmute<&mut T, &mut MaybeUninit<T>>` is unsound when exposed to safe code)
- #134611 (Align `{i686,x86_64}-win7-windows-msvc` to their parent targets)
- #134629 (compiletest: Allow using a specific debugger when running debuginfo tests)
- #134642 (Implement `PointerLike` for `isize`, `NonNull`, `Cell`, `UnsafeCell`, and `SyncUnsafeCell`.)
- #134660 (Fix spacing of markdown code block fences in compiler rustdoc)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
an expression
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 15 packages to latest compatible versions
Updating clap_complete v4.5.39 -> v4.5.40
Updating env_filter v0.1.2 -> v0.1.3
Updating env_logger v0.11.5 -> v0.11.6
Updating expect-test v1.5.0 -> v1.5.1
Updating foldhash v0.1.3 -> v0.1.4
Updating miniz_oxide v0.8.1 -> v0.8.2
Updating object v0.36.5 -> v0.36.7
Updating serde_json v1.0.133 -> v1.0.134
Updating thiserror v2.0.7 -> v2.0.9
Updating thiserror-impl v2.0.7 -> v2.0.9
Updating tinyvec v1.8.0 -> v1.8.1
Updating wasm-encoder v0.221.2 -> v0.222.0
Removing wasmparser v0.218.0
Removing wasmparser v0.221.2
Adding wasmparser v0.222.0
Updating wast v221.0.2 -> v222.0.0
Updating wat v1.221.2 -> v1.222.0
note: pass `--verbose` to see 35 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating object v0.36.5 -> v0.36.7
note: pass `--verbose` to see 6 unchanged dependencies behind latest
rustbook dependencies:
Locking 9 packages to latest compatible versions
Updating cc v1.2.0 -> v1.2.5
Updating clap_complete v4.5.39 -> v4.5.40
Updating env_filter v0.1.2 -> v0.1.3
Updating env_logger v0.11.5 -> v0.11.6
Updating libc v0.2.168 -> v0.2.169
Updating miniz_oxide v0.8.1 -> v0.8.2
Updating serde_json v1.0.133 -> v1.0.134
Updating thiserror v2.0.7 -> v2.0.9
Updating thiserror-impl v2.0.7 -> v2.0.9
```
|
|
|
|
|
|
This facade is like other `run_make_support::fs` APIs that
panic-on-failure but includes the path that the operation was called on
in the panic message.
|
|
`aggressive_rm_rf` does not correctly handle distinction between
symlink-to-file vs symlink-to-dir on Windows.
|
|
|
|
|
|
|
|
|
|
fix: Fix flycheck workspace when requested but package was found
|
|
|
|
|
|
fix: Properly check if workspace flychecking is allowed
|
|
fix: Fix empty check diagnostics not marking files as changed
|
|
|
|
fix: Don't trigger paren wrapping typing handler after idents
|
|
|
|
|
|
minor: Tell the server to stop prior to restarting it
|
|
|
|
fix: Set `result_id` for `RelatedFullDocumentDiagnosticReport` everywhere
|
|
|
|
compiler & tools dependencies:
Locking 15 packages to latest compatible versions
Updating clap_complete v4.5.39 -> v4.5.40
Updating env_filter v0.1.2 -> v0.1.3
Updating env_logger v0.11.5 -> v0.11.6
Updating expect-test v1.5.0 -> v1.5.1
Updating foldhash v0.1.3 -> v0.1.4
Updating miniz_oxide v0.8.1 -> v0.8.2
Updating object v0.36.5 -> v0.36.7
Updating serde_json v1.0.133 -> v1.0.134
Updating thiserror v2.0.7 -> v2.0.9
Updating thiserror-impl v2.0.7 -> v2.0.9
Updating tinyvec v1.8.0 -> v1.8.1
Updating wasm-encoder v0.221.2 -> v0.222.0
Removing wasmparser v0.218.0
Removing wasmparser v0.221.2
Adding wasmparser v0.222.0
Updating wast v221.0.2 -> v222.0.0
Updating wat v1.221.2 -> v1.222.0
note: pass `--verbose` to see 35 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating object v0.36.5 -> v0.36.7
note: pass `--verbose` to see 6 unchanged dependencies behind latest
rustbook dependencies:
Locking 9 packages to latest compatible versions
Updating cc v1.2.0 -> v1.2.5
Updating clap_complete v4.5.39 -> v4.5.40
Updating env_filter v0.1.2 -> v0.1.3
Updating env_logger v0.11.5 -> v0.11.6
Updating libc v0.2.168 -> v0.2.169
Updating miniz_oxide v0.8.1 -> v0.8.2
Updating serde_json v1.0.133 -> v1.0.134
Updating thiserror v2.0.7 -> v2.0.9
Updating thiserror-impl v2.0.7 -> v2.0.9
|
|
|
|
Miri subtree update
r? `@ghost`
|
|
remove an unused helper method
|
|
|
|
add more tests for SC access/fence consistency
|
