| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove extra whitespace from rustdoc breadcrumbs for copypasting
The docs header used to display [item names with their full path](https://doc.rust-lang.org/1.82.0/std/os/unix/ffi/trait.OsStrExt.html), but a [recent design change](https://doc.rust-lang.org/1.83.0/std/os/unix/ffi/trait.OsStrExt.html) has split the path and added extra styling to it.
The problem is the new styling affects how this text is copied to clipboard. I used to copy and paste the paths into `use` statements in the code, but the new styling has extra formatting and whitespace that makes copied text unusable in Rust source code.
Instead of:
> std::os::unix::ffi::OsStrExt
I now get:
> std
> ::
> os
> ::
> unix
> ::
> ffi
> Trait OsStrExt
This change removes extra whitespace from the markup, and removes `display: flex`. Paths (now in small text) are unlikely to be that long to wrap, and even then regular text wrapping should be sufficient.
|
|
TRPL: more backward-compatible Edition changes
- Improve the discussion of `unsafe` blocks within `unsafe` functions.
- Fix formatting in Appendix A
- Incorporate line edits to Chapter 17 from NoStarch.
|
|
Fix GDB `OsString` provider on Windows
It would throw an exception due to trying to look up `Wtf8Buf.__0`. The field it actually wants is called [`bytes`](https://github.com/rust-lang/rust/blob/b605c65b6eb5fa71783f8e26df69975f9f1680ee/library/std/src/sys_common/wtf8.rs#L134).
|
|
Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only)
Changes of this pull request:
1. Refactor code for qnx nto targets to share more code in file `nto_qnx.rs`
1. Add support for an additional network stack on nto qnx 7.1.
QNX 7.1 supports two network stacks:
1. `io-pkt`, which is default
2. `io-sock`, which is optional on 7.1 but default in QNX 8.0
As one can see in the [io-sock migration notes](https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.io_sock/topic/migrate_app.html), this changes the libc API in a way similar to e.g. linux-gnu vs. linux-musl.
This change adds a new target which has a different value for `target_env`, so that e.g. libc can distinguish between both APIs.
2. Add initial support for QNX 8.0, thanks to AkhilTThomas. As it turned out, the problem with forking many processes still exists in QNX 8.0. Because if this, we are now using it for any QNX version (i.e. not check for `target_env` anymore).
|
|
fix: Don't complete doc(hidden) enum variants and use trees
|
|
And also register its check step.
Co-authored-by: Jane Losare-Lusby <jlusby42@gmail.com>
|
|
Co-authored-by: Jane Losare-Lusby <jlusby42@gmail.com>
|
|
Co-authored-by: Jane Losare-Lusby <jlusby42@gmail.com>
|
|
fix: Make proc_macro span's line & column 1-indexed, as documented
|
|
That is, make the fake number that we return 1 and not 0.
|
|
|
|
|
|
Update emscripten std tests
This disables a bunch of emscripten tests that test things emscripten doesn't support and re-enables a whole bunch of tests which now work just fine on emscripten.
Tested with `EMCC_CFLAGS="-s MAXIMUM_MEMORY=2GB" ./x.py test library/ --target wasm32-unknown-emscripten`.
|
|
fix(libtest): Deprecate '--logfile'
rust-lang/testing-devex-team#9 proposed changing the behavior of `--logfile`. The given reasons were:
(1) Bazel can't programmatically process stdout. This seems like a limitation in Bazel and we recommend focusing on that. If we look at the wider Rust ecosystem, Rustc and Cargo don't support any such mechanism and the Cargo team rejected having one. Expecting this in libtest when its not supported elsewhere seems too specialized.
(2) Tests that leak out non-programmatic output that intermixes with programmatic output. We acknowledge this is a problem to be evaluated but we need to make sure we are stepping back and gathering requirements, rather than assuming `--logfile` will fit the needs.
Independent of the motive, regarding using or changing `--logfile`
(1) Most ways to do it would be a breaking change, like if we respect any stable `--format`. As suggested above, we could specialize this to new `--format` values but that would be confusing for some values to apply but not others.
(2) Other ways of solving this add new features to lib`test` when we are instead wanting to limit the feature set it has to minimize the compatibility surface that has to be maintained and the burden it would put on third party harnesses which are a focus area. Examples include `--format compact` or a `--log-format` flag
(3) The existence of `--logfile` dates back quite a ways (https://github.com/rust-lang/rust/commit/5cc050b265509c19717e11e12dd785d8c73f5b11, rust-lang/rust#2127) and the history gives the
impression this more of slipped through rather than being an intended feature (see also
https://github.com/rust-lang/rust/pull/82350#discussion_r579732071). Deprecation would better match to how it has been treated. By deprecating this, we do not expect custom test harnesses (rust-lang/testing-devex-team#2) to implement this.
T-testing-devex held an FCP for deprecating in rust-lang/testing-devex-team#9 though according to
[RFC #3455](https://rust-lang.github.io/rfcs/3455-t-test.html), this is still subject to final approval from T-libs-api.
Closes rust-lang/testing-devex-team#9
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #134300 (remove long-deprecated no-op attributes no_start and crate_id)
- #134373 (Improve and expand documentation of pipes)
- #135934 (Include missing item in the 1.81 release notes)
- #136005 (ports last few library files to new intrinsic style)
- #136016 (Improve check-cfg expected names diagnostic)
- #136039 (docs: fix typo in std::pin overview)
- #136056 (Fix typo in const stability error message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve check-cfg expected names diagnostic
This PR improves the check-cfg `allow-same-level` test by ~~normalizing it's output and by~~ adding more context to the test.
It also filters the well known cfgs from the `expected names are` note, as to reduce the size of the diagnostic. Users can still find the full list on the [rustc book](https://doc.rust-lang.org/nightly/rustc/check-cfg.html#well-known-names-and-values), which is reinforced for Cargo users by adding a note in the Cargo check-cfg specific section.
Fixes https://github.com/rust-lang/rust/issues/135995
r? `@jieyouxu`
|
|
Also refactor the check a bit.
|
|
|
|
- Don't show environment variables. Seeing PATH is almost never useful, and it can be extremely long.
- For .rlibs in the sysroot, replace crate hashes with a `"-*"` string. This will expand to the full crate name when pasted into the shell.
- Move `.rlib` to outside the glob.
- Abbreviate the sysroot path to `<sysroot>` wherever it appears in the arguments.
This also adds an example of the linker output as a run-make test. Currently it only runs on x86_64-unknown-linux-gnu, because each platform has its own linker arguments. So that it's stable across machines, pass BUILD_ROOT as an argument through compiletest through to run-make tests.
- Only use linker-flavor=gnu-cc if we're actually going to compare the output. It doesn't exist on MacOS.
|
|
fix: Prevent infinite recursion of bounds formatting
|
|
|
|
It seems one can't overwrite a cache entry:
```
Failed to save: Unable to reserve cache with key linkcheck--0.8.1, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/master, Key: linkcheck--0.8.1, Version: 33f8fd511bed9c91c40778bc5c27cb58425caa894ab50f9c5705d83cb78660e0
Warning: Cache save failed.
```
A proper solution is to use `restore-keys`:
https://github.com/actions/cache/blob/main/tips-and-workarounds.md#update-a-cache
|
|
show linker output even if the linker succeeds
Show stderr and stderr by default, controlled by a new `linker_messages` lint.
fixes https://github.com/rust-lang/rust/issues/83436. fixes https://github.com/rust-lang/rust/issues/38206. cc https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408986134
<!-- try-job: dist-x86_64-msvc -->
try-job: aarch64-apple
r? `@bjorn3`
|
|
|
|
|
|
|
|
fix: Fix markdown horizontal ruler sometimes being treated as a heading
|
|
|
|
|
|
|
|
Reword resolve errors caused by likely missing crate in dep tree
Reword label and add `help`:
```
error[E0432]: unresolved import `some_novel_crate`
--> f704.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
|
= help: if you wanted to use a crate named `some_novel_crate`, use `cargo add some_novel_crate` to add it to your `Cargo.toml`
```
Fix #133137.
|
|
|
|
|
|
fix: Fix flyimport not filtering via stability of import path
|
|
|
|
Only collect implicit visibile use symbols if they have renames
|
|
Otherwise this will pollute the index too much with unnecessary symbols
|
|
Make niches into nices
|
|
minor: Suggest better names when a type is a sequence
|
|
fix(bootstrap): deserialize null as `f64::NAN`
When doing optimized build through opt-dist,
I've often run into errors like `invalid type: null, expected f64`.
This is likely because some f64 fields might actually bet set null.
Unfortunately, serde_json doesn't handle null <-> NaN well.
This commit addresses it by having a custom deserialize method, so null is always be deserialized to `f64:NAN`.
See:
* https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/opt-dist.3A.20.60invalid.20type.3A.20null.2C.20expect.20f64.60.20failure
* https://github.com/serde-rs/json/issues/202
r? `@Kobzol`
|
|
Bootstrap: Don't move ownership of job object
I've been thinking about this since the last time I looked at bootstrap's use of job objects. We currently pass ownership of the job object to Python. I feel this is unneeded complexity.
The rationale given (in a comment) is that it helps with `ctrl-c` on `x.py`. But using `ctrl-c` when running `x.py` will also cause `bootstrap.exe` to immediately exit so I don't find that convincing.
|
|
bootstrap: Handle bootstrap lockfile race condition better
Fixes #135972
Tested by:
- Starting one build
- In another terminal, `echo -n '' > build/lock`
- Attempt to invoke bootstrap a second time
|
|
Rename test to `unresolvable-upvar-issue-87987.rs` and add some notes
Extracted from #135756. I had to figure out what this test was trying to test, so I might as well write it down for future reference.
|
|
|
|
|
|
|
|
|
|
Update cargo
5 commits in 045bf21b36a2e1f3ed85e38278d1c3cc4305e134..cecde95c119a456c30e57d3e4b31fff5a7d83df4
2025-01-17 14:59:36 +0000 to 2025-01-24 17:15:24 +0000
- Remove unused `-C link-arg=-fuse-ld=lld` (rust-lang/cargo#15097)
- Remove `unsafe` by using `LazyLock` (rust-lang/cargo#15096)
- Print globs when workspace members can't be found (rust-lang/cargo#15093)
- Make --allow-dirty imply --allow-staged (rust-lang/cargo#15013)
- fix(config): When merging, replace rather than combining specific configuration keys (rust-lang/cargo#15066)
|
|
When doing optimized build through opt-dist,
I've often run into errors like `invalid type: null, expected f64`.
This is likely because some f64 fields might actually bet set null.
Unfortunately, serde_json doesn't handle null <-> NaN well.
This commit addresses it by having a custom deserialize method, so
null is always be deserialized to `f64:NAN`.
See:
* https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/opt-dist.3A.20.60invalid.20type.3A.20null.2C.20expect.20f64.60.20failure
* https://github.com/serde-rs/json/issues/202
|
