Update cargo
9 commits in 8f40fc59fb0c8df91c97405785197f3c630304ea..c1fa840a85eca53818895901a53fae34247448b2
2024-08-21 22:37:06 +0000 to 2024-08-29 21:03:53 +0000
- fix(resolve): With `latest` message, differentiate actionable updates (rust-lang/cargo#14461)
- fix(pkgid): Allow open namespaces in PackageIdSpec's (rust-lang/cargo#14467)
- feat(resolve): Report incompatible-with-rustc when MSRV-resolver is disabled (rust-lang/cargo#14459)
- fix(resolve): Report incompatible packages with precise Rust version (rust-lang/cargo#14457)
- fix(resolve): Dont show locking workspace members (rust-lang/cargo#14445)
- Log details of failure if no errors were seen (rust-lang/cargo#14453)
- More helpful missing feature error message (rust-lang/cargo#14436)
- feat: Add matches_prerelease semantic (rust-lang/cargo#14305)
- refactor(update): Prepare for smarter update messages (rust-lang/cargo#14440)
r? ghost
Apply size optimizations to panic machinery and some cold functions
* std dependencies gimli and addr2line are now built with opt-level=s
* various panic-related methods and `#[cold]` methods are now marked `#[optimize(size)]`
Panics should be cold enough that it doesn't make sense to optimize them for speed. The only tradeoff here is if someone does a lot of backtrace captures (without panics) and printing then the opt-level change might impact their perf.
Seems to be the first use of the optimize attribute. Tracking issue #54882
This commit makes the "Wrap return type in Result" assist prefer type aliases of standard library
type when the are in scope, use at least one generic parameter, and have the name "Result".
The last restriction was made in an attempt to avoid false assumptions about which type the
user is referring to, but that might be overly strict. We could also do something like this, in
order of priority:
* Use the alias named "Result".
* Use any alias if only a single one is in scope, otherwise:
* Use the standard library type.
This is easy to add if others feel differently that is appropriate, just let me know.
Rewrite lint_expectations in a single pass.
This PR aims at reducing the perf regression from https://github.com/rust-lang/rust/pull/120924#issuecomment-2202486203 with drive-by simplifications.
Basically, instead of using the lint level builder, which is slow, this PR splits `lint_expectations` logic in 2:
- listing the `LintExpectations` is done in `shallow_lint_levels_on`, on a per-owner basis;
- building the unstable->stable expectation id map is done by iterating on attributes.
r? ghost for perf
internal: Lay basic ground work for standalone mbe tests
Most of our mbe hir-def tests don't actually do anything name res relevant, we can (and should) move those down the stack into `mbe/hir-expand`.
minor: Downgrade cyclic deps error to warning
As the issue here is no longer workable for us and this appearing for some repos due to package cycles which can cause we should downgrade it as some people tend to think this breaks r-a when it doesn't
add `aarch64_unknown_nto_qnx700` target - QNX 7.0 support for aarch64le
This backports the QNX 7.1 aarch64 implementation to 7.0.
* [x] required `-lregex` disabled, see https://github.com/rust-lang/libc/pull/3775 (released in libc 0.2.156)
* [x] uses `libgcc.a` instead of `libgcc_s.so` (7.0 used ancient GCC 5.4 which didn't have gcc_s)
* [x] a fix in `backtrace` crate to support stack traces https://github.com/rust-lang/backtrace-rs/pull/648
This PR bumps libc dependency to 0.2.158
CC: to the folks who did the [initial implementation](https://doc.rust-lang.org/rustc/platform-support/nto-qnx.html): `@flba-eb,` `@gh-tr,` `@jonathanpallant,` `@japaric`
# Compile target
```bash
# Configure qcc build environment
source _path_/_to_/qnx7.0/qnxsdp-env.sh
# Tell rust to use qcc when building QNX 7.0 targets
export build_env='
CC_aarch64-unknown-nto-qnx700=qcc
CFLAGS_aarch64-unknown-nto-qnx700=-Vgcc_ntoaarch64le_cxx
CXX_aarch64-unknown-nto-qnx700=qcc
AR_aarch64_unknown_nto_qnx700=ntoaarch64-ar'
# Build rust compiler, libs, and the remote test server
env $build_env ./x.py build \
--target x86_64-unknown-linux-gnu,aarch64-unknown-nto-qnx700 \
rustc library/core library/alloc library/std src/tools/remote-test-server
rustup toolchain link stage1 build/host/stage1
```
# Compile "hello world"
```bash
source _path_/_to_/qnx7.0/qnxsdp-env.sh
cargo new hello_world
cd hello_world
cargo +stage1 build --release --target aarch64-unknown-nto-qnx700
```
# Configure a remote for testing
Do this from a new shell - we will need to run more commands in the previous one. I ran into these two issues, and found some workarounds.
* Temporary dir might not work properly
* Default `remote-test-server` has issues binding to an address
```
# ./remote-test-server
starting test server
thread 'main' panicked at src/tools/remote-test-server/src/main.rs:175:29:
called `Result::unwrap()` on an `Err` value: Os { code: 249, kind: AddrNotAvailable, message: "Can't assign requested address" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Specifying `--bind` param actually fixes that, and so does setting `TMPDIR` properly.
```bash
# Copy remote-test-server to remote device. You may need to use sftp instead.
# ATTENTION: Note that the path is different from the one in the remote testing documentation for some reason
scp ./build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server qnxdevice:/path/
# Run ssh with port forwarding - so that rust tester can connect to the local port instead
ssh -L 12345:127.0.0.1:12345 qnxdevice
# on the device, run
rm -rf tmp && mkdir -p tmp && TMPDIR=$PWD/tmp ./remote-test-server --bind 0.0.0.0:12345
```
# Run test suit
Assume all previous environment variables are still set, or re-init them
```bash
export TEST_DEVICE_ADDR="localhost:12345"
# tidy needs to be skipped due to using un-published libc dependency
export exclude_tests='
--exclude src/bootstrap
--exclude src/tools/error_index_generator
--exclude src/tools/linkchecker
--exclude src/tools/tidy
--exclude tests/ui-fulldeps
--exclude rustc
--exclude rustdoc
--exclude tests/run-make-fulldeps'
env $build_env ./x.py test $exclude_tests --stage 1 --target aarch64-unknown-nto-qnx700
```
try-job: dist-x86_64-msvc
Handle attributes correctly in "Flip comma"
Attributes often contain path followed by a token tree (e.g. `align(2)`), and the previous code handled them as two separate items, which led to results such as `#[repr(alignC, (2))]`.
An alternative is to just make the assist unavailable in attributes, like we do in macros. But contrary to macros, attributes often have a fixed form, so this seems useful.
Fixes#18013.
Provide an option to hide deprecated items from completion
Fixes#17989.
I wonder if this should be instead done in the editor, that will do it in a language-agnostic way. Can't hurt to do it in rust-analyzer, I guess.
Rollup of 8 pull requests
Successful merges:
- #128495 (core: use `compare_bytes` for more slice element types)
- #128641 (refactor: standardize duplicate processes in parser)
- #129207 (Lint that warns when an elided lifetime ends up being a named lifetime)
- #129493 (Create opaque definitions in resolver.)
- #129619 (Update stacker to 0.1.17)
- #129672 (Make option-like-enum.rs UB-free and portable)
- #129780 (add crashtests for several old unfixed ICEs)
- #129832 (Remove stray dot in `std::char::from_u32_unchecked` documentation)
r? `@ghost`
`@rustbot` modify labels: rollup
add crashtests for several old unfixed ICEs
Adds several new crashtests for some older ICEs that did not yet have any.
Tests were added for #128097, #119095, #117460 and #126443.
Update stacker to 0.1.17
The main new feature is support for detecting the current stack size on illumos. (See [my blog post] for the context which led to this.)
[my blog post]: https://sunshowers.io/posts/rustc-segfault-illumos/
try-job: x86_64-mingw
refactor: standardize duplicate processes in parser
## Summary
This PR refactors the `read_number` function to standardize duplicate code, improve readability, and enhance efficiency.
## Changes
- Merged the logic for both `max_digits` cases into a single `read_atomically` closure
- Simplified control flow and reduced code duplication
core: use `compare_bytes` for more slice element types
`bool`, `NonZero<u8>`, `Option<NonZero<u8>>` and `ascii::Char` can be compared the same way as `u8`.
Attributes often contain path followed by a token tree (e.g. `align(2)`, and the previous code handled them as two separate items, which led to results such as `#[repr(alignC, (2))]`.
An alternative is to just make the assist unavailable in attributes, like we do in macros. But contrary to macros, attributes often have a fixed form, so this seems useful.
Rollup of 11 pull requests
Successful merges:
- #128523 (Add release notes for 1.81.0)
- #129605 (Add missing `needs-llvm-components` directives for run-make tests that need target-specific codegen)
- #129650 (Clean up `library/profiler_builtins/build.rs`)
- #129651 (skip stage 0 target check if `BOOTSTRAP_SKIP_TARGET_SANITY` is set)
- #129684 (Enable Miri to pass pointers through FFI)
- #129762 (Update the `wasm-component-ld` binary dependency)
- #129782 (couple more crash tests)
- #129816 (tidy: say which feature gate has a stability issue mismatch)
- #129818 (make the const-unstable-in-stable error more clear)
- #129824 (Fix code examples buttons not appearing on click on mobile)
- #129826 (library: Fix typo in `core::mem`)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `#[macro_use] extern crate tracing` from rustdoc and rustfmt
A follow-up to #129767 and earlier PRs doing this for `rustc_*` crates.
r? ```@GuillaumeGomez```
Remove `#[macro_use] extern crate tracing`, round 4
Because explicit importing of macros via use items is nicer (more standard and readable) than implicit importing via #[macro_use]. Continuing the work from #124511, #124914, and #125434. After this PR no `rustc_*` crates use `#[macro_use] extern crate tracing` except for `rustc_codegen_gcc` which is a special case and I will do separately.
r? ```@jieyouxu```
Make the "detect-old-time" UI test more representative
The test code did have an inference failure, but that would have failed
on Rust 1.79 and earlier too. Now it is rewritten to be specifically
affected by 1.80's `impl FromIterator<_> for Box<str>`.
llvm-wrapper: adapt for LLVM API changes
No functional changes intended.
Updates the wrapper for 21eddfac3d.
````@rustbot```` label: +llvm-main
r? ````@nikic````
