Commit Graph

252 Commits

Author SHA1 Message Date
chenx97
d3727148a0 support for mips32r6 as a target_arch value 2023-07-18 18:58:18 +08:00
chenx97
c6e03cd951 support for mips64r6 as a target_arch value 2023-07-18 18:58:18 +08:00
Nicholas Nethercote
b52f9eb6ca Introduce MonoItemData.
It replaces `(Linkage, Visibility)`, making the code nicer. Plus the
next commit will add another field.
2023-07-17 08:44:48 +10:00
Mahdi Dibaiee
e55583c4b8 refactor(rustc_middle): Substs -> GenericArg 2023-07-14 13:27:35 +01:00
Boxy
12138b8e5e Move TyCtxt::mk_x to Ty::new_x where applicable 2023-07-05 20:27:07 +01:00
Zalathar
9c430d38cf Remove trait CoverageInfoMethods, since non-LLVM backends don't need it
These methods are only ever called from within `rustc_codegen_llvm`, so they
can just be declared there as well.
2023-07-05 20:40:40 +10:00
Zalathar
4169d0f756 Narrow trait CoverageInfoBuilderMethods down to just one method
This effectively inlines most of `FunctionCx::codegen_coverage` into the LLVM
implementation of `CoverageInfoBuilderMethods`.
2023-07-05 20:40:39 +10:00
bors
fba636a387 Auto merge of #112814 - antoyo:sync-cg_gcc-2023-06-19, r=bjorn3
Sync rustc_codegen_gcc 2023/06/19

Hi.
This is a sync of the rustc_codegen_gcc subtree.
Thanks.
2023-06-22 02:11:08 +00:00
Michael Goulet
935452b619
Rollup merge of #112499 - tgross35:py-ruff-fixes, r=Mark-Simulacrum
Fix python linting errors

These were flagged by `ruff`, run using the config in https://github.com/rust-lang/rust/pull/112482
2023-06-19 17:53:34 -07:00
Antoni Boucher
f78096f57e Update Cargo.lock 2023-06-19 20:44:01 -04:00
Antoni Boucher
4d96893d85 Merge commit '1bbee3e217d75e7bc3bfe5d8c1b35e776fce96e6' into sync-cg_gcc-2023-06-19 2023-06-19 18:51:02 -04:00
bors
a8a29070f0 Auto merge of #100036 - DrMeepster:box_free_free_box, r=oli-obk
Remove `box_free` lang item

This PR removes the `box_free` lang item, replacing it with `Box`'s `Drop` impl. Box dropping is still slightly magic because the contained value is still dropped by the compiler.
2023-06-17 16:10:57 +00:00
Trevor Gross
22d00dcd47 Apply changes to fix python linting errors 2023-06-16 20:56:01 -04:00
DrMeepster
a5c6cb888e remove box_free and replace with drop impl 2023-06-16 13:41:06 -07:00
DonoughLiu
204bfb6a8c Support 128-bit enum variant in debuginfo codegen 2023-06-10 03:39:24 +08:00
Andrew Xie
204e2bf5a4 Updated cranelift codegen to reflect modified trait signature 2023-06-04 21:54:38 -04:00
Deadbeef
4f83717cf7 Use translatable diagnostics in rustc_const_eval 2023-06-01 14:45:18 +00:00
Scott McMurray
bf36193ef6 Add a distinct OperandValue::ZeroSized variant for ZSTs
These tend to have special handling in a bunch of places anyway, so the variant helps remember that.  And I think it's easier to grok than non-Scalar Aggregates sometimes being `Immediates` (like I got wrong and caused 109992).  As a minor bonus, it means we don't need to generate poison LLVM values for them to pass around in `OperandValue::Immediate`s.
2023-05-31 19:10:28 -07:00
bors
3266c36624 Auto merge of #111768 - oli-obk:pair_const_llvm, r=cjgillot
Optimize scalar and scalar pair representations loaded from ByRef in llvm

in https://github.com/rust-lang/rust/pull/105653 I noticed that we were generating suboptimal LLVM IR if we had a `ConstValue::ByRef` that could be represented by a `ScalarPair`. Before https://github.com/rust-lang/rust/pull/105653 this is probably rare, but after it, every slice will go down this suboptimal code path that requires LLVM to untangle a bunch of indirections and translate static allocations that are only used once to read a scalar pair from.
2023-05-30 10:31:10 +00:00
Oli Scherer
164d041e30 Stop creating intermediate places just to immediate convert them to operands 2023-05-26 15:01:29 +00:00
clubby789
f97fddab91 Ensure Fluent messages are in alphabetical order 2023-05-25 23:49:35 +00:00
bors
a2b1646c59 Auto merge of #86844 - bjorn3:global_alloc_improvements, r=pnkfelix
Support #[global_allocator] without the allocator shim

This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as `--emit obj` doesn't create an allocator shim.

Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once `#![feature(default_alloc_error_handler)]` becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either `--cfg no_global_oom_handling` for liballoc (like rust-for-linux) or `--gc-sections` no references to the oom error handler will exist.

To avoid this feature being insta-stable, you will have to define `__rust_no_alloc_shim_is_unstable` to avoid linker errors.

(Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the `__rust_no_alloc_shim_is_unstable` symbol requirement should prevent unintended dependence on this unstable feature.)
2023-05-25 16:59:57 +00:00
John Kåre Alsaker
fff20a703d Move expansion of query macros in rustc_middle to rustc_middle::query 2023-05-15 08:49:13 +02:00
bjorn3
66982a383b Prevent insta-stable no alloc shim support
You will need to add the following as replacement for the old __rust_*
definitions when not using the alloc shim.

    #[no_mangle]
    static __rust_no_alloc_shim_is_unstable: u8 = 0;
2023-05-11 14:35:09 +00:00
bjorn3
145b0574ef Use global_fn_name instead of format! 2023-05-11 14:35:09 +00:00
bjorn3
6ba7c5db07 Split AllocatorKind::fn_name in global_fn_name and default_fn_name 2023-05-11 14:35:08 +00:00
bjorn3
4ce20663f7 Don't use an allocator shim for #[global_allocator]
This makes it possible to use liballoc/libstd in combination with
`--emit obj` if you use `#[global_allocator]`. Making it work for the
default libstd allocator would require weak functions, which are not
well supported on all systems.
2023-05-11 14:23:31 +00:00
Gary Guo
91afde57a2 Add todo for filter landing pad 2023-05-07 12:38:47 +01:00
Gary Guo
47171e0c50 Use landingpad filter to encode aborting landing pad 2023-05-07 12:35:54 +01:00
Manish Goregaokar
38bbc39895
Rollup merge of #105452 - rcvalle:rust-cfi-3, r=bjorn3
Add cross-language LLVM CFI support to the Rust compiler

This PR adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395).

It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653.

Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto).

Thank you again, ``@bjorn3,`` ``@nikic,`` ``@samitolvanen,`` and the Rust community for all the help!
2023-05-03 16:42:48 -07:00
Ramon de C Valle
004aa15b47 Add cross-language LLVM CFI support to the Rust compiler
This commit adds cross-language LLVM Control Flow Integrity (CFI)
support to the Rust compiler by adding the
`-Zsanitizer-cfi-normalize-integers` option to be used with Clang
`-fsanitize-cfi-icall-normalize-integers` for normalizing integer types
(see https://reviews.llvm.org/D139395).

It provides forward-edge control flow protection for C or C++ and Rust
-compiled code "mixed binaries" (i.e., for when C or C++ and Rust
-compiled code share the same virtual address space). For more
information about LLVM CFI and cross-language LLVM CFI support for the
Rust compiler, see design document in the tracking issue #89653.

Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and
-Zsanitizer-cfi-normalize-integers, and requires proper (i.e.,
non-rustc) LTO (i.e., -Clinker-plugin-lto).
2023-05-03 22:41:29 +00:00
Boxy
f04b8fe0af rename needs_infer to has_infer 2023-04-27 08:35:19 +01:00
bors
999e6e5afb Auto merge of #101069 - zhaixiaojuan:loongarch64-inline-asm, r=Amanieu
Add loongarch64 asm! support
2023-04-25 09:18:58 +00:00
zhaixiaojuan
5f2fa4c11d Add loongarch64 asm! support 2023-04-25 14:15:31 +08:00
Matthias Krüger
f54dbe6e31 Revert "Remove #[alloc_error_handler] from the compiler and library"
This reverts commit abc0660118.
2023-04-25 00:08:35 +02:00
bors
39cf520299 Auto merge of #109507 - Amanieu:panic-oom-payload, r=davidtwco
Report allocation errors as panics

OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`.

This should be review one commit at a time:
- The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics.
- The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API.

ACP: https://github.com/rust-lang/libs-team/issues/192

Closes #51540
Closes #51245
2023-04-22 12:27:45 +00:00
Nilstrieb
b5d3d970fa Add rustc_fluent_macro to decouple fluent from rustc_macros
Fluent, with all the icu4x it brings in, takes quite some time to
compile. `fluent_messages!` is only needed in further downstream rustc
crates, but is blocking more upstream crates like `rustc_index`. By
splitting it out, we allow `rustc_macros` to be compiled earlier, which
speeds up `x check compiler` by about 5 seconds (and even more after the
needless dependency on `serde_json` is removed from
`rustc_data_structures`).
2023-04-18 18:56:22 +00:00
Amanieu d'Antras
abc0660118 Remove #[alloc_error_handler] from the compiler and library 2023-04-16 08:35:50 -07:00
bors
e14b81f10d Auto merge of #109989 - ids1024:m68k-asm, r=Amanieu
Add inline assembly support for m68k

I believe this should be correct, to the extent I understand the logic around inline assembly. M68k is fairly straightforward here, other than having separate address registers.
2023-04-13 11:41:57 +00:00
Ian Douglas Scott
2ac8dee44f Add inline assembly support for m68k 2023-04-12 17:58:15 -07:00
Michael Goulet
4a24aab220
Rollup merge of #96971 - zhaixiaojuan:master, r=wesleywiser
Initial support for loongarch64-unknown-linux-gnu

Hi, We hope to add a new port in rust for LoongArch.

LoongArch intro
LoongArch is a RISC style ISA which is independently designed by Loongson
Technology in China. It is divided into two versions, the 32-bit version (LA32)
and the 64-bit version (LA64). LA64 applications have application-level
backward binary compatibility with LA32 applications. LoongArch is composed of
a basic part (Loongson Base) and an expanded part. The expansion part includes
Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).

Currently the LA464 processor core supports LoongArch ISA and the Loongson
3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit
high-performance processor core. It can be used as a single core for high-end
embedded and desktop applications, or as a basic processor core to form an
on-chip multi-core system for server and high-performance machine applications.

Documentations:
ISA:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
ABI:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
More docs can be found at:
https://loongson.github.io/LoongArch-Documentation/README-EN.html

Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally.
I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
2023-04-11 20:28:45 -07:00
zhaixiaojuan
a3f0046142 Define MIN_ALIGN for loongarch64 2023-04-08 00:09:54 +08:00
Ulrich Weigand
9cd1a316aa Update gccjit and remove libc 0.1 dependency 2023-03-30 18:30:56 +02:00
Nikita Popov
30331828cb Use poison instead of undef
In cases where it is legal, we should prefer poison values over
undef values.

This replaces undef with poison for aggregate construction and
for uninhabited types. There are more places where we can likely
use poison, but I wanted to stay conservative to start with.

In particular the aggregate case is important for newer LLVM
versions, which are not able to handle an undef base value during
early optimization due to poison-propagation concerns.
2023-03-16 15:07:04 +01:00
clubby789
dd7df04e16 Remove uses of box_syntax in rustc and tools 2023-03-12 13:19:46 +00:00
est31
7e2ecb3cd8 Simplify message paths
This makes it easier to open the messages file while developing on features.

The commit was the result of automatted changes:

for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done

for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
2023-03-11 22:51:57 +01:00
Pietro Albini
b33172a2df
replace legacy copyright annotations in submodules 2023-03-09 12:24:47 +01:00
Matthias Krüger
c21a640c5a
Rollup merge of #108783 - antoyo:sync-cg_gcc-2023-03-04, r=cjgillot
Sync rustc_codegen_gcc 2023/03/04

Hi.
This sync all the changes from rustc_codegen_gcc.
Thanks for the review.
2023-03-07 19:57:45 +01:00
bors
0a3b557d52 Auto merge of #95317 - Jules-Bertholet:round_ties_to_even, r=pnkfelix,m-ou-se,scottmcm
Add `round_ties_even` to `f32` and `f64`

Tracking issue: #96710

Redux of #82273. See also #55107

Adds a new method, `round_ties_even`, to `f32` and `f64`, that rounds the float to the nearest integer , rounding halfway cases to the number with an even least significant bit. Uses the `roundeven` LLVM intrinsic to do this.

Of the five IEEE 754 rounding modes, this is the only one that doesn't already have a round-to-integer function exposed by Rust (others are `round`, `floor`, `ceil`, and `trunc`).  Ties-to-even is also the rounding mode used for int-to-float and float-to-float `as` casts, as well as float arithmentic operations. So not having an explicit rounding method for it seems like an oversight.

Bikeshed: this PR currently uses `round_ties_even` for the name of the method. But maybe `round_ties_to_even` is better, or `round_even`, or `round_to_even`?
2023-03-07 09:43:12 +00:00
Antoni Boucher
2c0c25dcc1 Fix for diagnostics 2023-03-05 12:31:16 -05:00