| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Accept additional user-defined syntax classes in fenced code blocks
Part of #79483.
This is a re-opening of https://github.com/rust-lang/rust/pull/79454 after a big update/cleanup. I also converted the syntax to pandoc as suggested by `@notriddle:` the idea is to be as compatible as possible with the existing instead of having our own syntax.
## Motivation
From the original issue: https://github.com/rust-lang/rust/issues/78917
> The technique used by `inline-c-rs` can be ported to other languages. It's just super fun to see C code inside Rust documentation that is also tested by `cargo doc`. I'm sure this technique can be used by other languages in the future.
Having custom CSS classes for syntax highlighting will allow tools like `highlight.js` to be used in order to provide highlighting for languages other than Rust while not increasing technical burden on rustdoc.
## What is the feature about?
In short, this PR changes two things, both related to codeblocks in doc comments in Rust documentation:
* Allow to disable generation of `language-*` CSS classes with the `custom` attribute.
* Add your own CSS classes to a code block so that you can use other tools to highlight them.
#### The `custom` attribute
Let's start with the new `custom` attribute: it will disable the generation of the `language-*` CSS class on the generated HTML code block. For example:
```rust
/// ```custom,c
/// int main(void) {
/// return 0;
/// }
/// ```
```
The generated HTML code block will not have `class="language-c"` because the `custom` attribute has been set. The `custom` attribute becomes especially useful with the other thing added by this feature: adding your own CSS classes.
#### Adding your own CSS classes
The second part of this feature is to allow users to add CSS classes themselves so that they can then add a JS library which will do it (like `highlight.js` or `prism.js`), allowing to support highlighting for other languages than Rust without increasing burden on rustdoc. To disable the automatic `language-*` CSS class generation, you need to use the `custom` attribute as well.
This allow users to write the following:
```rust
/// Some code block with `{class=language-c}` as the language string.
///
/// ```custom,{class=language-c}
/// int main(void) {
/// return 0;
/// }
/// ```
fn main() {}
```
This will notably produce the following HTML:
```html
<pre class="language-c">
int main(void) {
return 0;
}</pre>
```
Instead of:
```html
<pre class="rust rust-example-rendered">
<span class="ident">int</span> <span class="ident">main</span>(<span class="ident">void</span>) {
<span class="kw">return</span> <span class="number">0</span>;
}
</pre>
```
To be noted, we could have written `{.language-c}` to achieve the same result. `.` and `class=` have the same effect.
One last syntax point: content between parens (`(like this)`) is now considered as comment and is not taken into account at all.
In addition to this, I added an `unknown` field into `LangString` (the parsed code block "attribute") because of cases like this:
```rust
/// ```custom,class:language-c
/// main;
/// ```
pub fn foo() {}
```
Without this `unknown` field, it would generate in the DOM: `<pre class="language-class:language-c language-c">`, which is quite bad. So instead, it now stores all unknown tags into the `unknown` field and use the first one as "language". So in this case, since there is no unknown tag, it'll simply generate `<pre class="language-c">`. I added tests to cover this.
Finally, I added a parser for the codeblock attributes to make it much easier to maintain. It'll be pretty easy to extend.
As to why this syntax for adding attributes was picked: it's [Pandoc's syntax](https://pandoc.org/MANUAL.html#extension-fenced_code_attributes). Even if it seems clunkier in some cases, it's extensible, and most third-party Markdown renderers are smart enough to ignore Pandoc's brace-delimited attributes (from [this comment](https://github.com/rust-lang/rust/pull/110800#issuecomment-1522044456)).
## Raised concerns
#### It's not obvious when the `language-*` attribute generation will be added or not.
It is added by default. If you want to disable it, you will need to use the `custom` attribute.
#### Why not using HTML in markdown directly then?
Code examples in most languages are likely to contain `<`, `>`, `&` and `"` characters. These characters [require escaping](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pre) when written inside the `<pre>` element. Using the \`\`\` code blocks allows rustdoc to take care of escaping, which means doc authors can paste code samples directly without manually converting them to HTML.
cc `@poliorcetics`
r? `@notriddle`
|
|
Make useless_ptr_null_checks smarter about some std functions
This teaches the `useless_ptr_null_checks` lint that some std functions can't ever return null pointers, because they need to point to valid data, get references as input, etc.
This is achieved by introducing an `#[rustc_never_returns_null_ptr]` attribute and adding it to these std functions (gated behind bootstrap `cfg_attr`).
Later on, the attribute could maybe be used to tell LLVM that the returned pointer is never null. I don't expect much impact of that though, as the functions are pretty shallow and usually the input data is already never null.
Follow-up of PR #113657
Fixes #114442
|
|
`custom_code_classes_in_docs` feature
|
|
Rework `no_coverage` to `coverage(off)`
As discussed at the tail of https://github.com/rust-lang/rust/issues/84605 this replaces the `no_coverage` attribute with a `coverage` attribute that takes sub-parameters (currently `off` and `on`) to control the coverage instrumentation.
Allows future-proofing for things like `coverage(off, reason="Tested live", issue="#12345")` or similar.
|
|
add rustc_abi(assert_eq) to test some guaranteed or at least highly expected ABI compatibility guarantees
This new repr(transparent) test is super useful, it would have found https://github.com/rust-lang/rust/issues/115336 and found https://github.com/rust-lang/rust/issues/115404, https://github.com/rust-lang/rust/issues/115481, https://github.com/rust-lang/rust/issues/115509.
|
|
|
|
|
|
|
|
repr(transparent) cases
|
|
r=est31
Lint on invalid usage of `UnsafeCell::raw_get` in reference casting
This PR proposes to take into account `UnsafeCell::raw_get` method call for non-Freeze types for the `invalid_reference_casting` lint.
The goal of this is to catch those kind of invalid reference casting:
```rust
fn as_mut<T>(x: &T) -> &mut T {
unsafe { &mut *std::cell::UnsafeCell::raw_get(x as *const _ as *const _) }
//~^ ERROR casting `&T` to `&mut T` is undefined behavior
}
```
r? `@est31`
|
|
|
|
|
|
when terminating during unwinding, show the reason why
With this, the output on double-panic becomes something like that:
```
thread 'main' panicked at src/tools/miri/tests/fail/panic/double_panic.rs:15:5:
first
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at src/tools/miri/tests/fail/panic/double_panic.rs:10:9:
second
stack backtrace:
0: 0xbe273a - std::backtrace_rs::backtrace::miri::trace_unsynchronized::<&mut [closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/miri.rs:99:5
1: 0xbe22e6 - std::backtrace_rs::backtrace::miri::trace::<&mut [closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/miri.rs:62:14
2: 0xbe1086 - std::backtrace_rs::backtrace::trace_unsynchronized::<[closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
3: 0xba3afd - std::sys_common::backtrace::_print_fmt
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:67:5
4: 0xba2471 - <std::sys_common::backtrace::_print::DisplayBacktrace as std::fmt::Display>::fmt
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:44:22
5: 0xbcf754 - core::fmt::rt::Argument::<'_>::fmt
at /home/r/src/rust/rustc.3/library/core/src/fmt/rt.rs:138:9
6: 0x9b8f81 - std::fmt::write
at /home/r/src/rust/rustc.3/library/core/src/fmt/mod.rs:1094:17
7: 0x21391d - <std::sys::unix::stdio::Stderr as std::io::Write>::write_fmt
at /home/r/src/rust/rustc.3/library/std/src/io/mod.rs:1714:15
8: 0xba37b1 - std::sys_common::backtrace::_print
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:47:5
9: 0xba365b - std::sys_common::backtrace::print
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:34:9
10: 0x143c67 - std::panic_hook_with_disk_dump::{closure#1}
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:278:22
11: 0x144187 - std::panic_hook_with_disk_dump
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:312:9
12: 0x143659 - std::panicking::default_hook
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:239:5
13: 0x1482a7 - std::panicking::rust_panic_with_hook
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:729:13
14: 0x1475d5 - std::rt::begin_panic::<&str>::{closure#0}
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:650:9
15: 0xba496a - std::sys_common::backtrace::__rust_end_short_backtrace::<[closure@std::rt::begin_panic<&str>::{closure#0}], !>
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:170:18
16: 0x147599 - std::rt::begin_panic::<&str>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:649:12
17: 0x31916 - <Foo as std::ops::Drop>::drop
at src/tools/miri/tests/fail/panic/double_panic.rs:10:9
18: 0x1a2b5e - std::ptr::drop_in_place::<Foo> - shim(Some(Foo))
at /home/r/src/rust/rustc.3/library/core/src/ptr/mod.rs:497:1
19: 0x202bf - main
at src/tools/miri/tests/fail/panic/double_panic.rs:16:1
20: 0xcc6a8 - <fn() as std::ops::FnOnce<()>>::call_once - shim(fn())
at /home/r/src/rust/rustc.3/library/core/src/ops/function.rs:250:5
21: 0xba47d9 - std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:154:18
22: 0x141a6a - std::rt::lang_start::<()>::{closure#0}
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:166:18
23: 0xcca18 - std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once
at /home/r/src/rust/rustc.3/library/core/src/ops/function.rs:284:13
24: 0x146469 - std::panicking::try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:524:40
25: 0x145e09 - std::panicking::try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:488:19
26: 0x7b0ac - std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
at /home/r/src/rust/rustc.3/library/std/src/panic.rs:142:14
27: 0x14189b - std::rt::lang_start_internal::{closure#2}
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:148:48
28: 0x146481 - std::panicking::try::do_call::<[closure@std::rt::lang_start_internal::{closure#2}], isize>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:524:40
29: 0x145e2c - std::panicking::try::<isize, [closure@std::rt::lang_start_internal::{closure#2}]>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:488:19
30: 0x7b0d5 - std::panic::catch_unwind::<[closure@std::rt::lang_start_internal::{closure#2}], isize>
at /home/r/src/rust/rustc.3/library/std/src/panic.rs:142:14
31: 0x1418b0 - std::rt::lang_start_internal
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:148:20
32: 0x141a97 - std::rt::lang_start::<()>
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:165:17
thread 'main' panicked at /home/r/src/rust/rustc.3/library/core/src/panicking.rs:126:5:
panic in a destructor during cleanup
stack backtrace:
0: 0xe9f6d7 - std::backtrace_rs::backtrace::miri::trace_unsynchronized::<&mut [closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/miri.rs:99:5
1: 0xe9f27d - std::backtrace_rs::backtrace::miri::trace::<&mut [closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/miri.rs:62:14
2: 0xe9e016 - std::backtrace_rs::backtrace::trace_unsynchronized::<[closure@std::sys_common::backtrace::_print_fmt::{closure#1}]>
at /home/r/src/rust/rustc.3/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
3: 0xba3afd - std::sys_common::backtrace::_print_fmt
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:67:5
4: 0xba2471 - <std::sys_common::backtrace::_print::DisplayBacktrace as std::fmt::Display>::fmt
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:44:22
5: 0xbcf754 - core::fmt::rt::Argument::<'_>::fmt
at /home/r/src/rust/rustc.3/library/core/src/fmt/rt.rs:138:9
6: 0x9b8f81 - std::fmt::write
at /home/r/src/rust/rustc.3/library/core/src/fmt/mod.rs:1094:17
7: 0x4d0895 - <std::sys::unix::stdio::Stderr as std::io::Write>::write_fmt
at /home/r/src/rust/rustc.3/library/std/src/io/mod.rs:1714:15
8: 0xba37b1 - std::sys_common::backtrace::_print
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:47:5
9: 0xba365b - std::sys_common::backtrace::print
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:34:9
10: 0x400bd4 - std::panic_hook_with_disk_dump::{closure#1}
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:278:22
11: 0x144187 - std::panic_hook_with_disk_dump
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:312:9
12: 0x143659 - std::panicking::default_hook
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:239:5
13: 0x1482a7 - std::panicking::rust_panic_with_hook
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:729:13
14: 0x40403b - std::panicking::begin_panic_handler::{closure#0}
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:619:13
15: 0xe618b3 - std::sys_common::backtrace::__rust_end_short_backtrace::<[closure@std::panicking::begin_panic_handler::{closure#0}], !>
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:170:18
16: 0x403fc8 - std::panicking::begin_panic_handler
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:617:5
17: 0xee23e9 - core::panicking::panic_nounwind_fmt
at /home/r/src/rust/rustc.3/library/core/src/panicking.rs:96:14
18: 0xee29e6 - core::panicking::panic_nounwind
at /home/r/src/rust/rustc.3/library/core/src/panicking.rs:126:5
19: 0xee365e - core::panicking::panic_in_cleanup
at /home/r/src/rust/rustc.3/library/core/src/panicking.rs:206:5
20: 0x2028a - main
at src/tools/miri/tests/fail/panic/double_panic.rs:13:1
21: 0x3895ee - <fn() as std::ops::FnOnce<()>>::call_once - shim(fn())
at /home/r/src/rust/rustc.3/library/core/src/ops/function.rs:250:5
22: 0xe61725 - std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /home/r/src/rust/rustc.3/library/std/src/sys_common/backtrace.rs:154:18
23: 0x3fe9aa - std::rt::lang_start::<()>::{closure#0}
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:166:18
24: 0x389962 - std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once
at /home/r/src/rust/rustc.3/library/core/src/ops/function.rs:284:13
25: 0x4033b9 - std::panicking::try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:524:40
26: 0x402d58 - std::panicking::try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:488:19
27: 0x337ff7 - std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>
at /home/r/src/rust/rustc.3/library/std/src/panic.rs:142:14
28: 0x3fe7e7 - std::rt::lang_start_internal::{closure#2}
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:148:48
29: 0x4033d6 - std::panicking::try::do_call::<[closure@std::rt::lang_start_internal::{closure#2}], isize>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:524:40
30: 0x402d7f - std::panicking::try::<isize, [closure@std::rt::lang_start_internal::{closure#2}]>
at /home/r/src/rust/rustc.3/library/std/src/panicking.rs:488:19
31: 0x338028 - std::panic::catch_unwind::<[closure@std::rt::lang_start_internal::{closure#2}], isize>
at /home/r/src/rust/rustc.3/library/std/src/panic.rs:142:14
32: 0x1418b0 - std::rt::lang_start_internal
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:148:20
33: 0x3fe9dc - std::rt::lang_start::<()>
at /home/r/src/rust/rustc.3/library/std/src/rt.rs:165:17
thread caused non-unwinding panic. aborting.
```
If we also land https://github.com/rust-lang/rust/pull/115020, the 2nd backtrace disappears, hopefully making the "panic in a destructor during cleanup" easier to see.
Fixes https://github.com/rust-lang/rust/issues/114954.
|
|
|
|
|
|
Parse unnamed fields and anonymous structs or unions (no-recovery)
It is part of #114782 which implements #49804. Only parse anonymous structs or unions in struct field definition positions.
r? `@petrochenkov`
|
|
|
|
Anonymous structs or unions are only allowed in struct field
definitions.
Co-authored-by: carbotaniuman <41451839+carbotaniuman@users.noreply.github.com>
|
|
|
|
Fix ABI flags in RISC-V/LoongArch ELF file generated by rustc
Fix #114153
It turns out the current way to set these flags are completely wrong. In LLVM the target ABI is used instead of target features to determine these flags.
Not sure how to write a test though. Or maybe a test isn't necessary because this affects only those touching target json?
r? `@Nilstrieb`
|
|
This way is possible to write inline assembly code aware of it.
|
|
|
|
r=est31
Improve `invalid_reference_casting` lint
This PR improves the `invalid_reference_casting` lint:
- by considering an unlimited number of casts instead only const to mut ptr
- by also considering ptr-to-integer and integer-to-ptr casts
- by also taking into account [`ptr::cast`](https://doc.rust-lang.org/std/primitive.pointer.html#method.cast), [`ptr::cast`](https://doc.rust-lang.org/std/primitive.pointer.html#method.cast-1) and [`ptr::cast_const`](https://doc.rust-lang.org/std/primitive.pointer.html#method.cast_const)
Most of this improvements comes from skimming Github Code Search result for [`&mut \*.*as \*const`](https://github.com/search?q=lang%3Arust+%2F%26mut+%5C*.*as+%5C*const%2F&type=code)
r? ``@est31`` (maybe)
|
|
|
|
|
|
Similar to prior support added for the mips430, avr, and x86 targets
this change implements the rough equivalent of clang's
[`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling
e.g.
```rust
static mut CNT: usize = 0;
pub extern "riscv-interrupt-m" fn isr_m() {
unsafe {
CNT += 1;
}
}
```
to produce highly effective assembly like:
```asm
pub extern "riscv-interrupt-m" fn isr_m() {
420003a0: 1141 addi sp,sp,-16
unsafe {
CNT += 1;
420003a2: c62a sw a0,12(sp)
420003a4: c42e sw a1,8(sp)
420003a6: 3fc80537 lui a0,0x3fc80
420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0>
420003ae: 0585 addi a1,a1,1
420003b0: 62b52e23 sw a1,1596(a0)
}
}
420003b4: 4532 lw a0,12(sp)
420003b6: 45a2 lw a1,8(sp)
420003b8: 0141 addi sp,sp,16
420003ba: 30200073 mret
```
(disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`)
This outcome is superior to hand-coded interrupt routines which, lacking
visibility into any non-assembly body of the interrupt handler, have to
be very conservative and save the [entire CPU state to the stack
frame][full-frame-save]. By instead asking LLVM to only save the
registers that it uses, we defer the decision to the tool with the best
context: it can more accurately account for the cost of spills if it
knows that every additional register used is already at the cost of an
implicit spill.
At the LLVM level, this is apparently [implemented by] marking every
register as "[callee-save]," matching the semantics of an interrupt
handler nicely (it has to leave the CPU state just as it found it after
its `{m|s}ret`).
This approach is not suitable for every interrupt handler, as it makes
no attempt to e.g. save the state in a user-accessible stack frame. For
a full discussion of those challenges and tradeoffs, please refer to
[the interrupt calling conventions RFC][rfc].
Inside rustc, this implementation differs from prior art because LLVM
does not expose the "all-saved" function flavor as a calling convention
directly, instead preferring to use an attribute that allows for
differentiating between "machine-mode" and "superivsor-mode" interrupts.
Finally, some effort has been made to guide those who may not yet be
aware of the differences between machine-mode and supervisor-mode
interrupts as to why no `riscv-interrupt` calling convention is exposed
through rustc, and similarly for why `riscv-interrupt-u` makes no
appearance (as it would complicate future LLVM upgrades).
[clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v
[full-frame-save]: https://github.com/esp-rs/esp-riscv-rt/blob/9281af2ecffe13e40992917316f36920c26acaf3/src/lib.rs#L440-L469
[implemented by]: https://github.com/llvm/llvm-project/blob/b7fb2a3fec7c187d58a6d338ab512d9173bca987/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp#L61-L67
[callee-save]: https://github.com/llvm/llvm-project/blob/973f1fe7a8591c7af148e573491ab68cc15b6ecf/llvm/lib/Target/RISCV/RISCVCallingConv.td#L30-L37
[rfc]: https://github.com/rust-lang/rfcs/pull/3246
|
|
|
|
It was added by #113657 for its purposes.
Now it is not used any more, remove it,
as we use the attr now.
|
|
And look for it in the useless_ptr_null_checks lint
|
|
Add separate feature gate for async fn track caller
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately.
Fixes #110009
|
|
This patch adds a feature gate `async_fn_track_caller` that is separate from `closure_track_caller`. This is to allow enabling `async_fn_track_caller` separately.
Fixes #110009
|
|
|
|
Add simd_bswap, simd_bitreverse, simd_ctlz, and simd_cttz intrinsics
cc `@workingjubilee`
|
|
|
|
Co-authored-by: est31 <est31@users.noreply.github.com>
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com>
|
|
|
|
|
|
|
|
"no method" errors on standard library types
The standard library developer can annotate methods on e.g.
`BTreeSet::push` with `#[rustc_confusables("insert")]`. When the user
mistypes `btreeset.push()`, `BTreeSet::insert` will be suggested if
there are no other candidates to suggest.
|
|
|
|
Uplift `clippy::fn_null_check` lint
This PR aims at uplifting the `clippy::fn_null_check` lint into rustc.
## `incorrect_fn_null_checks`
(warn-by-default)
The `incorrect_fn_null_checks` lint checks for expression that checks if a function pointer is null.
### Example
```rust
let fn_ptr: fn() = /* somehow obtained nullable function pointer */
if (fn_ptr as *const ()).is_null() { /* ... */ }
```
### Explanation
Function pointers are assumed to be non-null, checking for their nullity is incorrect.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
|
|
|
|
|
|
|
|
privacy: Type privacy lints fixes and cleanups
See individual commits.
Follow up to https://github.com/rust-lang/rust/pull/111801.
|
|
Add `lazy_type_alias` feature gate
Add the `type_alias_type` to be able to have the weak alias used without restrictions.
Part of #112792.
cc `@compiler-errors`
r? `@oli-obk`
|
|
|
|
Syntactically accept `become` expressions (explicit tail calls experiment)
This adds `ast::ExprKind::Become`, implements parsing and properly gates the feature.
cc `@scottmcm`
|
|
Add `implement_via_object` to `rustc_deny_explicit_impl` to control object candidate assembly
Some built-in traits are special, since they are used to prove facts about the program that are important for later phases of compilation such as codegen and CTFE. For example, the `Unsize` trait is used to assert to the compiler that we are able to unsize a type into another type. It doesn't have any methods because it doesn't actually *instruct* the compiler how to do this unsizing, but this is later used (alongside an exhaustive match of combinations of unsizeable types) during codegen to generate unsize coercion code.
Due to this, these built-in traits are incompatible with the type erasure provided by object types. For example, the existence of `dyn Unsize<T>` does not mean that the compiler is able to unsize `Box<dyn Unsize<T>>` into `Box<T>`, since `Unsize` is a *witness* to the fact that a type can be unsized, and it doesn't actually encode that unsizing operation in its vtable as mentioned above.
The old trait solver gets around this fact by having complex control flow that never considers object bounds for certain built-in traits:
https://github.com/rust-lang/rust/blob/2f896da247e0ee8f0bef7cd7c54cfbea255b9f68/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs#L61-L132
However, candidate assembly in the new solver is much more lovely, and I'd hate to add this list of opt-out cases into the new solver. Instead of maintaining this complex and hard-coded control flow, instead we can make this a property of the trait via a built-in attribute. We already have such a build attribute that's applied to every single trait that we care about: `rustc_deny_explicit_impl`. This PR adds `implement_via_object` as a meta-item to that attribute that allows us to opt a trait out of object-bound candidate assembly as well.
r? `@lcnr`
|
