summary refs log tree commit diff
path: root/tests/rustdoc-js-std/parser-errors.js
diff options
context:
space:
mode:
authorTrevor Gross <tmgross@umich.edu>2024-11-14 14:17:20 -0600
committerTrevor Gross <tmgross@umich.edu>2024-11-14 16:18:41 -0600
commit5d818914af2760972943db448d2a08de27900c96 (patch)
treeb2b08ac4e528dd14c591957513adc0a212e3e821 /tests/rustdoc-js-std/parser-errors.js
parentb77dbbd4fd2ed4083635f74612aa25b4be80fc43 (diff)
downloadrust-5d818914af2760972943db448d2a08de27900c96.tar.gz
rust-5d818914af2760972943db448d2a08de27900c96.zip
Always inline functions signatures containing `f16` or `f128`
There are a handful of tier 2 and tier 3 targets that cause a LLVM crash
or linker error when generating code that contains `f16` or `f128`. The
cranelift backend also does not support these types. To work around
this, every function in `std` or `core` that contains these types must
be marked `#[inline]` in order to avoid sending any code to the backend
unless specifically requested.

However, this is inconvenient and easy to forget. Introduce a check for
these types in the frontend that automatically inlines any function
signatures that take or return `f16` or `f128`.

Note that this is not a perfect fix because it does not account for the
types being passed by reference or as members of aggregate types, but
this is sufficient for what is currently needed in the standard library.

Fixes: https://github.com/rust-lang/rust/issues/133035
Closes: https://github.com/rust-lang/rust/pull/133037
Diffstat (limited to 'tests/rustdoc-js-std/parser-errors.js')
0 files changed, 0 insertions, 0 deletions