| Age | Commit message (Collapse) | Author | Lines |
|---|
|
fix: remove the check of lld not supporting @response-file
In LLVM v9, lld has supported `@response-file.`
LLVM v9 was released on 2019-09-19.
The check was added back to 2018-03-14 (1.26.0) via 04442af18bf0.
It has been more than five years, and we ship our own lld regardlessly.
This should be happily removed.
See also:
* <https://github.com/llvm/llvm-project/commit/bb12396f9175eaf4586d8e5c76441977d97ccf93>
* <https://reviews.llvm.org/D63024>
|
|
atomic intrinsics: clarify which types are supported and (if applicable) what happens with provenance
The provenance semantics match what Miri implements and what the `AtomicPtr` API expects.
|
|
Sync Fuchsia target spec with clang Fuchsia driver
This updates the Fuchsia target spec with the [Clang Fuchsia driver], which picks up a few changes:
* Adds `-z start-stop-visibility=hidden` and `-z rel` to the pre link arguments.
* Adds `--execute-only` and `--fix-cortex-a53-843419` for `aarch64-unknown-fuchsia`.
* Enables the equivalent cpu features for `x86-64-v2` for `x86_64-unknown-fuchsia`, which is our minimum supported x86_64 platform according to [RFC-0073].
try-job: x86_64-fuchsia
[Clang Fuchsia driver]: https://github.com/llvm/llvm-project/blob/8374d421861cd3d47e21ae7889ba0b4c498e8d85/clang/lib/Driver/ToolChains/Fuchsia.cpp
[RFC-0073]: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0073_x86_64_platform_requirement
|
|
Allow more top-down inlining for single-BB callees
This means that things like `<usize as Step>::forward_unchecked` and `<PartialOrd for f32>::le` will inline even if
we've already done a bunch of inlining to find the calls to them.
Fixes #138136
~~Draft as it's built atop #138135, which adds a mir-opt test that's a nice demonstration of this. To see just this change, look at <https://github.com/rust-lang/rust/pull/138157/commits/48f63e3be552605c2933056b77bf23a326757f92>~~ Rebased to be just the inlining change, as the other existing tests show it great.
|
|
|
|
|
|
|
|
Don't `alloca` just to look at a discriminant
Today we're making LLVM do a bunch of extra work when you match on trivial stuff like `Option<bool>` or `ControlFlow<u8>`.
This PR changes that so that simple types like `Option<u32>` or `Result<(), Box<Error>>` can stay as `OperandValue::ScalarPair` and we can still read the discriminant from them, rather than needing to write them into memory to have a `PlaceValue` just to get the discriminant out.
Fixes #137503
|
|
|
|
Anonymous params are currently represented with `kw::Empty`, so handle
that properly. (Subsequent commits will get rid of the `kw::Empty`.)
|
|
Currently (PatKind::Wild` (i.e. `_`) gets turned by
`lower_fn_params_to_names` into an empty identifier, which means it is
printed incorrectly by HIR pretty printing.
And likewise for `lower_fn_params_to_names`, which affects some error
messages.
This commit fixes them. This requires a slight tweak in a couple of
places to continue using parameter numbers in some error messages. And
it improves the output of `tests/ui/typeck/cyclic_type_ice.rs`:
`/* _ */` is a better suggestion than `/* */`.
|
|
It has a single call site.
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #138126 (Add an opt-out in pretty printing for RTN rendering)
- #138399 (Delegation: allow foreign fns `reuse`)
- #138406 (Update mdbook to 0.4.47)
- #138417 (minor interpreter cleanups)
- #138420 (Adapt to LLVM dropping CfiFunctionIndex::begin()/end())
- #138423 (Don't emit error within cast function, propagate it as a `CastError`)
- #138425 (Remove `feature = "hash_raw_entry"`)
- #138427 (Fix RISC-V VxWorks LLVM target triples)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix RISC-V VxWorks LLVM target triples
The targets `riscv32-wrs-vxworks` and `riscv64-wrs-vxworks` uses the plain `$ARCH` LLVM triple, which LLVM normalizes to `$ARCH-unknown-unknown`, we should use `$ARCH-unknown-linux-gnu$ABI` which is consistent with the the other VxWorks targets.
Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](https://github.com/rust-lang/cc-rs/issues/1431) is correct.
Alternative: Pass `$ARCH-unknown-none` in the other VxWorks LLVM triples, I don't know anything about VxWorks, so am unsure which is the most correct option.
CC target maintainer `@biabbas.`
r? jieyouxu
|
|
Don't emit error within cast function, propagate it as a `CastError`
Minor nitpick from #136764.
r? `@WaffleLapkin`
|
|
Adapt to LLVM dropping CfiFunctionIndex::begin()/end()
After https://github.com/llvm/llvm-project/pull/130382, RustWrapper needs to call CfiFunctionIndex::symbols() instead.
|
|
minor interpreter cleanups
- remove the `eval_inline_asm` hook that `@saethlin` added; the usage never materialized and he agreed with removing it
- I tried merging `init_alloc_extra` and `adjust_global_allocation` and it didn't work; leave a comment as to why. Also, make the allocation code path a bit more clear by renaming `init_alloc_extra` to `init_local_allocation`.
r? `@oli-obk`
|
|
Delegation: allow foreign fns `reuse`
In example:
```rust
unsafe extern "C" {
fn foo();
}
reuse foo as bar;
```
Desugaring before:
```rust
fn bar() {
foo()
//~^ ERROR call to unsafe function `foo` is unsafe and requires unsafe function or block
}
```
after:
```rust
unsafe extern "C" fn bar() {
foo()
}
```
Fixes https://github.com/rust-lang/rust/issues/127412
r? `@petrochenkov`
|
|
Add an opt-out in pretty printing for RTN rendering
Today, we render RPITIT types like `impl Sized { T::method(..) }` when RTN is enabled. This is very useful for diagnostics, since it's often not clear what the `impl Sized` type means by itself, and it makes it clear that that's an RPITIT that can be bounded using RTN syntax. See #115624.
However, since we don't distinguish types that are rendered for the purposes of printing messages vs suggestions, this representation leaks into suggestions and turns into code that can't be parsed. This PR adds a new `with_types_for_suggestion! {}` and `with_types_for_signature! {}` options to the pretty printing architecture to make it clear that we're rendering a type for code suggestions.
This can be applied later as we find that we need it.
|
|
Add a .bss-like scheme for encoded const allocs
This check if all bytes are zero feel like it should be too slow, and instead we should have a flag that we track, but that seems hard. Let's see how this perfs first.
Also we can probably stash the "it's all zero actually" flag inside one of the other struct members that's already not using an entire byte. This optimization doesn't fire all that often, so it's possible that by sticking it in the varint length field, this PR actually makes rmeta size worse.
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #137816 (attempt to support `BinaryFormat::Xcoff` in `naked_asm!`)
- #138109 (make precise capturing args in rustdoc Json typed)
- #138343 (Enable `f16` tests for `powf`)
- #138356 (bump libc to 0.2.171 to fix xous)
- #138371 (Update compiletest's `has_asm_support` to match rustc)
- #138404 (Cleanup sysroot locating a bit)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
r=petrochenkov,jieyouxu
Cleanup sysroot locating a bit
All commits should preserve existing behavior.
|
|
Update compiletest's `has_asm_support` to match rustc
The list of `ASM_SUPPORTED_ARCHS` was missing a few from the compiler's
actual stable list.
|
|
r=aDotInTheVoid,compiler-errors
make precise capturing args in rustdoc Json typed
close #137616
This PR includes below changes.
- Add `rustc_hir::PreciseCapturingArgKind` which allows the query system to return a arg's data.
- Add `rustdoc::clean::types::PreciseCapturingArg` and change to use it.
- Add `rustdoc-json-types::PreciseCapturingArg` and change to use it.
- Update `tests/rustdoc-json/impl-trait-precise-capturing.rs`.
- Bump `rustdoc_json_types::FORMAT_VERSION`.
|
|
attempt to support `BinaryFormat::Xcoff` in `naked_asm!`
Fixes https://github.com/rust-lang/rust/issues/137219
So, the inline assembly support for xcoff is extremely limited. The LLVM [XCOFFAsmParser](https://github.com/llvm/llvm-project/blob/1b25c0c4da968fe78921ce77736e5baef4db75e3/llvm/lib/MC/MCParser/XCOFFAsmParser.cpp) does not support many of the attributes that LLVM itself emits, and that should exist based on [the assembler docs](https://www.ibm.com/docs/en/ssw_aix_71/assembler/assembler_pdf.pdf). It also does accept some that should not exist based on those docs.
So, I've tried to do the best I can given those limitations. At least it's better than emitting the directives for elf and having that fail somewhere deep in LLVM. Given that inline assembly for this target is incomplete (under `asm_experimental_arch`), I think that's OK (and again I don't see how we can do better given the limitations in LLVM).
r? ```@Noratrieb``` (given that you reviewed https://github.com/rust-lang/rust/pull/136637)
It seems reasonable to ping the [`powerpc64-ibm-aix` target maintainers](https://doc.rust-lang.org/rustc/platform-support/aix.html), hopefully they have thoughts too: ```@daltenty``` ```@gilamn5tr```
|
|
|
|
Rather than requiring the user to pass in a correctly sized blocks map.
|
|
naked functions: on windows emit `.endef` without the symbol name
tracking issue: https://github.com/rust-lang/rust/issues/90957
fixes https://github.com/rust-lang/rust/issues/138320
The `.endef` directive does not take the name as an argument. Apparently the LLVM x86_64 parser does accept this, but on i686 it's rejected. In general `i686` does some special name mangling stuff, so it's good to include it in the naked function tests.
r? ````@ChrisDenton```` (because windows)
|
|
metadata: Ignore sysroot when doing the manual native lib search in rustc
This is the opposite alternative to https://github.com/rust-lang/rust/pull/138170 and another way to make native library search consistent between rustc and linker.
This way the directory list searched by rustc is still a prefix of the directory list considered by linker, but it's a shorter prefix than in #138170.
We can include the sysroot directories into rustc's search again later if the issues with #138170 are resolved, it will be a backward compatible change.
This may break some code doing weird things on unstable rustc, or tier 2-3 targets, like bundling `libunwind.a` or sanitizers into something.
Note that this doesn't affect shipped `libc.a`, because it lives in `self-contained` directories in sysroot, and `self-contained` sysroot is already not included into the rustc's search. All libunwind and sanitizer libs should be moved to `self-contained` sysroot too eventually.
With the consistent search directory list between rustc and linker we can make rustc own the native library search (at least for static libs) and use linker search only as a fallback (like in #123436). This will allow addressing issues like https://github.com/rust-lang/rust/pull/132394 once and for all on all targets.
r? ``@bjorn3``
|
|
The place previously used here was that of the temporary holding the
reference returned by `Deref::deref` or `DerefMut::deref_mut`. However,
since the inner pattern of `deref!(inner)` expects the deref-target type
itself, this would ICE when that type was inspected (e.g. by the EUV
case for slice patterns). This adds a deref projection to fix that.
Since current in-tree consumers of EUV (upvar inference and clippy)
don't care about Rvalues, the place could be simplified to
`self.cat_rvalue(pat.hir_id, self.pat_ty_adjusted(subpat)?)` to save
some cycles. I personally find EUV to be a bit fragile, so I've opted
for pedantic correctness. Maybe a `HACK` comment would suffice though?
|
|
|
|
what happens with provenance
|
|
This means that things like `<usize as Step>::forward_unchecked` and `<PartialOrd for f32>::le` will inline even if we've already done a bunch of inlining to find the calls to them.
|
|
Do not register `Self: AutoTrait` when confirming auto trait (in old solver)
Every built-in auto impl for a trait goal like `Ty: Auto` immediately registers another obligation of `Ty: Auto` as one of its nested obligations, leading to us stressing the cycle detection machinery a lot more than we need to. This is because all traits have a `Self: Trait` predicate.
To fix this, remove the call to `impl_or_trait_obligations` in `vtable_auto_impl`, since auto traits do not have where clauses.
r? lcnr
|
|
Rollup of 12 pull requests
Successful merges:
- #134076 (Stabilize `std::io::ErrorKind::InvalidFilename`)
- #137504 (Move methods from Map to TyCtxt, part 4.)
- #138175 (Support rmeta inputs for --crate-type=bin --emit=obj)
- #138259 (Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs)
- #138280 (fix ICE in pretty-printing `global_asm!`)
- #138318 (Rustdoc: remove a bunch of `@ts-expect-error` from main.js)
- #138331 (Use `RUSTC_LINT_FLAGS` more)
- #138357 (merge `TypeChecker` and `TypeVerifier`)
- #138394 (remove unnecessary variant)
- #138403 (Delegation: one more ICE fix for `MethodCall` generation)
- #138407 (Delegation: reject C-variadics)
- #138409 (Use sa_sigaction instead of sa_union.__su_sigaction for AIX)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
`uclibc` is not an environment understood by LLVM, it is only a concept
in Clang that can be selected with `-muclibc` (it affects which dynamic
linker is passed to the static linker's `-dynamic-linker` flag).
In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it
prevents LLVM from seeing that the target is gnu-like; we should use
`gnueabi`/`gnu` directly instead.
|
|
In LLVM v9, lld has supported @response-file
LLVM v9 was released on 2019-09-19.
And the check was added back to 2018-03-14 (1.26.0) via 04442af18bf0.
It has been more than five years, and we ship our own lld regardlessly.
This should be happily removed.
See also:
* <https://github.com/llvm/llvm-project/commit/bb12396f9175eaf4586d8e5c76441977d97ccf93>
* <https://reviews.llvm.org/D63024>
|
|
Calculate predecessor count directly
Avoid allocating a vector of small vectors merely to determine how many
predecessors each basic block has.
Additionally use u8 and saturating operations. The pass only needs to
distinguish between [0..1] and [2..].
|
|
It was previously normalized by LLVM to `thumbv7a-vita-unknown-eabihf`,
which is probably wrong, as Vita is the OS.
|
|
The targets used the plain `$ARCH` triple, which LLVM normalizes to
`$ARCH-unknown-unknown`, which is inconsistent with the the other
VxWorks targets which all use `$ARCH-unknown-linux-gnu$ABI`.
|
|
|
|
|
|
After https://github.com/llvm/llvm-project/pull/130382, RustWrapper
needs to call CfiFunctionIndex::symbols() instead.
|
|
|
