Rust 1.70.0 #45
Closed
Rust 1.70.0 #45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since ascii chars are already handled by a special case in the `to_lower` and `to_upper` functions, there's no need to waste space on them in the LUTs.
panic!("a {}", "b") is still not allowed in const,
even if the hir flattens to panic!("a b").
The majority of char case replacements are single char replacements, so storing them as [char; 3] wastes a lot of space. This commit splits the replacement tables for both `to_lower` and `to_upper` into two separate tables, one with single-character mappings and one with multi-character mappings. This reduces the binary size for programs using all of these tables with roughly 24K bytes.
Flatten/inline format_args!() and (string and int) literal arguments into format_args!() Implements rust-lang/rust#78356 Gated behind `-Zflatten-format-args=yes`. Part of #99012 This change inlines string literals, integer literals and nested format_args!() into format_args!() during ast lowering, making all of the following pairs result in equivalent hir: ```rust println!("Hello, {}!", "World"); println!("Hello, World!"); ``` ```rust println!("[info] {}", format_args!("error")); println!("[info] error"); ``` ```rust println!("[{}] {}", status, format_args!("error: {}", msg)); println!("[{}] error: {}", status, msg); ``` ```rust println!("{} + {} = {}", 1, 2, 1 + 2); println!("1 + 2 = {}", 1 + 2); ``` And so on. This is useful for macros. E.g. a `log::info!()` macro could just pass the tokens from the user directly into a `format_args!()` that gets efficiently flattened/inlined into a `format_args!("info: {}")`. It also means that `dbg!(x)` will have its file, line, and expression name inlined: ```rust eprintln!("[{}:{}] {} = {:#?}", file!(), line!(), stringify!(x), x); // before eprintln!("[example.rs:1] x = {:#?}", x); // after ``` Which can be nice in some cases, but also means a lot more unique static strings than before if dbg!() is used a lot.
For larger applications it's important that users set `RUST_MIN_STACK` at the start of their program because `min_stack` caches the value. Not doing so can lead to their `env::set_var` call surprisingly not having any effect.
This makes pin docs a little bit less jargon-y and easier to read, by * splitting up the sentences * making them less interrupted by punctuation * turning the footnotes into paragraphs, as they contain useful information that shouldn't be hidden in footnotes. Footnotes also interrupt the read flow. * other improvements and simplifications
The indices are encoded as `u32`s in the range of invalid `char`s, so that we know that if any mapping fails to parse as a `char` we should use the value for lookup in the multi-table. This avoids the second binary search in cases where a multi-`char` mapping is needed. Idea from @nikic
The interaction between the environment variable methods can be confusing. Specifically `env_clear` and `remove_env` have a side effects not mentioned: they disable inheriting environment variables from the parent process. I wanted to fully document this behavior as well as explain relevant edge cases in each of the `Command` env methods. This is further confused by the return of `get_envs` which will return key/None if `remove_env` has been used, but an empty iterator if `env_clear` has been called. Or a non-empty iterator if `env_clear` was called and later explicit mappings are added. Currently there is no way (that I'm able to find) of observing whether or not the internal `env_clear=true` been toggled on the `Command` struct via its public API. Ultimately environment variable mappings can be in one of several states: - Explicitly set value (via `envs` / `env`) will take precedence over parent mapping - Not explicitly set, will inherit mapping from parent - Explicitly removed via `remove_env`, this single mapping will not inherit from parent - Implicitly removed via `env_clear`, no mappings will inherit from parent I tried to represent this in the relevant sections of the docs. This is my second ever doc PR (whoop!). I'm happy to take specific or general doc feedback. Also happy to explain the logic behind any changes or additions I made.
This makes a bit more sense — iter impl converts to slice first, while slice impl used to create iter, doing unnecessary conversions.
Bump bootstrap compiler to 1.69 beta r? `@pietroalbini`
fallback to lstat when stat fails on Windows Fixes #109106 ````@ChrisDenton```` please let me know if this is the expected behavior for stat on windows
Very minor thing that I happened to notice in passing, but it's both shorter and means it gets `mul nuw`, so why not.
…heck, implement const Iterator and DoubleEndedIterator for Range.
Use `size_of_val` instead of manual calculation Very minor thing that I happened to notice in passing, but it's both shorter and [means it gets `mul nsw`](https://rust.godbolt.org/z/Y9KxYETv5), so why not.
Make rust-intrinsic ABI unwindable Fix #104451, fix rust-lang/miri#2839 r? `@RalfJung`
Added diagnostic for pin! macro in addition to Box::pin if Unpin isn't implemented
I made a PR earlier, but accidentally renamed a branch and that deleted the PR... sorry for the duplicate
Currently, if an operation on `Pin<T>` is performed that requires `T` to implement `Unpin`, the diagnostic suggestion is to use `Box::pin` ("note: consider using `Box::pin`").
This PR suggests pin! as well, as that's another valid way of pinning a value, and avoids a heap allocation. Appropriate diagnostic suggestions were included to highlight the difference in semantics (local pinning for pin! vs non-local for Box::pin).
Fixes #109964
Re-phrase in a way that handles input values being either 0 or negative.
This patch updates the error reporting when Safe Transmute is not possible between 2 types by including the reason. Also, fix some small bugs that occur when computing the `Answer` for transmutability.
linkat() not available in the system headers of Solaris 10
I've installed rustup on x86_64-unknown-linux-gnu and would like to use the target sparcv9-sun-solaris. For this, I have built a gcc from the source code for cross-compiling to sparcv9-sun-solaris2.10 with system headers of Solaris 10.
With the following hello word example:
main.rs:
```rust
fn main() {
println!("Hello, world!");
}
```
I had a compilation error:
```
$ rustc -v --target sparcv9-sun-solaris -C linker=/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc main.rs
error: linking with `/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc` failed: exit status: 1
|
= note: "/opt/cross-solaris/gcc730/bin/sparcv9-sun-solaris2.10-gcc" "-m64" "/tmp/rustcgebYgj/symbols.o" "main.main.89363361-cgu.0.rcgu.o" "main.main.89363361-cgu.1.rcgu.o" "main.main.89363361-cgu.2.rcgu.o" "main.main.89363361-cgu.3.rcgu.o" "main.main.89363361-cgu.4.rcgu.o" "main.main.89363361-cgu.5.rcgu.o" "main.csypsau9u2r8348.rcgu.o" "-Wl,-z,ignore" "-L" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib" "-Wl,-Bstatic" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd-fa47c8247d587714.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libpanic_unwind-5c87bbe223e6c2a3.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libobject-d484934062ff9fbb.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libmemchr-e8dbd5835abcbf43.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libaddr2line-909ad09329bde2f9.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libgimli-4d74a3be929697ac.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_demangle-47cbe1d7f7271ae1.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd_detect-239fd2d25fb32a00.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libhashbrown-c4a7ce45fb9dec19.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libminiz_oxide-fa6bc3d9bfb4e402.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libadler-419f5a82ddd339a3.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_std_workspace_alloc-7672b378962c11be.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libunwind-0f9e07f0a032c000.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcfg_if-ede7757c356dfb28.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/liblibc-808d56fbc668148a.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/liballoc-784767fe059ad3fe.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/librustc_std_workspace_core-aa31d7ef0556bbe1.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcore-81d07df07db18847.rlib" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libcompiler_builtins-313a510e63006db2.rlib" "-Wl,-Bdynamic" "-lsocket" "-lposix4" "-lpthread" "-lresolv" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lsendfile" "-llgrp" "-L" "/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib" "-o" "main" "-nodefaultlibs"
= note: /opt/cross-solaris/gcc730/lib/gcc/sparcv9-sun-solaris2.10/7.3.0/../../../../sparcv9-sun-solaris2.10/bin/ld: warning: -z ignore ignored.
/home/dlaugt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/sparcv9-sun-solaris/lib/libstd-fa47c8247d587714.rlib(std-fa47c8247d587714.std.5c42d2c1-cgu.0.rcgu.o): In function `std::sys::unix::fs::link::h3683dfbfbb4995cb':
/rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/sys/unix/fs.rs:1407: undefined reference to `linkat'
collect2: error: ld returned 1 exit status
= help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
= note: use the `-l` flag to specify native libraries to link
= note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)
```
linkat() is not available in the system headers of Solaris 10. The hello word example works fine when I build/use rust with this PR change.
Clarify that RUST_MIN_STACK may be internally cached For larger applications it's important that users set `RUST_MIN_STACK` at the start of their program because [`min_stack`](https://github.com/rust-lang/rust/blob/7d3e03666a93bd2b0f78b3933f9305832af771a5/library/std/src/sys_common/thread.rs) caches the value. Not doing so can lead to their `env::set_var` call surprisingly not having any effect. In my own testing `RUST_MIN_STACK` had no effect until I moved it to the top of `main()`. Hopefully this clarification in the docs will help others going forward.
…r=compiler-errors Improve safe transmute error reporting This patch updates the error reporting when Safe Transmute is not possible between 2 types by including the reason. Also, fix some small bugs that occur when computing the `Answer` for transmutability.
Remove obsolete test case This test case was supposed to cover issue #31109 at some point. It never did anything, as the issue was still open at the time of its creation. When the issue was resolved, the `issue31109` test case was created, making the existence of this test pointless.
…omcc
Cover edge cases for {f32, f64}.hypot() docs
Fixes #88944
The Euclidean distance is a more general way to express what these functions do, and covers the edge cases of zero and negative inputs.
Does not cover the case of non-normal input values (as the [POSIX docs](https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/) do), but the docs for the rest of the functions in these modules do not address this, I assumed it was not desired.
Rollup of 9 pull requests
Successful merges:
- #109225 (Clarify that RUST_MIN_STACK may be internally cached)
- #109800 (Improve safe transmute error reporting)
- #110158 (Remove obsolete test case)
- #110180 (don't uniquify regions when canonicalizing)
- #110207 (Assemble `Unpin` candidates specially for generators in new solver)
- #110276 (Remove all but one of the spans in `BoundRegionKind::BrAnon`)
- #110279 (rustdoc: Correctly handle built-in compiler proc-macros as proc-macro and not macro)
- #110298 (Cover edge cases for {f32, f64}.hypot() docs)
- #110299 (Switch to `EarlyBinder` for `impl_subject` query)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
and couple of its methods
Add better assert messages for f32/f64 clamps
Add link to `collections` docs to `extend` trait I believe it would be useful here.
Add `tidy-alphabetical` to features in `core` So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often.
Add `tidy-alphabetical` to features in `alloc` & `std` So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often. Follow-up to #110269 cc `@jyn514`
…ethods, r=Amanieu Add Command environment variable inheritance docs The interaction between the environment variable methods can be confusing. Specifically `env_clear` and `remove_env` have a side effects not mentioned: they disable inheriting environment variables from the parent process. I wanted to fully document this behavior as well as explain relevant edge cases in each of the `Command` env methods. This is further confused by the return of `get_envs` which will return key/None if `remove_env` has been used, but an empty iterator if `env_clear` has been called. Or a non-empty iterator if `env_clear` was called and later explicit mappings are added. Currently there is no way (that I'm able to find) of observing whether or not the internal `env_clear=true` been toggled on the `Command` struct via its public API. Ultimately environment variable mappings can be in one of several states: - Explicitly set value (via `envs` / `env`) will take precedence over parent mapping - Not explicitly set, will inherit mapping from parent - Explicitly removed via `remove_env`, this single mapping will not inherit from parent - Implicitly removed via `env_clear`, no mappings will inherit from parent I tried to represent this in the relevant sections of the docs. This is my second-ever doc PR (whoop!). I'm happy to take specific or general doc feedback. Also happy to explain the logic behind any changes or additions I made.
Add links from `core::cmp` derives to their traits Fixes #109946 Adds intra-doc links from the `core::cmp` derives to their respective traits, and a link to their derive behaviour `@rustbot` label +A-docs
Use `Display` in top-level example for `PanicInfo` Addresses rust-lang/rust#110098. This confused me as well, when I was writing a `no_std` panic handler for the first time, so here's a better top-level example. `Display` is stable, prints the `.message()` if available, and falls back to `.payload().downcast_ref<&str>()` if the message is not available. So this example should provide strictly more information and also work for formatted panics. The old example still exists on the `payload` method.
Fix typos in library I ran [`typos -w library`](https://github.com/crate-ci/typos) to fix typos in the `library` directory. Refs #110150
Remove some unneeded imports / qualified paths Continuation of #105537.
|
this seems fine. @BradyBonnette if you wanted to look at why this specific aarch64 job has ended up hanging both here and on 1.69, it might be worth considering. |
|
This gets my stamp of approval. I'll probably follow up with blocking off currently unstable functions that would cause problems if they stabilized, but that's not critical. |
|
(Closed, because obviously we shouldn't merge 1.70 into the 1.69 branch) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As before this shouldn't actually merge into 1.69, but will help kick off CI.