Auto merge of #70826 - Centril:rollup-yn0hc1h, r=Centril
Rollup of 7 pull requests
Successful merges:
- #70553 (move OS constants to platform crate)
- #70665 (Do not lose or reorder user-provided linker arguments)
- #70750 (Match options directly in the Fuse implementation)
- #70782 (Stop importing the float modules in documentation)
- #70798 ("cannot resolve" → "cannot satisfy")
- #70808 (Simplify dtor registration for HermitCore by using a list of destructors)
- #70824 (Remove marker comments in libstd/lib.rs macro imports)
Rollup merge of #70824 - yoshuawuyts:fix-labels-in-std-macro-imports, r=Mark-Simulacrum
Remove marker comments in libstd/lib.rs macro imports
These comments were probably moved around when rustfmt was introduced. They don't correctly denote what they were intended for, so I propose we remove them instead. Thanks!
Rollup merge of #70782 - faern:use-assoc-float-consts, r=dtolnay
Stop importing the float modules in documentation
Follow up to #69860. I realized I had not searched for and fixed this for the float values. So with this PR they also use the associated constants instead of the module level constants.
For the documentation where it also was using the `consts` submodule I opted to change it to import that directly. This becomes more in line with how other docs that use the `consts` submodule looks. And it also makes it so there are not two `f32` or `f64` things in the current namespace (both the module and the primitive type) and then hopefully confusing documentation readers less.
Rollup merge of #70750 - cuviper:direct-fuse, r=scottmcm
Match options directly in the Fuse implementation
Rather than using `as_ref()`, `as_mut()`, and `?`, we can use `match` directly to save a lot of generated code. This was mentioned as a possibility in https://github.com/rust-lang/rust/pull/70366#issuecomment-603462546, and I found that it had a very large impact on #70332 using `Fuse` within `Chain`. Let's evaluate this change on its own first.
Rollup merge of #70665 - petrochenkov:linkargs, r=nagisa
Do not lose or reorder user-provided linker arguments
Linker arguments are potentially order-dependent, so the order in which `-C link-arg` and `-C link-args` options are passed to `rustc` should be preserved when they are passed further to the linker.
Also, multiple `-C link-args` options are now appended to each other rather than overwrite each other.
In other words, `-C link-arg=a -C link-args="b c" -C link-args="d e" -C link-arg=f` is now passed as `"a" "b" "c" "d" "e" "f"` and not as `"d" "e" "a" "f"`.
Auto merge of #70816 - Dylan-DPC:rollup-kzcs8px, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #67797 (Query-ify Instance::resolve)
- #70777 (Don't import integer and float modules, use assoc consts)
- #70795 (Keep track of position when deleting from a BTreeMap)
- #70812 (Do not use "nil" to refer to `()`)
- #70815 (Enable layout debugging for `impl Trait` type aliases)
Rollup merge of #70812 - rossmacarthur:fix/unit-called-nil, r=LukasKalbertodt
Do not use "nil" to refer to `()`
"nil" is not used in the [book](https://doc.rust-lang.org/book) or in the [standard library](https://doc.rust-lang.org/std) anywhere else. Because "nil" is often used in programming languages to refer to "None" or "null" I think it could be a little confusing for newcomers to see this type referred to as "nil".
Rollup merge of #70777 - faern:use-assoc-int-consts2, r=dtolnay
Don't import integer and float modules, use assoc consts
Stop importing the standard library integer and float modules to reach the `MIN`, `MAX` and other constants. They are available directly on the primitive types now.
This PR is a follow up of #69860 which made sure we use the new constants in documentation.
This type of change touches a lot of files, and previously all my assoc int consts PRs had collisions and were accepted only after a long delay. So I'd prefer to do it in smaller steps now. Just removing these imports seem like a good next step.
Auto merge of #70807 - Dylan-DPC:rollup-qd1kgl2, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #70558 (Fix some aliasing issues in Vec)
- #70760 (docs: make the description of Result::map_or more clear)
- #70769 (Miri: remove an outdated FIXME)
- #70776 (clarify comment in RawVec::into_box)
- #70806 (fix Miri assignment sanity check)
Rollup merge of #70769 - RalfJung:fixed, r=Dylan-DPC
Miri: remove an outdated FIXME
We even [have a test ](https://github.com/rust-lang/rust/blob/49dc2f9f091748beb1a8a9d5b3eb3bbe7362c3bd/src/test/ui/consts/miri_unleashed/drop.rs) making sure that we detect dropping with a non-const implementation.
Rollup merge of #70760 - PonasKovas:docs, r=Dylan-DPC
docs: make the description of Result::map_or more clear
The documentation of [`Result::map_or`](https://doc.rust-lang.org/std/result/enum.Result.html#method.map_or) is very unclear and confusing, probably because it was copied straight from [`Option::map_or`](https://doc.rust-lang.org/std/option/enum.Option.html#method.map_or) and someone forgot to adapt it for Result.
Rollup merge of #70558 - RalfJung:vec-extend-aliasing, r=Amanieu
Fix some aliasing issues in Vec
`Vec::extend` and `Vec::truncate` invalidated references into the vector even without reallocation, because they (implicitly) created a mutable reference covering the *entire* initialized part of the vector.
Fixes https://github.com/rust-lang/rust/issues/70301
I verified the fix by adding some new tests here that I ran in Miri.
Auto merge of #70803 - arlosi:hash-regression, r=eddyb
Fix performance regression in debuginfo file_metadata.
Fixes performance regression caused by #69718.
Finding the `SourceFile` associated with a `FileName` called `get_source_file` on the `SourceMap`, which does a linear search through all files in the `SourceMap`.
This resolves the issue by passing the `SourceFile` in from the caller (which already had it available) instead of the `FileName`
Arlo Siemsen [Sun, 5 Apr 2020 08:43:44 +0000 (01:43 -0700)]
Fix performance regression in debuginfo file_metadata.
Finding the `SourceFile` associated with a `FileName` called `get_source_file` on
the `SourceMap`, which does a linear search through all files in the `SourceMap`.
This resolves the issue by passing the SourceFile in from the caller (which already
had it available).
Auto merge of #70800 - Dylan-DPC:rollup-9jjoptp, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #70635 (rustc_target: Some cleanup to `no_default_libraries`)
- #70748 (Do not disable field reordering on enums with big discriminant)
- #70752 (Add slice::fill)
- #70766 (use ManuallyDrop instead of forget inside collections)
- #70768 (macro_rules: `NtLifetime` cannot start with an identifier)
- #70783 (comment refers to removed type)
Rollup merge of #70752 - yoshuawuyts:slice_fill, r=dtolnay
Add slice::fill
Adds the `slice::fill` method to fill a slice with an item. This replaces manual for loops where items are copied one-by-one. This is a counterpart to C++20's [`std::fill`](https://en.cppreference.com/w/cpp/algorithm/fill) function.
When compiling in release mode, for `[u8]` and `[u16]` this method will optimize to a `memset(3)` call ([godbolt](https://godbolt.org/z/85El_c)). The initial implementation relies on LLVM's optimizer to make it as fast as possible for any given input. But as @jonas-schievink [pointed out](https://twitter.com/sheevink/status/1245756597453885442) this can later be optimized through specialization to guarantee it has a specific performance profile.
## Why now?
Conversations about adding `slice::fill` are not new. In fact, https://github.com/rust-lang/rfcs/issues/2067 was opened 3 years ago about this exact topic. However discussion stranded while discussing implementation details, and it's not seen much forward motion since.
In ["The Hunt for the Fastest Zero"](https://travisdowns.github.io/blog/2020/01/20/zero.html) Travis Downs provides disects C++'s `std::fill` performance profile on gcc, comparing it among others to `memset(3)`. Even though `memset(3)` outperforms `std::fill` in their tests, the author notes the following:
> That the optimization fails, perhaps unexpectedly, in some cases is unfortunate but it’s nice that you can fix it yourself. [...] Do we throw out modern C++ idioms, at least where performance matters, for example by replacing std::fill with memset? I don’t think so.
Much of the article focuses on how how to fix the performance of `std::fill` by providing specializations for specific input. In Rust we don't have any dedicated methods to fill slices with values, so it either needs to be optimized at the MIR layer, or more likely rely on LLVM's optimizer.
By adding a dedicated method for filling slices with values it opens up the ability for us to in the future guarantee that e.g. `Vec<u8>` will always optimize to `memset` even in debug mode. Or perhaps provide stronger guarantees about memory when zeroing values when a certain flag is passed. But regardless of that, it improves general ergonomics of working with slices by providing a dedicated method with documentation and examples.
## References
- [slice-fill prototype on docs.rs](https://docs.rs/slice-fill/1.0.1/slice_fill/)
- [The Hunt For The Fastest Zero](https://travisdowns.github.io/blog/2020/01/20/zero.html)
- [Safe memset for slices](https://github.com/rust-lang/rfcs/issues/2067)
- [C++20 std::fill](https://en.cppreference.com/w/cpp/algorithm/fill)
- [ASM output on Godbolt](https://godbolt.org/z/5-XU66)
Auto merge of #70272 - eddyb:type-of-impl-trait, r=nikomatsakis
typeck/type_of: let wfcheck handle generics in opaque types' substs.
I was working on #70164, and `type_of`'s handling of opaque types seemed to be, by far, the trickiest use of `Ty::walk`, but I believe it wasn't doing anything (see https://github.com/rust-lang/rust/pull/57896#discussion_r396064431 - I suspect, based on glancing at the PR discussion, that an early attempt was kept in, despite becoming just an overcomplicated way to do exactly the same as the previous simple type equality check).
I would've loved to remove `ResolvedOpaqueTy` (keep the `Ty` and lose the `Substs`), but it looks like the MIR borrowck part of the process needs that now, so it would've been added anyway since #57896, even if that PR hadn't happened.
<hr/>
In the process, I've moved the remaining substitution validation to `wfcheck`, which was already handling lifetimes, and kept only `delay_span_bug`s in `type_of`, as an insurance policy.
I've added tests for lifetime and const cases, they seem to be checked correctly now.
(and more uniform than they were in https://github.com/rust-lang/rust/issues/63063#issuecomment-602162804)
However, the quality of the errors is maybe a bit worse, and they don't trigger when there are other errors (not sure if this is due to compilation stop points or something more specific to one opaque type).
r? @nikomatsakis cc @matthewjasper @oli-obk @Aaron1011
Auto merge of #70136 - hermitcore:network_tcp, r=dtolnay
add basic IP support in HermitCore
- add initial version to support sockets
- use TcpStream as test case
- HermitCore uses smoltcp as IP stack for pure Rust applications
- further functionalities (e.g. UDP support) will be added step by step
- in principle, the current PR is a revision of #69404
LLVM supports placing the hash of source files inside the debug info.
This information can be used by a debugger to verify that the source code matches
the executable.
This change adds support for both hash algorithms supported by LLVM, MD5 and SHA1, controlled by a target option.
* DWARF only supports MD5
* LLVM IR supports MD5 and SHA1 (and SHA256 in LLVM 11).
* CodeView (.PDB) supports MD5, SHA1, and SHA256.
Fixes #68980.
Tracking issue: #70401
rustc dev guide PR with further details: https://github.com/rust-lang/rustc-dev-guide/pull/623
Auto merge of #70156 - michaelwoerister:incr-cgus, r=nikomatsakis
Make the rustc respect the `-C codegen-units` flag in incremental mode.
This PR implements (the as of yet unapproved) major change proposal at https://github.com/rust-lang/compiler-team/issues/245. See the description there for background and rationale.
The changes are pretty straightforward and should be easy to rebase if the proposal gets accepted at some point.
Auto merge of #70747 - Centril:rollup-2vx9bve, r=Centril
Rollup of 9 pull requests
Successful merges:
- #69860 (Use associated numeric consts in documentation)
- #70576 (Update the description of the ticket to point at RFC 1721)
- #70597 (Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new)
- #70640 (Hide `task_context` when lowering body)
- #70641 (Remove duplicated code in trait selection)
- #70707 (Remove unused graphviz emitter)
- #70720 (Place TLS initializers with relocations in .tdata)
- #70735 (Clean up E0502 explanation)
- #70741 (Add test for #59023)
Rollup merge of #70597 - vakaras:thread_new_double_free_bug_fix, r=Amanieu
Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new
While working on concurrency support for Miri, I found that the `libstd::syn::unix::Thread::new` method has two potential problems: double-free and undefined behaviour.
**Double-free** could occur if the following events happened (credit for pointing this out goes to @RalfJung):
1. The call to `pthread_create` successfully launched a new thread that executed to completion and deallocated `p`.
2. The call to `pthread_attr_destroy` returned a non-zero value causing the `assert_eq!` to panic.
3. Since `mem::forget(p)` was not yet executed, the destructor of `p` would be executed and cause a double-free.
As far as I understand, this code also violates the stacked-borrows aliasing rules and thus would result in **undefined behaviour** if these rules were adopted. The problem is that the ownership of `p` is passed to the newly created thread before the call to `mem::forget`. Since the call to `mem::forget` is still a call, it counts as a use of `p` and triggers UB.
This pull request changes the code to use `mem::ManuallyDrop` instead of `mem::forget`. As a consequence, in case of a panic, `p` would be potentially leaked, which while undesirable is probably better than double-free or undefined behaviour.
Rollup merge of #69860 - faern:use-assoc-int-consts, r=dtolnay
Use associated numeric consts in documentation
Now when the associated constants on int/float types are stabilized and the recommended way of accessing said constants (#68952). We can start using it in this repository, and recommend it via documentation example code.
This PR is the reincarnation of #67913 minus the actual adding + stabilization of said constants. (EDIT: Now it's only changing the documentation. So users will see the new consts, but we don't yet update the internal code)
Because of how fast bit rot happens to PRs that touch this many files, it does not try to replace 100% of the old usage of the constants in the entire repo, but a good chunk of them.
projects / rust.git / log