Commit Graph

952 Commits

Author SHA1 Message Date
bors
91cacb3faf Auto merge of #97512 - scottmcm:add-coldcc, r=nagisa,lcnr
Add support for emitting functions with `coldcc` to LLVM

The eventual goal is to try using this for things like the internal panicking stuff, to see whether it helps.
2022-06-07 08:12:45 +00:00
bors
bb55bd449e Auto merge of #95565 - jackh726:remove-borrowck-mode, r=nikomatsakis
Remove migrate borrowck mode

Closes #58781
Closes #43234

# Stabilization proposal

This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors, then MIR borrowck (NLL) never occurs. If there *aren't* any errors, then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program, this should not break any programs. It does, however, change diagnostics significantly and allows a slightly larger set of programs to compile.

Tracking issue: #43234
RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md
Version: 1.63 (2022-06-30 => beta, 2022-08-11 => stable).

## Motivation

Over time, the Rust borrow checker has become "smarter" and thus allowed more programs to compile. There have been three different implementations: AST borrowck, MIR borrowck, and polonius (well, in progress). Additionally, there is the "lexical region resolver", which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker, but does emit some errors.

The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017, work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017, for the most part. During 2018, efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into "migrate" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition.

In early 2019, migrate mode was turned on by default in the 2015 edition as well, but with MIR borrowck errors emitted as warnings. By late 2019, these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker.

In the period since, various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver.

While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics), those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff.

## What is stabilized

As said previously, this does not fundamentally change the landscape of accepted programs. However, there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)`, but not otherwise.

There are two notable patterns that are "fixed" by this stabilization. First, the `scoped_threads` feature, which is a continutation of a pre-1.0 API, can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second, actually seen in the standard library. In the `Extend` impl for `HashMap`, there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl.

As mentioned before, there are a large number of diagnostic differences. Most of them are better, but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general "lifetime may not live long enough" error. While this may *seem* bad, the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however, on paper, they end up being roughly the same with roughly the same kinds of solutions.

## What isn't stabilized

This PR does not completely remove the lexical region resolver. In the future, it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck.

## Tests

Many test outputs get updated by this PR. However, there are number of tests specifically geared towards NLL under `src/test/ui/nll`

## History

* On 2017-07-14, [tracking issue opened](https://github.com/rust-lang/rust/issues/43234)
* On 2017-07-20, [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271)
* On 2017-08-29, [RFC opened](https://github.com/rust-lang/rfcs/pull/2094)
* On 2017-11-16, [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825)
* On 2017-12-20, [NLL feature complete](https://github.com/rust-lang/rust/pull/46862)
* On 2018-07-07, [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083)
* On 2018-07-27, [Add migrate mode](https://github.com/rust-lang/rust/pull/52681)
* On 2019-04-22, [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114)
* On 2019-08-26, [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221)
* On 2019-08-27, [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)
2022-06-07 05:04:14 +00:00
SparrowLii
b3cd892ae1 Avoid creating SmallVecs in global_llvm_features 2022-06-06 18:05:07 +08:00
Jack Huey
410dcc9674 Fully stabilize NLL 2022-06-03 17:16:41 -04:00
Scott McMurray
e90be842fb Add support for emitting functions with coldcc in LLVM
The eventual goal is to try using this for things like the internal panicking stuff, to see whether it helps.
2022-05-30 00:19:23 -07:00
bors
bef2b7cd1c Auto merge of #97214 - Mark-Simulacrum:stage0-bump, r=pietroalbini
Finish bumping stage0

It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.

This now brings us to cfg-clean, with the exception of check-cfg-features in bootstrap;
I'd prefer to leave that for a separate PR at this time since it's likely to be more tricky.

cc https://github.com/rust-lang/rust/pull/97147#issuecomment-1132845061

r? `@pietroalbini`
2022-05-29 16:28:21 +00:00
bors
9d1aeaeb82 Auto merge of #94214 - nikic:rust-opaque-pointers, r=cuviper
Prepare Rust for opaque pointers

Fix one codegen bug with opaque pointers, and update our IR tests to accept both typed pointer and opaque pointer IR. This is a bit annoying, but unavoidable if we want decent test coverage on both LLVM 14 and LLVM 15.

This prepares Rust for when LLVM will enable opaque pointers by default.
2022-05-29 14:12:42 +00:00
bors
0f06824013 Auto merge of #97287 - compiler-errors:type-interner, r=jackh726,oli-obk
Move things to `rustc_type_ir`

Finishes some work proposed in https://github.com/rust-lang/compiler-team/issues/341.

r? `@ghost`
2022-05-29 08:20:13 +00:00
Guillaume Gomez
239287f013
Rollup merge of #97028 - ridwanabdillahi:pretty-printer, r=michaelwoerister
Add support for embedding pretty printers via `#[debugger_visualizer]` attribute

Initial support for [RFC 3191](https://github.com/rust-lang/rfcs/pull/3191) in PR https://github.com/rust-lang/rust/pull/91779 was scoped to supporting embedding NatVis files using a new attribute. This PR implements the pretty printer support as stated in the RFC mentioned above.

This change includes embedding pretty printers in the `.debug_gdb_scripts` just as the pretty printers for rustc are embedded today. Also added additional tests for embedded pretty printers. Additionally cleaned up error checking so all error checking is done up front regardless of the current target.

RFC: https://github.com/rust-lang/rfcs/pull/3191
2022-05-29 01:12:30 +02:00
Michael Goulet
34e05812e0 Fix TyKind lint, make consts no longer fn, etc 2022-05-28 11:38:22 -07:00
Michael Goulet
a056a953f0 Initial fixes on top of type interner commit 2022-05-28 11:38:22 -07:00
Nikita Popov
1ff051a9c5 Fix documentation of basic stack protector
A stack protector is used for N >= 8, not N > 8.
2022-05-28 10:43:36 +02:00
Mark Rousskov
b454991ac4 Finish bumping stage0
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
2022-05-27 07:36:17 -04:00
Nikita Popov
373789b059 Don't use global initializer if type does not match
This was relying on the presence of a bitcast to avoid using the
constant global initializer for a load using a different type.
With opaque pointers, we need to check this explicitly.
2022-05-25 17:28:58 +02:00
Tomasz Miąsko
f4c92cc4d1 rustc_codegen_ssa: cleanup AtomicOrdering
* Remove unused `NotAtomic` ordering.
* Rename `Monotonic` to `Relaxed` - a Rust specific name.
2022-05-25 10:34:35 +02:00
ridwanabdillahi
ab1f8ed2d9 Update documentation. 2022-05-24 11:22:14 -07:00
ridwanabdillahi
60458b97e7 Add support for embedding pretty printers via the #[debugger_visualizer] attribute. Add tests for embedding pretty printers and update documentation.
Ensure all error checking for `#[debugger_visualizer]` is done up front and not when the `debugger_visualizer` query is run.

Clean up potential ODR violations when embedding pretty printers into the `__rustc_debug_gdb_scripts_section__` section.

Respond to PR comments and update documentation.
2022-05-24 11:14:48 -07:00
Jacob Pratt
49c82f31a8
Remove crate visibility usage in compiler 2022-05-20 20:04:54 -04:00
Michael Woerister
6411fef3ab Properly apply path prefix remapping paths emitted into debuginfo. 2022-05-18 12:19:01 +02:00
Connor Horman
658be0d1cf Add tmm_reg clobbers 2022-05-16 20:15:06 -04:00
Mateusz Mikuła
60361f2ca3 Add LLVM based mingw-w64 targets 2022-05-13 20:14:15 +02:00
bors
481db40311 Auto merge of #95562 - lcnr:attr-no-encode, r=davidtwco
don't encode only locally used attrs

Part of https://github.com/rust-lang/compiler-team/issues/505.

We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse `get_attrs` now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a method `fn get_attrs_unchecked` which I intend to remove in a followup PR.

After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates.

cc https://github.com/rust-lang/rust/pull/94963#issuecomment-1082924289
2022-05-12 12:48:30 +00:00
bors
0cd939e36c Auto merge of #96150 - est31:unused_macro_rules, r=petrochenkov
Implement a lint to warn about unused macro rules

This implements a new lint to warn about unused macro rules (arms/matchers), similar to the `unused_macros` lint added by #41907 that warns about entire macros.

```rust
macro_rules! unused_empty {
    (hello) => { println!("Hello, world!") };
    () => { println!("empty") }; //~ ERROR: 1st rule of macro `unused_empty` is never used
}

fn main() {
    unused_empty!(hello);
}
```

Builds upon #96149 and #96156.

Fixes #73576
2022-05-12 00:08:08 +00:00
Thom Chiovoloni
a64b2a95ff
Move #[used] check for Mach-O to rustc_typeck from rustc_codegen_llvm 2022-05-11 02:00:55 -07:00
Thom Chiovoloni
da72295411
Fix mixup between llvm.compiler.used and llvm.used in comment 2022-05-11 01:29:56 -07:00
Thom Chiovoloni
54133cfcf4
Only compile #[used] as llvm.compiler.used for ELF targets 2022-05-11 01:29:56 -07:00
lcnr
6c8265dc56 only_local: always check for misuse 2022-05-10 12:07:35 +02:00
bors
574830f573 Auto merge of #96094 - Elliot-Roberts:fix_doctests, r=compiler-errors
Begin fixing all the broken doctests in `compiler/`

Begins to fix #95994.
All of them pass now but 24 of them I've marked with `ignore HELP (<explanation>)` (asking for help) as I'm unsure how to get them to work / if we should leave them as they are.
There are also a few that I marked `ignore` that could maybe be made to work but seem less important.
Each `ignore` has a rough "reason" for ignoring after it parentheses, with

- `(pseudo-rust)` meaning "mostly rust-like but contains foreign syntax"
- `(illustrative)` a somewhat catchall for either a fragment of rust that doesn't stand on its own (like a lone type), or abbreviated rust with ellipses and undeclared types that would get too cluttered if made compile-worthy.
- `(not-rust)` stuff that isn't rust but benefits from the syntax highlighting, like MIR.
- `(internal)` uses `rustc_*` code which would be difficult to make work with the testing setup.

Those reason notes are a bit inconsistently applied and messy though. If that's important I can go through them again and try a more principled approach. When I run `rg '```ignore \(' .` on the repo, there look to be lots of different conventions other people have used for this sort of thing. I could try unifying them all if that would be helpful.

I'm not sure if there was a better existing way to do this but I wrote my own script to help me run all the doctests and wade through the output. If that would be useful to anyone else, I put it here: https://github.com/Elliot-Roberts/rust_doctest_fixing_tool
2022-05-07 06:30:29 +00:00
est31
5646e9a172 Allow unused rules in some places in the compiler, library and tools 2022-05-05 19:13:00 +02:00
Josh Triplett
0fc5c524f5 Stabilize bool::then_some 2022-05-04 13:22:08 +02:00
Yuki Okushi
329a73dbd6
Rollup merge of #96587 - bjorn3:refactor_backend_write, r=michaelwoerister
Refactor the WriteBackendMethods and ExtraBackendMethods traits

The new interface is slightly less confusing and is easier to implement for non-LLVM backends.
2022-05-03 14:58:57 +09:00
Elliot Roberts
7907385999 fix most compiler/ doctests 2022-05-02 17:40:30 -07:00
Vadim Petrochenkov
5b5964f569 rustc: Panic by default in DefIdTree::parent
Only crate root def-ids don't have a parent, and in majority of cases the argument of `DefIdTree::parent` cannot be a crate root.
So we now panic by default in `parent` and introduce a new non-panicing function `opt_parent` for cases where the argument can be a crate root.

Same applies to `local_parent`/`opt_local_parent`.
2022-05-02 01:56:50 +03:00
bjorn3
78c65a52db Merge new_metadata into codegen_allocator 2022-04-30 21:20:08 +02:00
bjorn3
fab72301d9 Remove config parameter of optimize_fat and avoid interior mutability for module 2022-04-30 20:58:42 +02:00
bjorn3
ee94ff254a Let LtoModuleCodegen::optimize take self by value 2022-04-30 20:51:17 +02:00
bjorn3
336bb0afea Rename run_lto_pass_manager to optimize_fat and remove thin parameter 2022-04-30 20:50:17 +02:00
Dylan DPC
d956d014f2
Rollup merge of #96432 - SparrowLii:dbg_scope, r=davidtwco
not need `Option` for `dbg_scope`

This PR fixes a few FIXME about not using `Option` in `dbg_scope` field of `DebugScope`, during `create_function_debug_context` func in codegen parts.
Added a `BitSet<SourceScope>` parameter to `make_mir_scope` to indicate whether the `DebugScope` has been instantiated.
cc ````@eddyb````
2022-04-28 02:40:34 +02:00
SparrowLii
843e8d19ec not need Option for dbg_scope 2022-04-26 21:00:19 +08:00
bors
18b53cefdf Auto merge of #95604 - nbdd0121:used2, r=petrochenkov
Generate synthetic object file to ensure all exported and used symbols participate in the linking

Fix #50007 and #47384

This is the synthetic object file approach that I described in https://github.com/rust-lang/rust/pull/95363#issuecomment-1079932354, allowing all exported and used symbols to be linked while still allowing them to be GCed.

Related #93791, #95363

r? `@petrochenkov`
cc `@carbotaniuman`
2022-04-25 16:14:54 +00:00
Matthias Krüger
433f1f425e
Rollup merge of #96215 - nikic:legacy-pm-removal, r=nagisa
Drop support for legacy PM with LLVM 15

LLVM 15 already removes some of the legacy PM APIs we're using. This patch forces use of NewPM with LLVM 15 (with `-Z new-llvm-pass-manager=no` throwing a warning) and stubs out various FFI methods with a report_fatal_error on LLVM 15.

For LLVMPassManagerBuilderPopulateLTOPassManager() I went with adding our own wrapper, as the alternative would be to muck about with weak symbols, which seems to be non-trivial as far as cross-platform support is concerned (std has `weak!` for this purpose, but only as an internal utility.)

Fixes #96072.
Fixes #96362.
2022-04-25 00:11:02 +02:00
Gary Guo
1af3e0a65e Ensure #[used] symbols are preserved in LTO 2022-04-24 22:32:05 +01:00
Michael Woerister
8b230086fa debuginfo: Emit ZST struct debuginfo for unit type when CPP-like debuginfo is enabled (instead of custom basic type). 2022-04-22 14:59:35 +02:00
Nikita Popov
6dc0bcc5db Stub out more PassManagerBuilder functions 2022-04-20 09:36:02 +02:00
Nikita Popov
890cabac8a Stub out various legacy PM functions with LLVM 15 2022-04-20 09:25:47 +02:00
Nikita Popov
25286dda2b Drop support for -Znew-llvm-pass-manager=no with LLVM 15 2022-04-20 09:25:47 +02:00
Dylan DPC
69e45d73b9
Rollup merge of #95740 - Amanieu:kreg0, r=nagisa
asm: Add a kreg0 register class on x86 which includes k0

Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.

Fixes #94977
2022-04-19 22:57:39 +02:00
Amanieu d'Antras
b2bc46938c asm: Add a kreg0 register class on x86 which includes k0
Previously we only exposed a kreg register class which excludes the k0
register since it can't be used in many instructions. However k0 is a
valid register and we need to have a way of marking it as clobbered for
clobber_abi.

Fixes #94977
2022-04-19 17:14:23 +02:00
Gary Guo
49cc6d1f84 Add SymbolExportInfo
This is currently a wrapper to `SymbolExportLevel` but it allows
later addition of extra information.
2022-04-18 20:50:56 +01:00
bors
d9b3ff7d34 Auto merge of #96117 - Dylan-DPC:rollup-5traczf, r=Dylan-DPC
Rollup of 7 pull requests

Successful merges:

 - #95887 (resolve: Create dummy bindings for all unresolved imports)
 - #96023 (couple of clippy::perf fixes)
 - #96035 (Update GitHub Actions actions/checkout Version v2 -> v3)
 - #96038 (docs: add link from zip to unzip)
 - #96047 (⬆️ rust-analyzer)
 - #96059 (clarify doc(cfg) wording)
 - #96081 (Make some `usize`-typed masks definitions agnostic to the size of `usize`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-04-16 14:24:14 +00:00
Dylan DPC
91847c43cc
Rollup merge of #96023 - matthiaskrgr:clippyper1304, r=lcnr
couple of clippy::perf fixes
2022-04-16 14:25:56 +02:00
bors
febce1fc31 Auto merge of #95689 - lqd:self-profiler, r=wesleywiser
Allow self-profiler to only record potentially costly arguments when argument recording is turned on

As discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns/near/277304909) with `@wesleywiser,` I'd like to record proc-macro expansions in the self-profiler, with some detailed data (per-expansion spans for example, to follow #95473).

At the same time, I'd also like to avoid doing expensive things when tracking a generic activity's arguments, if they were not specifically opted into the event filter mask, to allow the self-profiler to be used in hotter contexts.

This PR tries to offer:
- a way to ensure a closure to record arguments will only be called in that situation, so that potentially costly arguments can still be recorded when needed. With the additional requirement that, if possible, it would offer a way to record non-owned data without adding many `generic_activity_with_arg_{...}`-style methods. This lead to the `generic_activity_with_arg_recorder` single entry-point, and the closure parameter would offer the new methods, able to be executed in a context where costly argument could be created without disturbing the profiled piece of code.
- some facilities/patterns allowing to record more rustc specific data in this situation, without making `rustc_data_structures`  where the self-profiler is defined, depend on other rustc crates (causing circular dependencies): in particular, spans. They are quite tricky to turn into strings (if the default `Debug` impl output does not match the context one needs them for), and since I'd also like to avoid the allocation there when arg recording is turned off today, that has turned into another flexibility requirement for the API in this PR (separating the span-specific recording into an extension trait). **edit**: I've removed this from the PR so that it's easier to review, and opened https://github.com/rust-lang/rust/pull/95739.
- allow for extensibility in the future: other ways to record arguments, or additional data attached to them could be added in the future (e.g. recording the argument's name as well as its data).

Some areas where I'd love feedback:
- the API and names: the `EventArgRecorder` and its method for example. As well as the verbosity that comes from the increased flexibility.
- if I should convert the existing `generic_activity_with_arg{s}` to just forward to `generic_activity_with_arg_recorder` + `recorder.record_arg` (or remove them altogether ? Probably not): I've used the new API in the simple case I could find of allocating for an arg that may not be recorded, and the rest don't seem costly.
- [x] whether this API should panic if no arguments were recorded by the user-provided closure (like this PR currently does: it seems like an error to use an API dedicated to record arguments but not call the methods to then do so) or if this should just record a generic activity without arguments ?
- whether the `record_arg` function should be `#[inline(always)]`, like the `generic_activity_*` functions ?

As mentioned, r? `@wesleywiser` following our recent discussion.
2022-04-16 11:43:28 +00:00
bors
c8422403f7 Auto merge of #96108 - Dylan-DPC:rollup-t5f2fc9, r=Dylan-DPC
Rollup of 9 pull requests

Successful merges:

 - #93969 (Only add codegen backend to dep info if -Zbinary-dep-depinfo is used)
 - #94605 (Add missing links in platform support docs)
 - #95372 (make unaligned_references lint deny-by-default)
 - #95859 (Improve diagnostics for unterminated nested block comment)
 - #95961 (implement SIMD gather/scatter via vector getelementptr)
 - #96004 (Consider lifetimes when comparing types for equality in MIR validator)
 - #96050 (Remove some now-dead code that was only relevant before deaggregation.)
 - #96070 ([test] Add test cases for untested functions for BTreeMap)
 - #96099 (MaybeUninit array cleanup)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-04-16 09:19:26 +00:00
Dylan DPC
ea131bca17
Rollup merge of #95961 - RalfJung:gather-scatter, r=workingjubilee
implement SIMD gather/scatter via vector getelementptr

Fixes https://github.com/rust-lang/portable-simd/issues/271

However, I don't *really* know what I am doing here... Cc ``@workingjubilee`` ``@calebzulawski``

I didn't do anything for cranelift -- ``@bjorn3`` not sure if it's okay for that backend to temporarily break. I'm happy to cherry-pick a patch that adds cranelift support. :)
2022-04-16 07:12:45 +02:00
Amanieu d'Antras
547405e801 Add codegen for global_asm! sym operands 2022-04-15 14:36:30 +01:00
Matthias Krüger
bbd7ce6904 couple of clippy::perf fixes 2022-04-13 22:18:28 +02:00
bors
f38c5c8e5d Auto merge of #95656 - cjgillot:no-id-hashing-mode, r=Aaron1011
Remove NodeIdHashingMode.

r? `@ghost`
2022-04-13 11:27:17 +00:00
Camille GILLOT
443333dc1f Remove NodeIdHashingMode. 2022-04-12 19:59:32 +02:00
Ralf Jung
7f945b2b5b add simd_arith_offset intrinsics 2022-04-12 11:09:26 -04:00
Luqman Aden
bf3ef0da0c Switch to the 'normal' basic block for writing asm outputs if needed.
We may sometimes emit an `invoke` instead of a `call` for inline
assembly during the MIR -> LLVM IR lowering. But we failed to update
the IR builder's current basic block before writing the results to the
outputs. This would result in invalid IR because the basic block would
end in a `store` instruction, which isn't a valid terminator.
2022-04-09 15:25:46 -04:00
Rémy Rakic
1906b7e967 port codegen_module activity to arg recorder API 2022-04-07 15:47:20 +02:00
Rémy Rakic
b6a7b5accd remove allocation from a self-profiling call in the LLVM backend 2022-04-07 15:47:20 +02:00
Rémy Rakic
3a8006714b simplify a self-profiling activity call in the LLVM backend
and so that it doesn't allocate unless event argument recording is turned on
2022-04-07 15:47:20 +02:00
Cliff L. Biffle
98190b7168 Revert "Work around invalid DWARF bugs for fat LTO"
Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See #90357 for more info
and a repro case.

This commit is a mechanical revert of
d5de680e20 from PR #89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes #90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
2022-04-05 10:38:13 -07:00
Oli Scherer
d57b755909 Use WrappingRange::full instead of hand-rolling it 2022-04-05 13:18:22 +00:00
Oli Scherer
d32ce37a17 Mark scalar layout unions so that backends that do not support partially initialized scalars can special case them. 2022-04-05 13:18:21 +00:00
Loïc BRANSTETT
ccff48f97b Replace every String in Target(Options) with Cow<'static, str> 2022-04-03 21:29:57 +02:00
David Morrison
aa67016624 make memcmp return a value of c_int_width instead of i32 2022-04-02 17:21:08 -07:00
Dylan DPC
03b3993ae8
Rollup merge of #95461 - nyurik:spelling, r=lcnr
Spellchecking some comments

This PR attempts to clean up some minor spelling mistakes in comments
2022-03-30 09:10:07 +02:00
Yuri Astrakhan
a9cc3f6564 Spellchecking compiler code
Address some spelling mistakes in strings, private function names, and function params.
2022-03-30 01:42:10 -04:00
Yuri Astrakhan
7e8201ae0a Spellchecking some comments
This PR attempts to clean up some minor spelling mistakes in comments
2022-03-30 01:39:38 -04:00
bors
13c9fc38c9 Auto merge of #95300 - workingjubilee:less-bitsets, r=eddyb
Skip needless bitset for debuginfo

Found this while digging around looking at the inlining logic.
Seemed obvious enough so I decided to try to take care of it.
Is this what you had in mind, `@eddyb?`
2022-03-28 05:48:25 +00:00
Jubilee Young
f5f0e6d551 Skip needless bitset for debuginfo 2022-03-25 03:55:18 -07:00
Michael Woerister
e169261a6f debuginfo: Fix debuginfo for Box<T> where T is unsized.
Before this fix, the debuginfo for the fields was generated from the
struct defintion of Box<T>, but (at least at the moment) the compiler
pretends that Box<T> is just a (fat) pointer, so the fields need to be
`pointer` and `vtable` instead of `__0: Unique<T>` and `__1: Allocator`.

This is meant as a temporary mitigation until we can make sure that
simply treating Box as a regular struct in debuginfo does not cause too
much breakage in the ecosystem.
2022-03-24 11:12:41 +01:00
Dylan DPC
67d6cc6ef3
Rollup merge of #91608 - workingjubilee:fold-neon-fp, r=nagisa,Amanieu
Fold aarch64 feature +fp into +neon

Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.

I am... pretty sure no one is relying on this.

An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.

- Fixes rust-lang/rust#95002.
- Fixes rust-lang/rust#95064.
- Fixes rust-lang/rust#95122.
2022-03-23 03:05:28 +01:00
Jubilee Young
990c297ffb Filter for all features instead of any
Adds regression tests for feature logic
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Co-authored-by: Simonas Kazlauskas <git@kazlauskas.me>
2022-03-22 15:20:01 -07:00
Jubilee Young
b807d5970b Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON

In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a

In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.

"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
2022-03-22 15:14:33 -07:00
bors
d6f3a4ecb4 Auto merge of #88098 - Amanieu:oom_panic, r=nagisa
Implement -Z oom=panic

This PR removes the `#[rustc_allocator_nounwind]` attribute on `alloc_error_handler` which allows it to unwind with a panic instead of always aborting. This is then used to implement `-Z oom=panic` as per RFC 2116 (tracking issue #43596).

Perf and binary size tests show negligible impact.
2022-03-18 03:01:46 +00:00
bors
040703018c Auto merge of #94261 - michaelwoerister:debuginfo-types-refactor, r=wesleywiser
debuginfo: Refactor debuginfo generation for types

This PR implements the refactoring of the `rustc_codegen_llvm::debuginfo::metadata` module as described in MCP https://github.com/rust-lang/compiler-team/issues/482.

In particular it
- changes names to use `di_node` instead of `metadata`
- uniformly names all functions that build new debuginfo nodes `build_xyz_di_node`
- renames `CrateDebugContext` to `CodegenUnitDebugContext` (which is more accurate)
- removes outdated parts from `compiler/rustc_codegen_llvm/src/debuginfo/doc.md`
- moves `TypeMap` and functions that work directly work with it to a new `type_map` module
- moves enum related builder functions to a new `enums` module
- splits enum debuginfo building for the native and cpp-like cases, since they are mostly separate
- uses `SmallVec` instead of `Vec` in many places
- removes the old infrastructure for dealing with recursion cycles (`create_and_register_recursive_type_forward_declaration()`, `RecursiveTypeDescription`, `set_members_of_composite_type()`, `MemberDescription`, `MemberDescriptionFactory`, `prepare_xyz_metadata()`, etc)
- adds `type_map::build_type_with_children()` as a replacement for dealing with recursion cycles
- adds many (doc-)comments explaining what's going on
- changes cpp-like naming for C-Style enums so they don't get a `enum$<...>` name (because the NatVis visualizer does not apply to them)
- fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields
- changes cpp-like naming for generator enums so that NatVis works for them
- changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of, sometimes, next to it

The following could be done in subsequent PRs:
- add caching for `closure_saved_names_of_captured_variables`
- add caching for `generator_layout_and_saved_local_names`
- fix inconsistent handling of what is considered a C-style enum wrt to debuginfo
- rename `metadata` module to `types`
- move common generator fields to front instead of appending them

This PR is based on https://github.com/rust-lang/rust/pull/93644 which is not merged yet.

Right now, the changes are all done in one big commit. They could be split into smaller commits but hopefully the list of changes above makes it tractable to review them as a single commit too.

For now: r? `@ghost` (let's see if this affects compile times)
2022-03-15 10:52:32 +00:00
Michael Woerister
584855e03d debuginfo: Refactor debuginfo generation for types -- Rename DebugInfoMethods::create_vtable_metadata() to DebugInfoMethods::create_vtable_debuginfo() 2022-03-14 17:25:24 +01:00
Michael Woerister
9580a7115d debuginfo: Refactor debuginfo generation for types -- Address review comments. 2022-03-14 17:25:17 +01:00
Matthias Krüger
0e423932f8
Rollup merge of #90621 - adamgemmell:dev/stabilise-target-feature, r=Amanieu
Stabilise `aarch64_target_feature`

This PR stabilises `aarch64_target_feature` - see https://github.com/rust-lang/rust/issues/90620
2022-03-14 17:24:56 +01:00
Michael Woerister
19707b0ff2 debuginfo: Refactor debuginfo generation for types -- Address outstanding FIXMEs. 2022-03-14 16:55:01 +01:00
Michael Woerister
07a1194edf debuginfo: Refactor debuginfo generation for types -- Run x.py fmt 2022-03-14 16:52:47 +01:00
Michael Woerister
5144661d6b Remove out-dated information from rustc_codegen_llvm/src/debuginfo/doc.md 2022-03-14 16:52:47 +01:00
Michael Woerister
07ebc13d87 debuginfo: Refactor debuginfo generation for types
This commit
- changes names to use di_node instead of metadata
- uniformly names all functions that build new debuginfo nodes build_xyz_di_node
- renames CrateDebugContext to CodegenUnitDebugContext (which is more accurate)
- moves TypeMap and functions that work directly work with it to a new type_map module
- moves and reimplements enum related builder functions to a new enums module
- splits enum debuginfo building for the native and cpp-like cases, since they are mostly separate
- uses SmallVec instead of Vec in many places
- removes the old infrastructure for dealing with recursion cycles (create_and_register_recursive_type_forward_declaration(), RecursiveTypeDescription, set_members_of_composite_type(), MemberDescription, MemberDescriptionFactory, prepare_xyz_metadata(), etc)
- adds type_map::build_type_with_children() as a replacement for dealing with recursion cycles
- adds many (doc-)comments explaining what's going on
- changes cpp-like naming for C-Style enums so they don't get a enum$<...> name (because the NatVis visualizer does not apply to them)
- fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields
- changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of, sometimes, next to it
2022-03-14 16:49:06 +01:00
Adam Gemmell
39961390ad Tie fp and neon 2022-03-14 10:54:21 +00:00
bors
012720ffb0 Auto merge of #94733 - nnethercote:fix-AdtDef-interning, r=fee1-dead
Improve `AdtDef` interning.

This commit makes `AdtDef` use `Interned`. Much of the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.

r? `@fee1-dead`
2022-03-12 07:02:05 +00:00
Nicholas Nethercote
ca5525d564 Improve AdtDef interning.
This commit makes `AdtDef` use `Interned`. Much the commit is tedious
changes to introduce getter functions. The interesting changes are in
`compiler/rustc_middle/src/ty/adt.rs`.
2022-03-11 13:31:24 +11:00
Dylan DPC
b18b2d1bcd
Rollup merge of #94728 - compiler-errors:box-allocator-zst-meta, r=michaelwoerister
Only emit pointer-like metadata for `Box<T, A>` when `A` is ZST

Basically copy the change in #94043, but for debuginfo.

r? ``@michaelwoerister``

Fixes #94725
2022-03-10 23:13:00 +01:00
bors
282778aee2 Auto merge of #94764 - nikic:update-llvm-3, r=nagisa
Update LLVM submodule

This merges upstream changes from the 14.x release branch.

Fixes #89609.
Fixes #93923.
Fixes #94032.
2022-03-10 08:56:02 +00:00
Nikita Popov
0c7d0a19dd Use new pass manager on s390x with LLVM 14
The problematic compile-time issue should be resolved with this
version.
2022-03-09 10:00:23 +01:00
lcnr
b8135fd5c8 add #[rustc_pass_by_value] to more types 2022-03-08 15:39:52 +01:00
Michael Goulet
307ee94a8a only emit pointer-like metadata for BZST-allocator Box 2022-03-07 23:06:59 -08:00
bors
ecb867ec3c Auto merge of #94690 - nnethercote:clarify-Layout-interning, r=fee1-dead
Clarify `Layout` interning.

`Layout` is another type that is sometimes interned, sometimes not, and
we always use references to refer to it so we can't take any advantage
of the uniqueness properties for hashing or equality checks.

This commit renames `Layout` as `LayoutS`, and then introduces a new
`Layout` that is a newtype around an `Interned<LayoutS>`. It also
interns more layouts than before. Previously layouts within layouts
(via the `variants` field) were never interned, but now they are. Hence
the lifetime on the new `Layout` type.

Unlike other interned types, these ones are in `rustc_target` instead of
`rustc_middle`. This reflects the existing structure of the code, which
does layout-specific stuff in `rustc_target` while `TyAndLayout` is
generic over the `Ty`, allowing the type-specific stuff to occur in
`rustc_middle`.

The commit also adds a `HashStable` impl for `Interned`, which was
needed. It hashes the contents, unlike the `Hash` impl which hashes the
pointer.

r? `@fee1-dead`
2022-03-07 15:25:42 +00:00
Nicholas Nethercote
4f008e06c3 Clarify Layout interning.
`Layout` is another type that is sometimes interned, sometimes not, and
we always use references to refer to it so we can't take any advantage
of the uniqueness properties for hashing or equality checks.

This commit renames `Layout` as `LayoutS`, and then introduces a new
`Layout` that is a newtype around an `Interned<LayoutS>`. It also
interns more layouts than before. Previously layouts within layouts
(via the `variants` field) were never interned, but now they are. Hence
the lifetime on the new `Layout` type.

Unlike other interned types, these ones are in `rustc_target` instead of
`rustc_middle`. This reflects the existing structure of the code, which
does layout-specific stuff in `rustc_target` while `TyAndLayout` is
generic over the `Ty`, allowing the type-specific stuff to occur in
`rustc_middle`.

The commit also adds a `HashStable` impl for `Interned`, which was
needed. It hashes the contents, unlike the `Hash` impl which hashes the
pointer.
2022-03-07 13:41:47 +11:00
bors
3d1eaf4b62 Auto merge of #94638 - erikdesjardins:noextranull, r=nagisa
cleanup: remove unused ability to have LLVM null-terminate const strings

(and the copied function in rustc_codegen_gcc)

Noticed this while writing https://github.com/rust-lang/rust/pull/94450#issuecomment-1059687348.

r? `@nagisa`
2022-03-07 02:07:36 +00:00
bors
8876ca3dd4 Auto merge of #94597 - nnethercote:ConstAllocation, r=fee1-dead
Introduce `ConstAllocation`.

Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.

This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.

In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.

The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.

r? `@fee1-dead`
2022-03-06 22:37:54 +00:00
Nicholas Nethercote
4852291417 Introduce ConstAllocation.
Currently some `Allocation`s are interned, some are not, and it's very
hard to tell at a use point which is which.

This commit introduces `ConstAllocation` for the known-interned ones,
which makes the division much clearer. `ConstAllocation::inner()` is
used to get the underlying `Allocation`.

In some places it's natural to use an `Allocation`, in some it's natural
to use a `ConstAllocation`, and in some places there's no clear choice.
I've tried to make things look as nice as possible, while generally
favouring `ConstAllocation`, which is the type that embodies more
information. This does require quite a few calls to `inner()`.

The commit also tweaks how `PartialOrd` works for `Interned`. The
previous code was too clever by half, building on `T: Ord` to make the
code shorter. That caused problems with deriving `PartialOrd` and `Ord`
for `ConstAllocation`, so I changed it to build on `T: PartialOrd`,
which is slightly more verbose but much more standard and avoided the
problems.
2022-03-07 08:25:50 +11:00
bors
38a0b81b1c Auto merge of #94679 - matthiaskrgr:rollup-9vd7w6a, r=matthiaskrgr
Rollup of 3 pull requests

Successful merges:

 - #94659 (explain why shift with signed offset works the way it does)
 - #94671 (fix pin doc typo)
 - #94672 (Improved error message for failed bitcode load)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-03-06 20:21:35 +00:00
Erik Desjardins
e1a4bf6492 cleanup: remove unused ability to have LLVM null-terminate const strings 2022-03-06 12:28:46 -05:00
Joe
65ec4dd904
Improved error message for failed bitcode load
"bc" is an unnecessary shorthand that obfuscates the compilation error
2022-03-06 15:25:05 +01:00
Tomasz Miąsko
095d818e0c Always include global target features in function attributes
This ensures that information about target features configured with
`-C target-feature=...` or detected with `-C target-cpu=native` is
retained for subsequent consumers of LLVM bitcode.

This is crucial for linker plugin LTO, since this information is not
conveyed to the plugin otherwise.
2022-03-04 16:57:34 +01:00
Tomasz Miąsko
b6f845f225 Use SmallStr when building target-features LLVM attribute 2022-03-04 16:57:34 +01:00
bors
047f9c4bc4 Auto merge of #94539 - tmiasko:string-attributes, r=nikic
Pass LLVM string attributes as string slices
2022-03-04 10:38:11 +00:00
bors
62ff2bcf94 Auto merge of #94159 - erikdesjardins:align-load, r=nikic
Add !align metadata on loads of &/&mut/Box

Note that this refers to the alignment of what the loaded value points
to, _not_ the alignment of the loaded value itself.

r? `@ghost` (blocked on #94158)
2022-03-04 08:14:31 +00:00
Amanieu d'Antras
aa36237e16 Add -Z oom={panic,abort} command-line option 2022-03-03 12:58:38 +00:00
cuishuang
00fffdddd2 all: fix some typos
Signed-off-by: cuishuang <imcusg@gmail.com>
2022-03-03 19:47:23 +08:00
Dylan DPC
878a4ff90e
Rollup merge of #94529 - GuillaumeGomez:unused-doc-comments-blocks, r=estebank
Unused doc comments blocks

Fixes #77030.
2022-03-03 01:09:15 +01:00
Tomasz Miąsko
926bf1a371 Pass LLVM string attributes as string slices 2022-03-03 00:28:50 +01:00
Guillaume Gomez
628fbdf9b7 Fix unused_doc_comments lint errors 2022-03-02 20:06:35 +01:00
mark
e489a94dee rename ErrorReported -> ErrorGuaranteed 2022-03-02 09:45:25 -06:00
bors
c42d846add Auto merge of #94229 - erikdesjardins:rem2, r=nikic
Remove LLVM attribute removal

This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function.
Then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.
(see [`src/test/codegen/optimize-attr-1.rs`](03a8cc7df1/src/test/codegen/optimize-attr-1.rs (L33)))

However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.

r? `@ghost` (blocked on #94221)
`@rustbot` label S-blocked
2022-03-02 08:48:33 +00:00
bors
39a3b52767 Auto merge of #87402 - nagisa:nagisa/request-feature-requests-for-features, r=estebank
Direct users towards using Rust target feature names in CLI

This PR consists of a couple of changes on how we handle target features.

In particular there is a bug-fix wherein we avoid passing through features that aren't prefixed by `+` or `-` to LLVM. These appear to be causing LLVM to assert, which is pretty poor a behaviour (and also makes it pretty clear we expect feature names to be prefixed).

The other commit, I anticipate to be somewhat more controversial is outputting a warning when users specify a LLVM-specific, or otherwise unknown, feature name on the CLI. In those situations we request users to either replace it with a known Rust feature name (e.g. `bmi` -> `bmi1`) or file a feature request. I've a couple motivations for this: first of all, if users are specifying these features on the command line, I'm pretty confident there is also a need for these features to be usable via `#[cfg(target_feature)]` machinery.  And second, we're growing a fair number of backends recently and having ability to provide some sort of unified-ish interface in this place seems pretty useful to me.

Sponsored by: standard.ai
2022-03-02 03:03:22 +00:00
bors
4a56cbec59 Auto merge of #94402 - erikdesjardins:revert-coldland, r=nagisa
Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa"

Should fix (untested) #94390

Reopens #46515, #87055

r? `@ehuss`
2022-03-01 08:57:46 +00:00
Erik Desjardins
69ae4233cf Add !align metadata on loads of &/&mut/Box
Note that this refers to the alignment of what the loaded value points
to, _not_ the alignment of the loaded value itself.
2022-02-28 20:04:36 -05:00
Simonas Kazlauskas
df701a292c Querify global_backend_features
At the very least this serves to deduplicate the diagnostics that are
output about unknown target features provided via CLI.
2022-03-01 01:57:25 +02:00
Simonas Kazlauskas
c97c216efd Direct users towards using Rust feature names in CLI
If they are trying to use features rustc doesn't yet know about,
request a feature request.

Additionally, also warn against using feature names without leading `+`
or `-` signs.
2022-03-01 01:57:10 +02:00
Matthias Krüger
ea39f46cad
Rollup merge of #94365 - mati865:fix-mingw-detection-for-rawdylib, r=michaelwoerister
Fix MinGW target detection in raw-dylib

LLVM target doesn't have to be the same as Rust target so relying on it is wrong.

It was one of concerns in https://github.com/rust-lang/rust/pull/88801 that was not fixed in https://github.com/rust-lang/rust/pull/90782.
2022-02-28 12:57:48 +01:00
Erik Desjardins
dce14cfacc Remove LLVM attribute removal
This was necessary before, because `declare_raw_fn` would always apply
the default optimization attributes to every declared function,
and then `attributes::from_fn_attrs` would have to remove the default
attributes in the case of, e.g. `#[optimize(speed)]` in a `-Os` build.

However, every relevant callsite of `declare_raw_fn` (i.e. where we
actually generate code for the function, and not e.g. a call to an
intrinsic, where optimization attributes don't [?] matter)
calls `from_fn_attrs`, so we can simply remove the attribute setting
from `declare_raw_fn`, and rely on `from_fn_attrs` to apply the correct
attributes all at once.
2022-02-28 00:02:11 -05:00
Erik Desjardins
851fcc7a54 Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa"
This reverts commit 4f49627c6f, reversing
changes made to 028c6f1454.
2022-02-27 23:11:03 -05:00
Simonas Kazlauskas
dfcfaa4ec1 Do not pass through features without +/- prefix
LLVM really dislikes this and will assert, saying something along the
lines of:

```
rustc: llvm/lib/MC/MCSubtargetInfo.cpp:60: void ApplyFeatureFlag(
  llvm::FeatureBitset&, llvm::StringRef, llvm::ArrayRef<llvm::SubtargetFeatureKV>
): Assertion
  `SubtargetFeatures::hasFlag(Feature) && "Feature flags should start with '+' or '-'"`
failed.
```
2022-02-27 21:21:38 +02:00
Erik Desjardins
fec4335407 Apply noundef metadata to loads of types that do not permit raw init
This matches the noundef attributes we apply on arguments/return types.
2022-02-27 12:16:16 -05:00
bors
2bd9656c80 Auto merge of #94221 - erikdesjardins:addattr, r=nikic
Add LLVM attributes in batches instead of individually

This should improve performance.

~r? `@ghost` (blocked on #94127)~
2022-02-27 09:23:24 +00:00
Erik Desjardins
91e7e8ddcb just put smallvec lengths in the signature 2022-02-26 16:58:17 -05:00
bors
761e888485 Auto merge of #93516 - nagisa:branch-protection, r=cjgillot
No branch protection metadata unless enabled

Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.

This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.

Additionally this PR also ensures we emit an error if
`-Zbranch-protection` is set on targets other than the supported
aarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.
2022-02-26 21:53:03 +00:00
Erik Desjardins
30d3ce0674 Add LLVM attributes in batches instead of individually
This should improve performance.
2022-02-26 13:14:55 -05:00
bors
8128e910c0 Auto merge of #94127 - erikdesjardins:debugattr, r=nikic
At opt-level=0, apply only ABI-affecting attributes to functions

This should provide a small perf improvement for debug builds,
and should more than cancel out the perf regression from adding noundef (https://github.com/rust-lang/rust/pull/93670#issuecomment-1038347581, #94106).

r? `@nikic`
2022-02-26 09:41:19 +00:00
bors
d981633ed6 Auto merge of #94290 - Mark-Simulacrum:bump-bootstrap, r=pietroalbini
Bump bootstrap to 1.60

This bumps the bootstrap compiler to 1.60 and cleans up cfgs and Span's rustc_pass_by_value (enabled by the bootstrap bump).
2022-02-25 18:34:02 +00:00
Mateusz Mikuła
c35a1d4028 Fix MinGW target detection in raw-dylib
LLVM target doesn't have to be the same as Rust target so relying on it is wrong.
2022-02-25 17:46:23 +01:00
Mark Rousskov
22c3a71de1 Switch bootstrap cfgs 2022-02-25 08:00:52 -05:00
bors
9b2a46591a Auto merge of #93644 - michaelwoerister:simpler-debuginfo-typemap, r=wesleywiser
debuginfo: Simplify TypeMap used during LLVM debuginfo generation.

This PR simplifies the TypeMap that is used in `rustc_codegen_llvm::debuginfo::metadata`. It was unnecessarily complicated because it was originally implemented when types were not yet normalized before codegen. So it did it's own normalization and kept track of multiple unnormalized types being mapped to a single unique id.

This PR is based on https://github.com/rust-lang/rust/pull/93503, which is not merged yet.

The PR also removes the arena used for allocating string ids and instead uses `InlinableString` from the [inlinable_string](https://crates.io/crates/inlinable_string) crate. That might not be the best choice, since that crate does not seem to be very actively maintained. The [flexible-string](https://crates.io/crates/flexible-string) crate would be an alternative.

r? `@ghost`
2022-02-25 11:00:32 +00:00
Michael Woerister
bb2059f959 debuginfo: Simplify TypeMap used during LLVM debuginfo generation -- address review comments. 2022-02-25 10:30:45 +01:00
bors
ece55d416e Auto merge of #94130 - erikdesjardins:partially, r=nikic
Use undef for (some) partially-uninit constants

There needs to be some limit to avoid perf regressions on large arrays
with undef in each element (see comment in the code).

Fixes: #84565
Original PR: #83698

Depends on LLVM 14: #93577
2022-02-25 05:44:33 +00:00
Dylan DPC
6b03a46f27
Rollup merge of #94242 - compiler-errors:fat-uninhabitable-pointer, r=michaelwoerister
properly handle fat pointers to uninhabitable types

Calculate the pointee metadata size by using `tcx.struct_tail_erasing_lifetimes` instead of duplicating the logic in `fat_pointer_kind`. Open to alternatively suggestions on how to fix this.

Fixes #94149

r? ````@michaelwoerister```` since you touched this code last, I think!
2022-02-24 21:42:15 +01:00
bors
3d127e2040 Auto merge of #94123 - bjorn3:cg_ssa_singleton_builder, r=tmiasko
Partially move cg_ssa towards using a single builder

Not all codegen backends can handle hopping between blocks well. For example Cranelift requires blocks to be terminated before switching to building a new block. Rust-gpu requires a `RefCell` to allow hopping between blocks and cg_gcc currently has a buggy implementation of hopping between blocks. This PR reduces the amount of cases where cg_ssa switches between blocks before they are finished and mostly fixes the block hopping in cg_gcc. (~~only `scalar_to_backend` doesn't handle it correctly yet in cg_gcc~~ fixed that one.)

`@antoyo` please review the cg_gcc changes.
2022-02-24 12:28:19 +00:00
bjorn3
96cf7999ab Introduce Bx::switch_to_block 2022-02-24 12:18:21 +01:00
Matthias Krüger
77a8e60dd7
Rollup merge of #89887 - arlosi:char-debug, r=wesleywiser
Change `char` type in debuginfo to DW_ATE_UTF

Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more appropriate encoding is `DW_ATE_UTF`.

Clang also uses the DW_ATE_UTF for `char32_t` in C++.

This fixes the display of the `char` type in the Windows debuggers. Without this change, the variable did not show in the locals window.
![image](https://user-images.githubusercontent.com/704597/137368067-9b3e4dc8-a075-44ba-a687-bf3810a44e5a.png)

LLDB 13 is also able to display the char value, when before it failed with `need to add support for DW_TAG_base_type 'char' encoded with DW_ATE = 0x8, bit_size = 32`

r? `@wesleywiser`
2022-02-24 07:48:04 +01:00
Arlo Siemsen
be454f056f Change char type in debuginfo to DW_ATE_UTF
Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more
appropriate encoding is DW_ATE_UTF.

Clang uses this same debug encoding for char32_t.

This fixes the display of `char` types in Windows debuggers as well as LLDB.
2022-02-23 08:31:10 -08:00
Michael Goulet
c73a2f8a65 properly handle fat pointers to uninhabitable types 2022-02-23 08:20:12 -08:00
David Wood
4e41a46f6a Reapply cg_llvm: fewer_names in uncached_llvm_type
Co-authored-by: Erik Desjardins <erikdesjardins@users.noreply.github.com>
Co-authored-by: Tomasz Miąsko <tomasz.miasko@gmail.com>
2022-02-22 08:23:53 +01:00
Michael Woerister
e72e6399b1 debuginfo: Simplify TypeMap used during LLVM debuginfo generation.
The previous implementation was written before types were properly
normalized for code generation and had to assume a more complicated
relationship between types and their debuginfo -- generating separate
identifiers for debuginfo nodes that were based on normalized types.

Since types are now already normalized, we can use them as identifiers
for debuginfo nodes.
2022-02-21 13:03:36 +01:00
lcnr
1245131a11 use List<Ty<'tcx>> for tuples 2022-02-21 07:09:11 +01:00
bors
45e2c2881d Auto merge of #93678 - steffahn:better_unsafe_diagnostics, r=nagisa
Improve `unused_unsafe` lint

I’m going to add some motivation and explanation below, particularly pointing the changes in behavior from this PR.

_Edit:_ Looking for existing issues, looks like this PR fixes #88260.

_Edit2:_ Now also contains code that closes #90776.
2022-02-20 21:15:11 +00:00
Frank Steffahn
8f8689fb31 Improve unused_unsafe lint
Main motivation: Fixes some issues with the current behavior. This PR is
more-or-less completely re-implementing the unused_unsafe lint; it’s also only
done in the MIR-version of the lint, the set of tests for the `-Zthir-unsafeck`
version no longer succeeds (and is thus disabled, see `lint-unused-unsafe.rs`).

On current nightly,
```rs
unsafe fn unsf() {}

fn inner_ignored() {
    unsafe {
        #[allow(unused_unsafe)]
        unsafe {
            unsf()
        }
    }
}
```

doesn’t create any warnings. This situation is not unrealistic to come by, the
inner `unsafe` block could e.g. come from a macro. Actually, this PR even
includes removal of one unused `unsafe` in the standard library that was missed
in a similar situation. (The inner `unsafe` coming from an external macro hides
    the warning, too.)

The reason behind this problem is how the check currently works:
* While generating MIR, it already skips nested unsafe blocks (i.e. unsafe
  nested in other unsafe) so that the inner one is always the one considered
  unused
* To differentiate the cases of no unsafe operations inside the `unsafe` vs.
  a surrounding `unsafe` block, there’s some ad-hoc magic walking up the HIR to
  look for surrounding used `unsafe` blocks.

There’s a lot of problems with this approach besides the one presented above.
E.g. the MIR-building uses checks for `unsafe_op_in_unsafe_fn` lint to decide
early whether or not `unsafe` blocks in an `unsafe fn` are redundant and ought
to be removed.
```rs
unsafe fn granular_disallow_op_in_unsafe_fn() {
    unsafe {
        #[deny(unsafe_op_in_unsafe_fn)]
        {
            unsf();
        }
    }
}
```
```
error: call to unsafe function is unsafe and requires unsafe block (error E0133)
  --> src/main.rs:13:13
   |
13 |             unsf();
   |             ^^^^^^ call to unsafe function
   |
note: the lint level is defined here
  --> src/main.rs:11:16
   |
11 |         #[deny(unsafe_op_in_unsafe_fn)]
   |                ^^^^^^^^^^^^^^^^^^^^^^
   = note: consult the function's documentation for information on how to avoid undefined behavior

warning: unnecessary `unsafe` block
  --> src/main.rs:10:5
   |
9  | unsafe fn granular_disallow_op_in_unsafe_fn() {
   | --------------------------------------------- because it's nested under this `unsafe` fn
10 |     unsafe {
   |     ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

```
Here, the intermediate `unsafe` was ignored, even though it contains a unsafe
operation that is not allowed to happen in an `unsafe fn` without an additional `unsafe` block.

Also closures were problematic and the workaround/algorithms used on current
nightly didn’t work properly. (I skipped trying to fully understand what it was
supposed to do, because this PR uses a completely different approach.)
```rs
fn nested() {
    unsafe {
        unsafe { unsf() }
    }
}
```
```
warning: unnecessary `unsafe` block
  --> src/main.rs:10:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default
```

vs

```rs
fn nested() {
    let _ = || unsafe {
        let _ = || unsafe { unsf() };
    };
}
```
```
warning: unnecessary `unsafe` block
 --> src/main.rs:9:16
  |
9 |     let _ = || unsafe {
  |                ^^^^^^ unnecessary `unsafe` block
  |
  = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:10:20
   |
10 |         let _ = || unsafe { unsf() };
   |                    ^^^^^^ unnecessary `unsafe` block
```

*note that this warning kind-of suggests that **both** unsafe blocks are redundant*

--------------------------------------------------------------------------------

I also dislike the fact that it always suggests keeping the outermost `unsafe`.
E.g. for
```rs
fn granularity() {
    unsafe {
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
I prefer if `rustc` suggests removing the more-course outer-level `unsafe`
instead of the fine-grained inner `unsafe` blocks, which it currently does on nightly:
```
warning: unnecessary `unsafe` block
  --> src/main.rs:10:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:11:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
11 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block

warning: unnecessary `unsafe` block
  --> src/main.rs:12:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
12 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
```

--------------------------------------------------------------------------------

Needless to say, this PR addresses all these points. For context, as far as my
understanding goes, the main advantage of skipping inner unsafe blocks was that
a test case like
```rs
fn top_level_used() {
    unsafe {
        unsf();
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
should generate some warning because there’s redundant nested `unsafe`, however
every single `unsafe` block _does_ contain some statement that uses it. Of course
this PR doesn’t aim change the warnings on this kind of code example, because
the current behavior, warning on all the inner `unsafe` blocks, makes sense in this case.

As mentioned, during MIR building all the unsafe blocks *are* kept now, and usage
is attributed to them. The way to still generate a warning like
```
warning: unnecessary `unsafe` block
  --> src/main.rs:11:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsf();
11 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:12:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
12 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block

warning: unnecessary `unsafe` block
  --> src/main.rs:13:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
13 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
```

in this case is by emitting a `unused_unsafe` warning for all of the `unsafe`
blocks that are _within a **used** unsafe block_.

The previous code had a little HIR traversal already anyways to collect a set of
all the unsafe blocks (in order to afterwards determine which ones are unused
afterwards). This PR uses such a traversal to do additional things including logic
like _always_ warn for an `unsafe` block that’s inside of another **used**
unsafe block. The traversal is expanded to include nested closures in the same go,
this simplifies a lot of things.

The whole logic around `unsafe_op_in_unsafe_fn` is a little complicated, there’s
some test cases of corner-cases in this PR. (The implementation involves
differentiating between whether a used unsafe block was used exclusively by
operations where `allow(unsafe_op_in_unsafe_fn)` was active.) The main goal was
to make sure that code should compile successfully if all the `unused_unsafe`-warnings
are addressed _simultaneously_ (by removing the respective `unsafe` blocks)
no matter how complicated the patterns of `unsafe_op_in_unsafe_fn` being
disallowed and allowed throughout the function are.

--------------------------------------------------------------------------------

One noteworthy design decision I took here: An `unsafe` block
with `allow(unused_unsafe)` **is considered used** for the purposes of
linting about redundant contained unsafe blocks. So while
```rs

fn granularity() {
    unsafe { //~ ERROR: unnecessary `unsafe` block
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
warns for the outer `unsafe` block,
```rs

fn top_level_ignored() {
    #[allow(unused_unsafe)]
    unsafe {
        #[deny(unused_unsafe)]
        {
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
        }
    }
}
```
warns on the inner ones.
2022-02-20 21:00:12 +01:00
bors
523a1b1d38 Auto merge of #94062 - Mark-Simulacrum:drop-print-cfg, r=oli-obk
Move ty::print methods to Drop-based scope guards

Primary goal is reducing codegen of the TLS access for each closure, which shaves ~3 seconds of bootstrap time over rustc as a whole.
2022-02-20 18:12:59 +00:00
Erik Desjardins
067f628286 add check for llvm 14 2022-02-20 11:37:22 -05:00
bjorn3
e6d7a8d7d4 Remove build_sibling_block 2022-02-20 13:38:15 +01:00
Matthias Krüger
f2d6770f77
Rollup merge of #94146 - est31:let_else, r=cjgillot
Adopt let else in more places

Continuation of #89933, #91018, #91481, #93046, #93590, #94011.

I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This is the biggest of these PRs and handles the changes outside of rustdoc, rustc_typeck, rustc_const_eval, rustc_trait_selection, which were handled in PRs #94139, #94142, #94143, #94144.
2022-02-20 00:37:34 +01:00
est31
2ef8af6619 Adopt let else in more places 2022-02-19 17:27:43 +01:00