Auto merge of #99792 - JohnTitor:rollup-20i7ewx, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #98583 (Stabilize Windows `FileTypeExt` with `is_symlink_dir` and `is_symlink_file`)
- #99698 (Prefer visibility map parents that are not `doc(hidden)` first)
- #99700 (Add a clickable link to the layout section)
- #99712 (passes: port more of `check_attr` module)
- #99759 (Remove dead code from cg_llvm)
- #99765 (Don't build std for *-uefi targets)
- #99771 (Update pulldown-cmark version to 0.9.2 (fixes url encoding for some chars))
- #99775 (rustdoc: do not allocate String when writing path full name)
Rollup merge of #99700 - est31:rustdoc_layout_heading, r=GuillaumeGomez
Add a clickable link to the layout section
The layout section (activated by `--show-type-layout`) is currently not linkable to (outside of chrome's link to text feature). This PR makes it linkable via `#layout`.
Rollup merge of #99698 - compiler-errors:no-doc-hidden, r=cjgillot
Prefer visibility map parents that are not `doc(hidden)` first
Far simpler approach to #98876.
This only fixes the case where the parent is `doc(hidden)`, not where the child is `doc(hidden)` since I don't know how to get the attrs on the import statement given a `ModChild`... I'll try to follow up with that, but this is a good first step.
Rollup merge of #98583 - joshtriplett:stabilize-windows-symlink-types, r=thomcc
Stabilize Windows `FileTypeExt` with `is_symlink_dir` and `is_symlink_file`
These calls allow detecting whether a symlink is a file or a directory,
a distinction Windows maintains, and one important to software that
wants to do further operations on the symlink (e.g. removing it).
On znver2 the default impl seems to be slow due to different inlining decisions. It goes through `core::array::iter_next_chunk`
which has a deep call tree.
Auto merge of #99574 - durin42:allocator-patch-redux, r=nikic
codegen: use new {re,de,}allocator annotations in llvm
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
Rollup merge of #99724 - ehuss:fix-broken-links-fragment, r=Dylan-DPC
Fix some broken link fragments.
An exception for link fragments starting with `-` was added in #49590. However, it is not clear what issues were encountered at the time. Perhaps those were fixed in the meantime.
This removes the exception, and fixes a couple of broken links that were skipped due to it.
Rollup merge of #99235 - WaffleLapkin:rustdoc_implement_support_for_must_implement, r=GuillaumeGomez
rustdoc: Add support for `#[rustc_must_implement_one_of]`
This PR adds support for `#[rustc_must_implement_one_of]` attribute added in #92164. There is a desire to eventually use this attribute of `Read`, so making it show up in docs is a good thing.
I "stole" the styling from cfg notes, not sure what would be a proper styling. Currently it looks like this:
Augie Fackler [Mon, 21 Mar 2022 19:30:54 +0000 (15:30 -0400)]
codegen: use new {re,de,}allocator annotations in llvm
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
While we're here, we also emit allocator attributes on
__rust_alloc_zeroed. This should allow LLVM to perform more
optimizations for zeroed blocks, and probably fixes #90032. [This
comment](https://github.com/rust-lang/rust/issues/24194#issuecomment-308791157)
mentions "weird UB-like behaviour with bitvec iterators in
rustc_data_structures" so we may need to back this change out if things
go wrong.
The new test cases require LLVM 15, so we copy them into LLVM
14-supporting versions, which we can delete when we drop LLVM 14.
Auto merge of #99753 - Dylan-DPC:rollup-k046940, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #99618 (handle consts with param/infer in `const_eval_resolve` better)
- #99666 (Restore `Opaque` behavior to coherence check)
- #99692 (interpret, ptr_offset_from: refactor and test too-far-apart check)
- #99739 (Remove erroneous E0133 code from an error message.)
- #99748 (Use full type name instead of just saying `impl Trait` in "captures lifetime" error)
Rollup merge of #99692 - RalfJung:too-far, r=oli-obk
interpret, ptr_offset_from: refactor and test too-far-apart check
We didn't have any tests for the "too far apart" message, and indeed that check mostly relied on the in-bounds check and was otherwise probably not entirely correct... so I rewrote that check, and it is before the in-bounds check so we can test it separately.
Rollup merge of #99666 - compiler-errors:issue-99663, r=lcnr
Restore `Opaque` behavior to coherence check
Fixes #99663.
This broke in 84c3fcd2a0285c06a682c9b064640084e4c7271b. I'm not exactly certain that adding this behavior back is necessarily correct, but at least the UI test I provided may stimulate some thoughts.
I think delaying a bug here is certainly not correct in the case of opaques -- if we want to change coherence behavior for opaques, then we should at least be emitting a new error.
Rollup merge of #99618 - compiler-errors:uhh-idk, r=lcnr
handle consts with param/infer in `const_eval_resolve` better
This PR addresses [this thread here](https://github.com/rust-lang/rust/pull/99449#discussion_r924141230). Was this the change you were looking for ``@lcnr?``
Interestingly, one test has begun to pass. Was that expected?
Auto merge of #99677 - pietroalbini:pa-fix-97786-perf-regression, r=Mark-Simulacrum
Remove new allocations from `imported_source_files`
https://github.com/rust-lang/rust/pull/97786 introduced a [large performance regression](https://github.com/rust-lang/rust/pull/97786#issuecomment-1176552836). After some local investigation it turns out the allocations performed by my change were the cause of the perf regression. This PR refactors my change to remove those allocations.
Auto merge of #99745 - JohnTitor:rollup-lvrie64, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #98211 (Implement `fs::get_path` for FreeBSD.)
- #99353 (Slightly improve mismatched GAT where clause error)
- #99593 (Suggest removing the tuple struct field for the unwrapped value)
- #99615 (Remove some explicit `self.infcx` for `FnCtxt`, which already derefs into `InferCtxt`)
- #99711 (Remove reachable coverage without counters)
- #99718 (Avoid `&str`/`Symbol` to `String` conversions)
- #99720 (Sync rustc_codegen_cranelift)
Rollup merge of #99711 - tmiasko:coverage, r=wesleywiser
Remove reachable coverage without counters
Remove reachable coverage without counters to maintain invariant that
either there is no coverage at all or there is a live coverage counter
left that provides the function source hash.
The motivating example would be a following closure:
```rust
let f = |x: bool| {
debug_assert!(x);
};
```
Which, with span changes from #93967, with disabled debug assertions,
after the final CFG simplifications but before removal of dead blocks,
gives rise to MIR:
```rust
fn main::{closure#0}(_1: &[closure@a.rs:2:13: 2:22], _2: bool) -> () {
debug x => _2;
let mut _0: ();
Rollup merge of #99615 - compiler-errors:remove-some-explicit-infcx, r=lcnr
Remove some explicit `self.infcx` for `FnCtxt`, which already derefs into `InferCtxt`
The use of `self.infcx.method_on_infcx` vs `self.method_on_infcx` when `self` is a `FnCtxt` is a bit inconsistent, so I'm moving some `self.infcx` usages I found to just use autoderef
Rollup merge of #99353 - compiler-errors:gat-where-clause-mismatch, r=cjgillot
Slightly improve mismatched GAT where clause error
This makes the error reporting a bit more standardized between `where` on GATs and functions.
cc #99206 (`@BoxyUwU),` don't want to mark this as as "fixed" because they're still not perfect, but this is still an improvement IMO so I want to land it incrementally.
regarding "consider adding where clause to trait definition", we don't actually do that for methods as far as i can tell? i could file an issue to look into that maybe.
Auto merge of #98989 - dpaoliello:rawdylibbin, r=michaelwoerister
Enable raw-dylib for bin crates
Fixes #93842
When `raw-dylib` is used in a `bin` crate, we need to collect all of the `raw-dylib` functions, generate the import library and add that to the linker command line.
I also changed the tests so that 1) the C++ dlls are created after the Rust dlls, thus there is no chance of accidentally using them in the Rust linking process and 2) disabled generating import libraries when building with MSVC.
Auto merge of #99735 - JohnTitor:rollup-d93jyr2, r=JohnTitor
Rollup of 9 pull requests
Successful merges:
- #92390 (Constify a few `(Partial)Ord` impls)
- #97077 (Simplify some code that depend on Deref)
- #98710 (correct the output of a `capacity` method example)
- #99084 (clarify how write_bytes can lead to UB due to invalid values)
- #99178 (Lighten up const_prop_lint, reusing const_prop)
- #99673 (don't ICE on invalid dyn calls)
- #99703 (Expose size_hint() for TokenStream's iterator)
- #99709 (`Inherited` always has `TypeckResults` available)
- #99713 (Fix sidebar background)
I need the size hint in syn (https://github.com/dtolnay/syn/blob/1.0.98/src/buffer.rs) to reduce allocations when converting TokenStream into syn's internal TokenBuffer representation.
Aside from `size_hint`, the other non-default methods in `std::vec::IntoIter`'s `Iterator` impl are `advance_by`, `count`, and `__iterator_get_unchecked`. I've included `count` in this PR since it is trivial. I did not include `__iterator_get_unchecked` because it is spoopy and I did not feel like dealing with that. Lastly, I did not include `advance_by` because that requires `feature(iter_advance_by)` (https://github.com/rust-lang/rust/issues/77404) and I noticed this comment at the top of libproc_macro:
Rollup merge of #97077 - ouz-a:Optimize-backend, r=oli-obk
Simplify some code that depend on Deref
Now that we can assume #97025 works, it's safe to expect Deref is always in the first place of projections. With this, I was able to simplify some code that depended on Deref's place in projections. When we are able to move Derefer before `ElaborateDrops` successfully we will be able to optimize more places.
Auto merge of #97313 - cjgillot:ast-lifetimes-anon, r=petrochenkov
Resolve function lifetime elision on the AST
~Based on https://github.com/rust-lang/rust/pull/97720~
Lifetime elision for functions is purely syntactic in nature, so can be resolved on the AST.
This PR replicates the elision logic and diagnostics on the AST, and replaces HIR-based resolution by a `delay_span_bug`.
This refactor allows for more consistent diagnostics, which don't have to guess the original code from HIR.
Tomasz Miąsko [Mon, 25 Jul 2022 00:00:00 +0000 (00:00 +0000)]
Remove reachable coverage without counters
Remove reachable coverage without counters to maintain invariant that
either there is no coverage at all or there is a live coverage counter
left that provides the function source hash.
The motivating example would be a following closure:
```rust
let f = |x: bool| {
debug_assert!(x);
};
```
Which, with span changes from #93967, with disabled debug assertions,
after the final CFG simplifications but before removal of dead blocks,
gives rise to MIR:
```rust
fn main::{closure#0}(_1: &[closure@a.rs:2:13: 2:22], _2: bool) -> () {
debug x => _2;
let mut _0: ();
Auto merge of #99707 - JohnTitor:rollup-74rb8vq, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #95040 (protect `std::io::Take::limit` from overflow in `read`)
- #95916 (kmc-solid: Use `libc::abort` to abort a program)
- #99494 (Use non-relocatable code in nofile-limit.rs test)
- #99581 (Improve error messages involving `derive` and `packed`.)
- #99643 (Add `sign-ext` target feature to the WASM target)
- #99659 (Use `VecMap::get` in `ConstraintLocator::check`)
- #99690 (add miri-track-caller to more intrinsic-exposing methods)
Rollup merge of #99690 - RalfJung:miri-track-caller, r=Mark-Simulacrum
add miri-track-caller to more intrinsic-exposing methods
Follow-up to https://github.com/rust-lang/rust/pull/98674: I went through the Miri test suite to find more functions that would benefit from Miri backtrace pruning, and this is what I found.
Basically anything that just exposes a potentially-UB intrinsic to the user should get this treatment.
Rollup merge of #99581 - nnethercote:improve-derive-packed-errors, r=estebank
Improve error messages involving `derive` and `packed`.
There are two errors involving `derive` and `packed`.
```
`#[derive]` can't be derived on a `#[repr(packed)]` struct with type or const parameters
`#[derive]` can't be derived on a `#[repr(packed)]` struct that does not derive Copy
```
The second one overstates things. It is possible to use derive on a
repr(packed) struct that doesn't derive Copy in two cases.
- If all the fields within the struct meet the required alignment: 1 for
`repr(packed)`, or `N` for `repr(packed(N))`.
- If `Default` is the only trait derived.
This commit improves things in a few ways.
- Changes the errors to say `this trait can't be derived on this ...`.
This is more accurate, because it's just *this* trait and *this*
packed struct that are a problem, not *all* derived traits on *all*
packed structs.
- Adds more details to the "ERROR" lines in the test case, enough to
distinguish between the two error messages.
- Adds more cases to the test case that don't cause errors, e.g. `Default`
derives.
- Uses a wider variety of builtin traits in the test case, for better coverage.
Rollup merge of #99494 - tmiasko:no-pie, r=Mark-Simulacrum
Use non-relocatable code in nofile-limit.rs test
To avoid using static-pie which is not essential to the test but which
was reported to cause problems on Void Linux where glibc is build
without support for static-pie.
Rollup merge of #95916 - solid-rs:feat-kmc-solid-abort, r=Mark-Simulacrum
kmc-solid: Use `libc::abort` to abort a program
This PR updates the target-specific abort subroutine for the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.
The current implementation uses a `hlt` instruction, which is the most direct way to notify a connected debugger but is not the most flexible way. This PR changes it to call the `abort` libc function, making it possible for a system designer to override its behavior as they see fit.
projects / rust.git / log