| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 5 pull requests
Successful merges:
- #131023 (Copy correct path to clipboard for modules/keywords/primitives)
- #131035 (Preserve brackets around if-lets and skip while-lets)
- #131038 (Fix `adt_const_params` leaking `{type error}` in error msg)
- #131053 (Improve `--print=check-cfg` documentation)
- #131056 (enable compiler fingerprint logs in verbose mode)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
enable compiler fingerprint logs in verbose mode
This provides very useful logs especially when debugging build cache-related stuff.
|
|
Improve `--print=check-cfg` documentation
This PR improves the `--print=check-cfg` documentation by:
1. switching to a table for better readability
2. adding a clear indication where the specific check-cfg syntax starts
3. adding a link to the main `--check-cfg` documentation
`@rustbot` label +F-check-cfg
|
|
r=compiler-errors
Fix `adt_const_params` leaking `{type error}` in error msg
Fixes the confusing diagnostic described in #118179. (users would see `{type error}` in some situations, which is pretty weird)
`adt_const_params` tracking issue: #95174
|
|
Preserve brackets around if-lets and skip while-lets
r? `@jieyouxu`
Tracked by #124085
Fresh out of #129466, we have discovered 9 crates that the lint did not successfully migrate because the span of `if let` includes the surrounding brackets `(..)` like the following, which surprised me a bit.
```rust
if (if let .. { .. } else { .. }) {
// ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// the span somehow includes the surrounding brackets
}
```
There is one crate that failed the migration because some suggestion spans cross the macro expansion boundaries. Surely there is no way to patch them with `match` rewrite. To handle this case, we will instead require all spans to be tested for admissibility as suggestion spans.
Besides, there are 4 false negative cases discovered with desugared-`while let`. We don't need to lint them, because the `else` branch surely contains exactly one statement because the drop order is not changed whatsoever in this case.
```rust
while let Some(value) = droppy().get() {
..
}
// is desugared into
loop {
if let Some(value) = droppy().get() {
..
} else {
break;
// here can be nothing observable in this block
}
}
```
I believe this is the one and only false positive that I have found. I think we have finally nailed all the corner cases this time.
|
|
Copy correct path to clipboard for modules/keywords/primitives
Fixes #131021
|
|
Bump `cc` and run `cargo update` for bootstrap
Bump `cc` to 1.1.22, which includes a caching fix. Also run `cargo update` which does a minor increment on a few dependencies.
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #130895 (make type-check-4 asm tests about non-const expressions)
- #131057 (Reject leading unsafe in `cfg!(...)` and `--check-cfg`)
- #131060 (Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags to fix stage 1 cargo rebuilds)
- #131061 (replace manual verbose checks with `Config::is_verbose`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
replace manual verbose checks with `Config::is_verbose`
self-explanatory
|
|
Drop conditionally applied cargo `-Zon-broken-pipe=kill` flags to fix stage 1 cargo rebuilds
The conditionally applied `-Zon-broken-pipe=kill` flag trigger rebuilds because they can invalidate previous tool build cache due to differing flags. This PR removes those flags to stop tool build cache invalidation.
> The build cache for clippy will be broken because bootstrap sets `-Zon-broken-pipe=kill` for every invocation except for cargo. Which means building cargo will invalidate any tool build cache which was built previously.
>
> *From <https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Modifying.20run-make.20tests.20unnecessarily.20rebuild.20stage.201.20cargo/near/473486972>*
Fixes #130980.
But introduces #131059 (breaks 2 cargo tests that relied upon some behavior related to `-Zon-broken-pipe=kill` being set).
r? `@onur-ozkan` (or bootstrap)
|
|
Reject leading unsafe in `cfg!(...)` and `--check-cfg`
This PR reject leading unsafe in `cfg!(...)` and `--check-cfg`.
Fixes (after-backport) https://github.com/rust-lang/rust/issues/131055
r? `@jieyouxu`
|
|
make type-check-4 asm tests about non-const expressions
These tests recently got changed in https://github.com/rust-lang/rust/pull/129759. I asked the PR author to make the tests read from a `static mut` (rather than just making them "pass"), but I now think that was a mistake: previously the tests failed because the const was not a valid const expression, after the PR they failed because the const failed to evaluate.
So this PR restores the tests to "fail because the const is not a valid const expression". That can be done in a target-independent way so I unified the x86 and aarch64 tests into one.
Cc `@oli-obk` as the original [author](https://github.com/rust-lang/rust/commit/0d88631059742db30c44edadd1c8a2f51c8eb971) of these tests -- not sure if you still remember what they were intended to test.
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
These conditionally applied flags trigger rebuilds because they can
invalidate previous cargo build cache.
|
|
add has_enzyme/needs-enzyme to the test infra
This unblocks merging the Enzyme / Autodiff frontend.
For the full implementation, see: https://github.com/rust-lang/rust/pull/129175
We don't want to run tests that require Enzyme / Autodiff support when we build rustc without the required features.
It correctly filtered out a test which started with `//@ needs-enzyme`.
```
running 80 tests
i...............................................................................
test result: ok. 79 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 380.41ms
```
Tracking:
- https://github.com/rust-lang/rust/issues/124509
r? jieyouxu
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
weekly update: add header to compiler deps update
Look at #131000: library and rustbook have nice headers for deps updates (i.e. `library dependencies:`), but not compiler one. Fixes this.
|
|
avoid `{type error}` being leaked in user-facing messages,
particularly when using the `adt_const_params` feature
|
|
Miri subtree update
r? `@ghost`
|
|
properly elaborate effects implied bounds for super traits
Summary: This PR makes it so that we elaborate `<T as Tr>::Fx: EffectsCompat<somebool>` into `<T as SuperTr>::Fx: EffectsCompat<somebool>` when we know that `trait Tr: ~const SuperTr`.
Some discussion at https://github.com/rust-lang/project-const-traits/issues/2.
r? project-const-traits
`@rust-lang/project-const-traits:` how do we feel about this approach?
|
|
|
|
In redesigned rustdoc toolbar: Adjust spacings and sizing to improve behavior with over-long names
Fixes #130993.
Some additional adjustments also fix more issues I’ve noticed such as:
* on small screens, opening search made the 3 bottons move down very slightly (because the row with the crate picker got larger, enlarging the whole grid), this is fixed with a `min-height: 60px` on the toolbar
* with long names in the “breadcrumps” area, wrapping was very broken
* 
* fixed:
* 
* the left grid area has a minimal width (105px); like before, that leaves about enough space for crate names becoming as short as “all cra…”;
to save even more space, there’s support for a little bit of extra squeezing of the buttons
* 
* 
* 
I’m really not super good with HTML or CSS stuff at all; there seem to be many magical numbers already, I’ve just used `px` values until things look right, I hope that’s okay 🤷♂️
r? `@GuillaumeGomez`
cc `@notriddle`
|
|
|
|
|
|
let rustfmt format imports
This matches the recent change in rustc.
`@rust-lang/miri` what do you think?
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #123932 (restate GlobalAlloc method safety preconditions in terms of what the caller has to do for greater clarity)
- #129003 (Improve Ord docs)
- #130972 (stabilize const_cell_into_inner)
- #130990 (try to get rid of mir::Const::normalize)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
try to get rid of mir::Const::normalize
It was easy to make this compile, let's see if anything breaks...
r? `@compiler-errors`
|
|
stabilize const_cell_into_inner
This const-stabilizes
- `UnsafeCell::into_inner`
- `Cell::into_inner`
- `RefCell::into_inner`
- `OnceCell::into_inner`
`@rust-lang/wg-const-eval` this uses `rustc_allow_const_fn_unstable(const_precise_live_drops)`, so we'd be comitting to always finding *some* way to accept this code. IMO that's fine -- what these functions do is to move out the only field of a struct, and that struct has no destructor itself. The field's destructor does not get run as it gets returned to the caller.
`@rust-lang/libs-api` this was FCP'd already [years ago](https://github.com/rust-lang/rust/issues/78729#issuecomment-811409860), except that `OnceCell::into_inner` was added to the same feature gate since then (Cc `@tgross35).` Does that mean we have to re-run the FCP? If yes, I'd honestly prefer to move `OnceCell` into its own feature gate to not risk missing the next release. (That's why it's not great to add new functions to an already FCP'd feature gate.) OTOH if this needs an FCP either way since the previous FCP was so long ago, then we might as well do it all at once.
|
|
Improve Ord docs
- Makes wording more clear and re-structures some sections that can be overwhelming for someone not already in the know.
- Adds examples of how *not* to implement Ord, inspired by various anti-patterns found in real world code.
Many of the wording changes are inspired directly by my personal experience of being confused by the `Ord` docs and seeing other people get it wrong as well, especially lately having looked at a number of `Ord` implementations as part of #128899.
Created with help by `@orlp.`
r? `@workingjubilee`
|
|
r=tgross35
restate GlobalAlloc method safety preconditions in terms of what the caller has to do for greater clarity
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #130931 (Rename `standalone` doctest attribute into `standalone_crate`)
- #131000 (Weekly `cargo update`)
- #131011 (cleanup: don't `.into()` identical types)
- #131013 (cleanup: don't manually `unwrap_or_default()`)
- #131014 (cleanup: don't clone types that are Copy)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
cleanup: don't clone types that are Copy
|
|
cleanup: don't manually `unwrap_or_default()`
|
|
cleanup: don't `.into()` identical types
|
|
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
Locking 5 packages to latest compatible versions
Updating autocfg v1.3.0 -> v1.4.0
Updating flate2 v1.0.33 -> v1.0.34
Updating portable-atomic v1.8.0 -> v1.9.0
Updating syn v2.0.77 -> v2.0.79
Updating tempfile v3.12.0 -> v3.13.0
note: pass `--verbose` to see 81 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 9 unchanged dependencies behind latest
rustbook dependencies:
Locking 13 packages to latest compatible versions
Updating autocfg v1.3.0 -> v1.4.0
Updating cc v1.1.21 -> v1.1.22
Updating flate2 v1.0.33 -> v1.0.34
Updating libc v0.2.158 -> v0.2.159
Updating pkg-config v0.3.30 -> v0.3.31
Updating redox_syscall v0.5.4 -> v0.5.6
Updating serde_spanned v0.6.7 -> v0.6.8
Updating syn v2.0.77 -> v2.0.79
Updating tempfile v3.12.0 -> v3.13.0
Updating thiserror v1.0.63 -> v1.0.64
Updating thiserror-impl v1.0.63 -> v1.0.64
Updating toml_edit v0.22.21 -> v0.22.22
Updating winnow v0.6.18 -> v0.6.20
note: pass `--verbose` to see 30 unchanged dependencies behind latest
```
|
|
Rename `standalone` doctest attribute into `standalone_crate`
Following [zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/Renaming.20code.20block.20.22standalone.22.20attribute.3F) and poll results.
r? `@notriddle`
|
|
crashes: more tests
r? `@jieyouxu`
|
|
|
|
coherency
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #130383 (check if it's rust-lang/rust CI job in `llvm::is_ci_llvm_modified`)
- #130416 (resolve #130122: reword 'sort-by' edge-conditions documentation)
- #130537 (rustdoc: add doc comment to DocVisitor)
- #130743 (Clarifications for set_nonblocking methods)
- #131010 (extend comment in global_llvm_features regarding target-cpu=native)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
extend comment in global_llvm_features regarding target-cpu=native
Based on the description in https://github.com/rust-lang/rust/pull/83084 by `@nagisa` -- seems better to have this in the code, where it is easier to find.
|
|
Clarifications for set_nonblocking methods
Closes #129903.
The issue mentions that `send`, `recv` and other operations are interpreted by some users as methods of `TcpSocket` which led to confusion since it hasn't them. To fix it I added "system" into the documentation as being more precise for two reasons:
* it's makes it clear that these names are system operations;
* it doesn't point to the location of these methods like `libc` because not every system is POSIX compatible.
|
