-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 5 pull requests #110940
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #110940
Conversation
Instead of skipping functions with internal ABIs, check that the signature doesn't contain any fn-ptr types with external ABIs that aren't FFI-safe. Signed-off-by: David Wood <[email protected]>
Remove an `unwrap` that assumed FFI-safe types in foreign fn-ptr types. Signed-off-by: David Wood <[email protected]>
Extend previous commit's support for checking for external fn-ptrs in internal fn types to report errors for multiple found fn-ptrs. Signed-off-by: David Wood <[email protected]>
Extend previous checks for external ABI fn-ptrs to use in internal statics, constants, type aliases and algebraic data types. Signed-off-by: David Wood <[email protected]>
`rustc_arena`.
…omez,jyn514,notriddle rustdoc: Add a new lint for broken inline code This patch adds `rustdoc::unescaped_backticks`, a new rustdoc lint that will detect broken inline code nodes. The lint woks by finding stray backticks and with some heuristics tries to guess where the second backtick might be missing. Here is how it looks: ```rust #![warn(rustdoc::unescaped_backticks)] /// `add(a, b) is the same as `add(b, a)`. pub fn add(a: i32, b: i32) -> i32 { a + b } ``` ```text warning: unescaped backtick --> src/lib.rs:3:41 | 3 | /// `add(a, b) is the same as `add(b, a)`. | ^ | help: a previous inline code might be longer than expected | 3 | /// `add(a, b)` is the same as `add(b, a)`. | + help: if you meant to use a literal backtick, escape it | 3 | /// `add(a, b) is the same as `add(b, a)\`. | + ``` If we can't get proper spans, for example if the doc comment comes from a macro expansion, we print the suggestion in help messages instead. Here's a [real-world example](https://docs.rs/tracing-subscriber/0.3.17/tracing_subscriber/layer/trait.Filter.html#method.max_level_hint): ```text warning: unescaped backtick --> /tracing-subscriber-0.3.17/src/layer/mod.rs:1400:9 | 1400 | / /// Returns an optional hint of the highest [verbosity level][level] that 1401 | | /// this `Filter` will enable. 1402 | | /// 1403 | | /// If this method returns a [`LevelFilter`], it will be used as a hint to ... | 1427 | | /// [`Interest`]: tracing_core::subscriber::Interest 1428 | | /// [rebuild]: tracing_core::callsite::rebuild_interest_cache | |_____________________________________________________________________^ | = help: a previous inline code might be longer than expected change: Therefore, if the `Filter will change the value returned by this to this: Therefore, if the `Filter` will change the value returned by this = help: if you meant to use a literal backtick, escape it change: [`rebuild_interest_cache`][rebuild] is called after the value of the max to this: [`rebuild_interest_cache\`][rebuild] is called after the value of the max ``` You can find more examples [here](https://gist.github.com/lukas-code/7678ddf5c608aee97b3a669de80d3465). A limitation of the current implementation is, that it cannot suggest removing misplaced backticks, for example [here](https://docs.rs/tikv-jemalloc-sys/0.5.3+5.3.0-patched/tikv_jemalloc_sys/fn.mallctl.html). The lint is allowed by default ~~and nightly-only~~ for now, ~~but without a feature gate. This is similar to how `rustdoc::invalid_html_tags` and `rustdoc::bare_urls` were handled.~~
…-fn-ptr-in-internal-abi-fn, r=jackh726 lint/ctypes: ext. abi fn-ptr in internal abi fn Fixes rust-lang#94223. - In the improper ctypes lint, instead of skipping functions with internal ABIs, check that the signature doesn't contain any fn-ptr types with external ABIs that aren't FFI-safe. - When computing the ABI for fn-ptr types, remove an `unwrap` that assumed FFI-safe types in foreign fn-ptr types. - I'm not certain that this is the correct approach.
…w-response, r=lcnr Clear response values for overflow in new solver When we have an overflow, return a trivial query response. This fixes an ICE with the code described in rust-lang#110544: ```rust trait Trait {} struct W<T>(T); impl<T, U> Trait for W<(W<T>, W<U>)> where W<T>: Trait, W<U>: Trait, {} fn impls<T: Trait>() {} fn main() { impls::<W<_>>() } ``` Where, while proving `W<?0>: Trait`, we overflow but still apply the query response of `?0 = (W<?1>, W<?2>)`. Then while re-processing the query to validate that our evaluation result was stable, we get a different query response that looks like `?1 = (W<?3>, W<?4>), ?2 = (W<?5>, W<?6>)`, and so we trigger the ICE. Also, by returning a trivial query response we also avoid the infinite-loop/OOM behavior of the old solver. r? ``@lcnr``
…c, r=notriddle rustdoc: Fix missing `repr` attribute in doc(inline) on foreign items Fixes rust-lang#110698. r? `@notriddle`
…=Nilstrieb Use `NonNull::new_unchecked` and `NonNull::len` in `rustc_arena`. This avoids a few extra dereferences as well as an `unwrap`. According to the docs for [`NonNull::len`](https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.len) this also ensures that: > This function is safe, even when the non-null raw slice cannot be dereferenced to a slice because the pointer does not have a valid address. I am also fairly sure that the `unwrap` is unneeded in this case, as the docs for [`Box::into_raw`](https://doc.rust-lang.org/std/boxed/struct.Box.html#method.into_raw) also state: > Consumes the Box, returning a wrapped raw pointer. **The pointer will be properly aligned and non-null.**
@bors r+ p=5 rollup=never |
⌛ Testing commit 3962bfd with merge 07979e5fff82e2024682a2d0e803f8fa1635ae31... |
💔 Test failed - checks-actions |
Seems flaky. @bors retry |
⌛ Testing commit 3962bfd with merge 69724c493b422ffb8d273809692abd4b42fe5e46... |
💔 Test failed - checks-actions |
@bors retry python setuptools issue |
Still an issue apparently. Should we wait a bit before retrying? |
@bors p=50 trying again, it's not obvious to me what might be the cause |
⌛ Testing commit 3962bfd with merge b990a9d4f5b729b712ca7fe15b4ae65d2b244fee... |
💔 Test failed - checks-actions |
☔ The latest upstream changes (presumably #110643) made this pull request unmergeable. Please resolve the merge conflicts. |
Successful merges:
repr
attribute in doc(inline) on foreign items #110901 (rustdoc: Fix missingrepr
attribute in doc(inline) on foreign items)NonNull::new_unchecked
andNonNull::len
inrustc_arena
. #110921 (UseNonNull::new_unchecked
andNonNull::len
inrustc_arena
.)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup