Commit Graph

874 Commits

Author SHA1 Message Date
Nicholas Nethercote
7c40661ddb Update smallvec to 1.8.1.
This pulls in https://github.com/servo/rust-smallvec/pull/282, which
gives some small wins for rustc.
2022-06-27 08:48:55 +10:00
Yuki Okushi
33eb3c05c5
Rollup merge of #98214 - petrochenkov:islike, r=compiler-errors
rustc_target: Remove some redundant target properties

`is_like_emscripten` is equivalent to `os == "emscripten"`, so it's removed.
`is_like_fuchsia` is equivalent to `os == "fuchsia"`, so it's removed.
`is_like_osx` also falls into the same category and is equivalent to `vendor == "apple"`, but it's commonly used so I kept it as is for now.

`is_like_(solaris,windows,wasm)` are combinations of different operating systems or architectures (see compiler/rustc_target/src/spec/tests/tests_impl.rs) so they are also kept as is.

I think `is_like_wasm` (and maybe `is_like_osx`) are sufficiently closed sets, so we can remove these fields as well and replace them with methods like `fn is_like_wasm() { arch == "wasm32" || arch == "wasm64" }`.
On other hand, `is_like_solaris` and `is_like_windows` are sufficiently open and I can imagine custom targets introducing other values for `os`.
This is kind of a gray area.
2022-06-24 16:43:45 +09:00
Yuki Okushi
0af99c99c4
Rollup merge of #97633 - mkroening:object-osabi, r=petrochenkov
Session object: Set OS/ABI

Closes https://github.com/rust-lang/rust/issues/97535.

This depends on
* https://github.com/gimli-rs/object/pull/438

This adapts LLVM's behavior of [`MCELFObjectTargetWriter::getOSABI`](8c8a2679a2/llvm/include/llvm/MC/MCELFObjectWriter.h (L72-L86)).
2022-06-24 16:43:43 +09:00
Michael Goulet
cc45ad50f8
Rollup merge of #98355 - hoodmane:emscripten-no-default, r=petrochenkov
Update no_default_libraries handling for emscripten target

```@sbc100``` says:

> `-sDEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]` is almost certainly wrong/out-of-date.   This setting defaults to the empty list anyway these days so its redundant.  Also we now support `-nodefaultlibs` so you can use that, as with other toolchains.

https://github.com/rust-lang/rust/issues/98303#issuecomment-1162163684
2022-06-23 14:39:12 -07:00
Martin Kröning
21625e5730 Session object: Set OS/ABI
This adapts LLVM's behavior of MCELFObjectTargetWriter::getOSABI [1].

[1]: 8c8a2679a2/llvm/include/llvm/MC/MCELFObjectWriter.h (L72-L86)
2022-06-23 11:20:52 +02:00
Hood Chatham
8e09f42042 Update Emscripten's no_default_libraries handling 2022-06-21 13:21:16 -07:00
bors
dc80ca78b6 Auto merge of #98098 - bjorn3:archive_refactor, r=michaelwoerister
Remove the source archive functionality of ArchiveWriter

We now build archives through strictly additive means rather than taking an existing archive and potentially substracting parts. This is simpler and makes it easier to swap out the archive writer in https://github.com/rust-lang/rust/pull/97485.
2022-06-21 16:24:56 +00:00
bors
a25b1315ee Auto merge of #95576 - DrMeepster:box_erasure, r=oli-obk
Remove dereferencing of Box from codegen

Through #94043, #94414, #94873, and #95328, I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However, these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains.

Hopefully, this is the end of the Box<T, A> ICEs.
2022-06-21 11:00:39 +00:00
Dylan DPC
88cb597e7a
Rollup merge of #98146 - hoodmane:remove-memory-init-flag, r=petrochenkov
Remove --memory-init-file flag when linking with Emscripten

This flag does nothing. It only applies when generating asmjs JavaScript.
``@sbc100``
2022-06-19 15:26:29 +02:00
bjorn3
18c6fe5798 Remove the source archive functionality of ArchiveWriter
We now build archives through strictly additive means rather than taking
an existing archive and potentially substracting parts.
2022-06-19 12:56:31 +00:00
bjorn3
7ff0df5102 Fix "Remove src_files and remove_file" 2022-06-19 12:56:31 +00:00
Hood Chatham
3fb6d45af9 ENH Move --memory-init-file flag from EmLinker to asmjs target spec 2022-06-18 17:48:00 -07:00
Matthias Krüger
f351f347b8
Rollup merge of #98165 - WaffleLapkin:once_things_renamings, r=m-ou-se
once cell renamings

This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128

- Move/rename `lazy::{OnceCell, Lazy}` to `cell::{OnceCell, LazyCell}`
- Move/rename `lazy::{SyncOnceCell, SyncLazy}` to `sync::{OnceLock, LazyLock}`

(I used `Lazy...` instead of `...Lazy` as it seems to be more consistent, easier to pronounce, etc)

```@rustbot``` label +T-libs-api -T-libs
2022-06-19 00:17:13 +02:00
Yuki Okushi
d9559f4514
Rollup merge of #98150 - hoodmane:emscripten-g4, r=sbc100
Emscripten target: replace -g4 with -g, and -g3 with --profiling-funcs

Emscripten prints the following warning:
```
emcc: warning: please replace -g4 with -gsource-map [-Wdeprecated]
```
`@sbc100`
2022-06-18 10:03:24 +09:00
Vadim Petrochenkov
37fd2941a1 rustc_target: Remove some redundant target properties 2022-06-18 01:09:20 +03:00
Hood Chatham
a2ecf5b2f7 Replace -g4 with -gsource-map 2022-06-17 10:52:10 -07:00
bors
0423e06ca9 Auto merge of #98160 - nnethercote:mv-finish-out-of-Encoder, r=bjorn3
Move `finish` out of the `Encoder` trait.

This simplifies things, but requires making `CacheEncoder` non-generic.

(This was previously merged as commit 4 in #94732 and then was reverted
in #97905 because it caused a perf regression.)

r? `@ghost`
2022-06-17 05:13:07 +00:00
Maybe Waffle
7c360dc117 Move/rename lazy::{OnceCell, Lazy} to cell::{OnceCell, LazyCell} 2022-06-16 19:53:59 +04:00
Matthias Krüger
95be954af4
Rollup merge of #97757 - xFrednet:rfc-2383-expect-with-force-warn, r=wesleywiser,flip1995
Support lint expectations for `--force-warn` lints (RFC 2383)

Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.

This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.

This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.

---

r? `@wesleywiser`

cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃

Follow-up of: https://github.com/rust-lang/rust/pull/87835

Issue: https://github.com/rust-lang/rust/issues/85549

Yeah, and that's it.
2022-06-16 09:10:20 +02:00
Nicholas Nethercote
bb02cc47c4 Move finish out of the Encoder trait.
This simplifies things, but requires making `CacheEncoder` non-generic.

(This was previously merged as commit 4 in #94732 and then was reverted
in #97905 because it caused a perf regression.)
2022-06-16 16:20:32 +10:00
xFrednet
8527a3d369
Support lint expectations for --force-warn lints (RFC 2383) 2022-06-16 08:16:43 +02:00
DrMeepster
1d1ff36214 fix codegen assertion 2022-06-15 18:39:23 -07:00
DrMeepster
cb417881a9 remove box derefs from codgen 2022-06-15 18:38:26 -07:00
Yuki Okushi
97b9347c93
Rollup merge of #98083 - nnethercote:rename-Encoder, r=bjorn3
Rename rustc_serialize::opaque::Encoder as MemEncoder.

This avoids the name clash with `rustc_serialize::Encoder` (a trait),
and allows lots qualifiers to be removed and imports to be simplified
(e.g. fewer `as` imports).

(This was previously merged as commit 5 in #94732 and then was reverted
in #97905 because of a perf regression caused by commit 4 in #94732.)

r? ```@bjorn3```
2022-06-15 12:02:04 +09:00
Yuki Okushi
2722c2aa33
Rollup merge of #98078 - erikdesjardins:uncheckedsize, r=petrochenkov
Use unchecked mul to compute slice sizes

This allows LLVM to realize that `slice.len() > 0` iff `slice.len() * size_of::<T>() > 0`, allowing a branch on the latter to be folded into the former when dropping vecs and boxed slices, in some cases.

Fixes (partially) #96497
2022-06-15 12:02:03 +09:00
bors
2d1e075079 Auto merge of #96285 - flip1995:pk-vfe, r=nagisa
Introduce `-Zvirtual-function-elimination` codegen flag

Fixes #68262

This PR adds a codegen flag `-Zvirtual-function-elimination` to enable the VFE optimization in LLVM. To make this work, additonal  information has to be added to vtables ([`!vcall_visibility` metadata](https://llvm.org/docs/TypeMetadata.html#vcall-visibility-metadata) and a `typeid` of the trait). Furthermore, instead of just `load`ing functions, the [`llvm.type.checked.load` intrinsic](https://llvm.org/docs/LangRef.html#llvm-type-checked-load-intrinsic) has to be used to map functions to vtables.

For technical details of the changes, see the commit messages.

I also tested this flag on https://github.com/tock/tock on different boards to verify that this fixes the issue https://github.com/tock/tock/issues/2594. This flag is able to improve the size of the resulting binary by about 8k-9k bytes by removing the unused debug print functions.

[Rendered documentation update](https://github.com/flip1995/rust/blob/pk-vfe/src/doc/rustc/src/codegen-options/index.md#virtual-function-elimination)
2022-06-14 21:37:11 +00:00
Erik Desjardins
50f6a9ed87 use unchecked mul to compute slice sizes
...since slice sizes can't signed wrap

see https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

> The total size len * mem::size_of::<T>() of the slice must be no larger than isize::MAX.
2022-06-14 17:09:07 -04:00
bjorn3
43929a8a75 Remove src_files and remove_file
They only apply to the main source archive and their role can be
fulfilled through the skip argument of add_archive too.
2022-06-14 15:11:14 +00:00
b-naber
e14b34c386 account for endianness in debuginfo for const args 2022-06-14 16:12:34 +02:00
b-naber
060acc97db rebase 2022-06-14 16:12:28 +02:00
b-naber
705d818bd5 implement valtrees as the type-system representation for constant values 2022-06-14 16:07:11 +02:00
flip1995
e1c1d0f8c2
Add llvm.type.checked.load intrinsic
Add the intrinsic

declare {i8*, i1} @llvm.type.checked.load(i8* %ptr, i32 %offset, metadata %type)

This is used in the VFE optimization when lowering loading functions
from vtables to LLVM IR. The `metadata` is used to map the function to
all vtables this function could belong to. This ensures that functions
from vtables that might be used somewhere won't get removed.
2022-06-14 14:50:52 +02:00
Dylan DPC
9e5c5c57e9
Rollup merge of #97935 - nnethercote:rename-ConstS-val-as-kind, r=lcnr
Rename the `ConstS::val` field as `kind`.

And likewise for the `Const::val` method.

Because its type is called `ConstKind`. Also `val` is a confusing name
because `ConstKind` is an enum with seven variants, one of which is
called `Value`. Also, this gives consistency with `TyS` and `PredicateS`
which have `kind` fields.

The commit also renames a few `Const` variables from `val` to `c`, to
avoid confusion with the `ConstKind::Value` variant.

r? `@BoxyUwU`
2022-06-14 10:35:29 +02:00
Nicholas Nethercote
abe45a9ffa Rename rustc_serialize::opaque::Encoder as MemEncoder.
This avoids the name clash with `rustc_serialize::Encoder` (a trait),
and allows lots qualifiers to be removed and imports to be simplified
(e.g. fewer `as` imports).

(This was previously merged as commit 5 in #94732 and then was reverted
in #97905 because of a perf regression caused by commit 4 in #94732.)
2022-06-14 14:52:01 +10:00
Nicholas Nethercote
93e4b6ef06 Rename the ConstS::val field as kind.
And likewise for the `Const::val` method.

Because its type is called `ConstKind`. Also `val` is a confusing name
because `ConstKind` is an enum with seven variants, one of which is
called `Value`. Also, this gives consistency with `TyS` and `PredicateS`
which have `kind` fields.

The commit also renames a few `Const` variables from `val` to `c`, to
avoid confusion with the `ConstKind::Value` variant.
2022-06-14 13:06:44 +10:00
Yuki Okushi
537920eedb
Rollup merge of #95243 - vladimir-ea:compiler_watch_os, r=nagisa
Add Apple WatchOS compile targets

Hello,

I would like to add the following target triples for Apple WatchOS as Tier 3 platforms:

armv7k-apple-watchos
arm64_32-apple-watchos
x86_64-apple-watchos-sim
There are some pre-requisites Pull Requests:
https://github.com/rust-lang/compiler-builtins/pull/456 (merged)
https://github.com/alexcrichton/cc-rs/pull/662 (pending)
https://github.com/rust-lang/libc/pull/2717 (merged)

There will be a subsequent PR with standard library changes for WatchOS.  Previous compiler and library changes were in a single PR (https://github.com/rust-lang/rust/pull/94736) which is now closed in favour of separate PRs.

Many thanks!
Vlad.

### Tier 3 Target Requirements

Adds support for Apple WatchOS compile targets.

Below are details on how this target meets the requirements for tier 3:

>   tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

`@deg4uss3r` has volunteered to be the target maintainer. I am also happy to help if a second maintainer is required.

> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

Uses the same naming as the LLVM target, and the same convention as other Apple targets.

> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

I don't believe there is any ambiguity here.

> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

I don't see any legal issues here.

> The target must not introduce license incompatibilities.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
> If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

I see no issues with any of the above.

> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

Only relevant to those making approval decisions.

> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

core and alloc can be used. std support will be added in a subsequent PR.

> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Use --target=<target> option to cross compile, just like any target. Tests can be run using the WatchOS simulator (see https://developer.apple.com/documentation/xcode/running-your-app-in-the-simulator-or-on-a-device).

> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

I don't foresee this being a problem.

> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

No other targets should be affected by the pull request.
2022-06-14 07:47:23 +09:00
Vladimir Michael Eatwell
dc5c61028a Add Apple WatchOS compile targets 2022-06-13 16:08:53 +01:00
David Knaack
8558b35295 Use safer strip=symbols-flag for dylibs on macOS 2022-06-11 13:20:17 +02:00
bors
c84594661c Auto merge of #97905 - nnethercote:revert-infallible-encoder, r=bjorn3
Revert part of #94372 to improve performance

#94732 was supposed to give small but widespread performance improvements, as judged from three per-merge performance runs. But the performance run that occurred after merging included a roughly equal number of improvements and regressions, for unclear reasons.

This PR is for a test run reverting those changes, to see what happens.

r? `@ghost`
2022-06-11 04:00:23 +00:00
Nicholas Nethercote
3186e311e5 Revert dc08bc51f2. 2022-06-10 11:58:29 +10:00
Nicholas Nethercote
7f51a1b976 Revert b983e42936. 2022-06-10 08:35:03 +10:00
Vadim Petrochenkov
a8ee1f3a4f Stabilize the bundle native library modifier 2022-06-09 23:12:58 +04:00
Nicholas Nethercote
b983e42936 Rename rustc_serialize::opaque::Encoder as MemEncoder.
This avoids the name clash with `rustc_serialize::Encoder` (a trait),
and allows lots qualifiers to be removed and imports to be simplified
(e.g. fewer `as` imports).
2022-06-08 09:50:44 +10:00
Nicholas Nethercote
dc08bc51f2 Move finish out of the Encoder trait.
This simplifies things, but requires making `CacheEncoder` non-generic.
2022-06-08 09:21:05 +10:00
Nicholas Nethercote
1acbe7573d Use delayed error handling for Encodable and Encoder infallible.
There are two impls of the `Encoder` trait: `opaque::Encoder` and
`opaque::FileEncoder`. The former encodes into memory and is infallible, the
latter writes to file and is fallible.

Currently, standard `Result`/`?`/`unwrap` error handling is used, but this is a
bit verbose and has non-trivial cost, which is annoying given how rare failures
are (especially in the infallible `opaque::Encoder` case).

This commit changes how `Encoder` fallibility is handled. All the `emit_*`
methods are now infallible. `opaque::Encoder` requires no great changes for
this. `opaque::FileEncoder` now implements a delayed error handling strategy.
If a failure occurs, it records this via the `res` field, and all subsequent
encoding operations are skipped if `res` indicates an error has occurred. Once
encoding is complete, the new `finish` method is called, which returns a
`Result`. In other words, there is now a single `Result`-producing method
instead of many of them.

This has very little effect on how any file errors are reported if
`opaque::FileEncoder` has any failures.

Much of this commit is boring mechanical changes, removing `Result` return
values and `?` or `unwrap` from expressions. The more interesting parts are as
follows.
- serialize.rs: The `Encoder` trait gains an `Ok` associated type. The
  `into_inner` method is changed into `finish`, which returns
  `Result<Vec<u8>, !>`.
- opaque.rs: The `FileEncoder` adopts the delayed error handling
  strategy. Its `Ok` type is a `usize`, returning the number of bytes
  written, replacing previous uses of `FileEncoder::position`.
- Various methods that take an encoder now consume it, rather than being
  passed a mutable reference, e.g. `serialize_query_result_cache`.
2022-06-08 07:01:26 +10:00
Nicholas Nethercote
582b9cbc45 Don't pass in a vector to Encoder::new.
It's not necessary.
2022-06-08 07:01:26 +10:00
Nicholas Nethercote
92b1ab8d57 Remove an unnecessary encoder operation. 2022-06-08 07:01:26 +10:00
Dylan DPC
95266530d5
Rollup merge of #97808 - alexcrichton:wasm-features, r=petrochenkov
Add some unstable target features for the wasm target codegen

I was experimenting with cross-language LTO for the wasm target recently
between Rust and C and found that C was injecting the `+mutable-globals`
flag on all functions. When specifying the corresponding
`-Ctarget-feature=+mutable-globals` feature to Rust it prints a warning
about an unknown feature. I've added the `mutable-globals` feature plus
another few I know of to the list of known features for wasm targets.
These features all continue to be unstable to source code as they were
before.
2022-06-07 11:41:09 +02:00
Dylan DPC
62c260de8c
Rollup merge of #97738 - Kixiron:zst-panic, r=eddyb
Fix ICEs from zsts within unsized types with non-zero offsets

- Fixes #97732
- Fixes ICEs while compiling `alloc` with `-Z randomize-layout`

r? ``@eddyb``
2022-06-07 11:41:08 +02:00
Dylan DPC
ab1027ad0f
Rollup merge of #97058 - bjorn3:multi_artifact_work_products, r=nagisa
Various refactors to the incr comp workproduct handling

This is the result of me looking into adding support for having multiple object files for a single codegen unit to incr comp. This is necessary to support inline assembly in cg_clif without requiring partial linking which is not supported on Windows and seems to fail on macOS for some reason. Cg_clif uses an external assembler to handle inline asm and thus produces one object file with regular functions and one object file containing compiled inline asm for each codegen unit which uses inline asm. Current incr comp can't handle this. This PR doesn't yet add support for this, but it makes it easier to do so.
2022-06-07 11:41:06 +02:00