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.
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).
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.
r? `@nikic`
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.
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:
<details><summary>Code to reproduce</summary>
<p>
```rust
#![feature(rustc_attrs)]
#[rustc_must_implement_one_of(a, b)]
pub trait Trait {
fn req();
fn a(){ Self::b() }
fn b(){ Self::a() }
}
```
</p>
</details>
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.
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use full type name instead of just saying `impl Trait` in "captures lifetime" error
I think this is very useful, especially when there's >1 `impl Trait`, and it just means passing around a bit more info that we already have access to.
Remove erroneous E0133 code from an error message.
This error message is about `derive` and `packed`, but E0133 is for
"Unsafe code was used outside of an unsafe function or block".
r? ``@estebank``
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.
Restore `Opaque` behavior to coherence check
Fixes#99663.
This broke in 84c3fcd2a0. 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.
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?
r? ``@lcnr``
Sync rustc_codegen_cranelift
This time most of the changes are bugfixes. No exciting new features to report. Thanks `@matthiaskrgr` for reporting a bunch of crashes!
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
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: ();
bb0: {
Coverage::Expression(4294967295) = 1 - 2;
return;
}
...
}
```
Which also makes the initial instrumentation quite suspect, although
this pull request doesn't attempt to address that aspect directly.
Fixes#98833.
r? ``@wesleywiser`` ``@richkadel``
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
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.
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.
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)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Expose size_hint() for TokenStream's iterator
The iterator for `proc_macro::TokenStream` is a wrapper around a `Vec` iterator:
babff2211e/library/proc_macro/src/lib.rs (L363-L371)
so it can cheaply provide a perfectly precise size hint, with just a pointer subtraction:
babff2211e/library/alloc/src/vec/into_iter.rs (L170-L177)
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:
babff2211e/library/proc_macro/src/lib.rs (L20-L22)
correct the output of a `capacity` method example
The output of this example in std::alloc is different from which shown in the comment. I have tested it on both Linux and Windows.
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.
r? `@oli-obk`
Constify a few `(Partial)Ord` impls
Only a few `impl`s are constified for now, as #92257 has not landed in the bootstrap compiler yet and quite a few impls would need that fix.
This unblocks #92228, which unblocks marking iterator methods as `default_method_body_is_const`.
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.
r? `@petrochenkov`
