Update pkg-config
I'd like to be able to cross-compile rustc in a scenario where it'd be really helpful to have cd3ccca7c3. I've done some test builds of the compiler on x86_64 linux, targeting x86_64 linux and aarch64 linux.
12 commits in b8f30cb23c4e5f20854a4f683325782b7cff9837..b332991a57c9d055f1864de1eed93e2178d49440
2022-10-10 19:16:06 +0000 to 2022-10-13 22:05:28 +0000
- Differentiate the warning when an alias (built-in or user-defined) shadows an external subcommand (rust-lang/cargo#11170)
- chore: Update tests for latest clap (rust-lang/cargo#11235)
- feat(publish): Support 'publish.timeout' config behind '-Zpublish-timeout' (rust-lang/cargo#11230)
- Add missing edition (rust-lang/cargo#11231)
- doc(profiles): add module level doc (rust-lang/cargo#11219)
- refactor(publish): Clarify which SourceId is being used (rust-lang/cargo#11216)
- Add new SourceKind::SparseRegistry to differentiate sparse registries (rust-lang/cargo#11209)
- Fix deadlock when build scripts are waiting for input on stdin (rust-lang/cargo#11205)
- refactor: New variant `FeaturesFor::ArtifactDep` (rust-lang/cargo#11184)
- Fix rustdoc warning about unclosed HTML tag (rust-lang/cargo#11221)
- refactor(tests): Prepare for wait-for-publish test changes (rust-lang/cargo#11210)
- Add configuration option for controlling crates.io protocol (rust-lang/cargo#11215)
Miri sync
This is a Miri sync created with my experimental fork of josh. We should probably not merge this yet, but we can use this to check if the sync looks the way it should.
r? `@oli-obk`
resolve error when attempting to link a universal library on macOS
Previously attempting to link universal libraries into libraries (but not binaries) would produce an error that "File too small to be an archive". This works around this by invoking `lipo -thin` to extract a library for the target platform when passed a univeral library.
Fixes#55235
It's worth acknowledging that this implementation is kind of a horrible hack. Unfortunately I don't know how to do anything better, hopefully this PR will be a jumping off point.
Previously attempting to link universal libraries into libraries (but not binaries) would produce an error that "File too small to be an archive". This works around this by using `object` to extract a library for the target platform when passed a univeral library.
Fixes#55235
Migrate more of rustc_parse to SessionDiagnostic
Still far from complete, but I thought I'd add a checkpoint here because rebasing was starting to get annoying.
Remove support for legacy PM
This removes support for optimizing with LLVM's legacy pass manager, as well as the unstable `-Znew-llvm-pass-manager` option. We have been defaulting to the new PM since LLVM 13 (except for s390x that waited for 14), and LLVM 15 removed support altogether. The only place we still use the legacy PM is for writing the output file, just like `llc` does.
cc #74705
r? ``@nikic``
Update stdarch
This pulls in the following changes:
- [Use simd_bitmask intrinsic in a couple of places](9f0928782b)
- [Remove simd_shuffle<n> usage in favor of simd_shuffle](3fd17e4607)
- [Remove late specifiers in __cpuid_count](f1db941633)
- Helps with #101346
- [Use mov and xchg instead of movl(q) and xchgl(q)](3049a31937)
- [Bump cfg-if dependency to 1.0](f305cc83e7)
- [Fix documentation of __m256bh and __m512bh structs](699c093a42)
r? ``@Amanieu``
A lot of the types in this crate implemented HashStable directly to
avoid circular dependencies. One way around that is to use
HashStable_Generic. We adopt that here to avoid a lot of boilerplate.
This doesn't update all the types, because some would require
`I: Interner + HashStable`.
safe transmute: use `Assume` struct to provide analysis options
This task was left as a TODO in #92268; resolving it brings [`BikeshedIntrinsicFrom`](https://doc.rust-lang.org/nightly/core/mem/trait.BikeshedIntrinsicFrom.html) more in line with the API defined in [MCP411](https://github.com/rust-lang/compiler-team/issues/411).
**Before:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<
Src,
Context,
const ASSUME_ALIGNMENT: bool,
const ASSUME_LIFETIMES: bool,
const ASSUME_VALIDITY: bool,
const ASSUME_VISIBILITY: bool,
> where
Src: ?Sized,
{}
```
**After:**
```rust
pub unsafe trait BikeshedIntrinsicFrom<Src, Context, const ASSUME: Assume = { Assume::NOTHING }>
where
Src: ?Sized,
{}
```
`Assume::visibility` has also been renamed to `Assume::safety`, as library safety invariants are what's actually being assumed; visibility is just the mechanism by which it is currently checked (and that may change).
r? `@oli-obk`
---
Related:
- https://github.com/rust-lang/compiler-team/issues/411
- https://github.com/rust-lang/rust/issues/99571
Generate error index with mdbook instead of raw HTML pages
This is a follow-up of https://github.com/rust-lang/rust/pull/100922.
This comes from a remark from ````@estebank```` who said that the search was a nice thing on the previous version and that it wasn't possible anymore. An easy way to come around this limitation was to use `mdbook`, which is what I did here.
Now some explanations on the code. I'll explain how I developed this and why I reached this solution. First I did it very basically by simply setting the source directory and the output directory, generated a `SUMMARY.md` manually which listed all error codes and that was it. Two problems arose from this:
1. A lot of new HTML files were generated at the top level
2. An `index.html` file was generated at the top-level (the summary in short).
So for `1.`, it's not great to have too many files at the top-level as it could create file conflicts more easily. And for `2.`, this is actually a huge issue because <doc.rust-lang.org> generates an `index.html` file with a links to a few different resources, so it should never be overwritten. <s>Unfortunately, `mdbook` **always** generates an `index.html` file so the only solution I could see (except for sending them a contribution, I'll maybe do that later) was to temporaly move a potentially existing `index.html` file and then puts it back once done. For this last part, to ensure that we don't return *before* it has been put back, I wrapped the `mdbook` generation code inside `render_html_inner` which is called from `render_html` which in turn handle the "save" of `index.html`.</s>
EDIT: `mdbook` completely deletes ALL the content in the target directory so I instead generate into a sub directory and then I move the files to the real target directory.
To keep compatibility with the old version, I also put the `<script>` ````@notriddle```` nicely provided in the previous PR only into the `error-index.html` file to prevent unneeded repetition. I didn't use `mdbook` `additional-js` option because the JS is included at the end of all HTML files, which we don't want for two reasons:
1. It's slow.
2. We only want it to be run in `error-index.html` (even if we also ensure in the JS itself too!).
<s>Now the last part: why we generate the summary twice. We actually generate it once to tell `mdbook` what the book will look like and a second time because a create a new chapter content which will actually list all the error codes (with the updated paths).</s>
EDIT: I removed the need for two summaries.
You can test it [here](https://rustdoc.crud.net/imperio/error-index-mdbook/error-index.html).
r? ````@notriddle````
Replace `rustc_data_structures::thin_vec::ThinVec` with `thin_vec::ThinVec`
`rustc_data_structures::thin_vec::ThinVec` looks like this:
```
pub struct ThinVec<T>(Option<Box<Vec<T>>>);
```
It's just a zero word if the vector is empty, but requires two
allocations if it is non-empty. So it's only usable in cases where the
vector is empty most of the time.
This commit removes it in favour of `thin_vec::ThinVec`, which is also
word-sized, but stores the length and capacity in the same allocation as
the elements. It's good in a wider variety of situation, e.g. in enum
variants where the vector is usually/always non-empty.
The commit also:
- Sorts some `Cargo.toml` dependency lists, to make additions easier.
- Sorts some `use` item lists, to make additions easier.
- Changes `clean_trait_ref_with_bindings` to take a
`ThinVec<TypeBinding>` rather than a `&[TypeBinding]`, because this
avoid some unnecessary allocations.
r? `@spastorino`
- ... when creating diagnostics in rustc_metadata
- use the error_code! macro
- pass macro output to diag.code()
- use fluent from within manual implementation of SessionDiagnostic
- emit the untested errors in case they occur in the wild
- stop panicking in the probably-not-dead code, add fixme to write test
Migrate rustc_monomorphize to use SessionDiagnostic
### Description
- Migrates diagnostics in `rustc_monomorphize` to use `SessionDiagnostic`
- Adds an `impl IntoDiagnosticArg for PathBuf`
### TODO / Help!
- [x] I'm having trouble figuring out how to apply an optional note. 😕 Help!?
- Resolved. It was bad docs. Fixed in https://github.com/rust-lang/rustc-dev-guide/pull/1437/files
- [x] `errors:RecursionLimit` should be `#[fatal ...]`, but that doesn't exist so it's `#[error ...]` at the moment.
- Maybe I can switch after this is merged in? --> https://github.com/rust-lang/rust/pull/100694
- Or maybe I need to manually implement `SessionDiagnostic` instead of deriving it?
- [x] How does one go about converting an error inside of [a call to struct_span_lint_hir](8064a49508/compiler/rustc_monomorphize/src/collector.rs (L917-L927))?
- [x] ~What placeholder do you use in the fluent template to refer to the value in a vector? It seems like [this code](0b79f758c9/compiler/rustc_macros/src/diagnostics/diagnostic_builder.rs (L83-L114)) ought to have the answer (or something near it)...but I can't figure it out.~ You can't. Punted.
Rollup of 5 pull requests
Successful merges:
- #99517 (Display raw pointer as *{mut,const} T instead of *-ptr in errors)
- #99928 (Do not leak type variables from opaque type relation)
- #100473 (Attempt to normalize `FnDef` signature in `InferCtxt::cmp`)
- #100653 (Move the cast_float_to_int fallback code to GCC)
- #100941 (Point at the string inside literal and mention if we need string inte…)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Move the cast_float_to_int fallback code to GCC
Now that we require at least LLVM 13, that codegen backend is always
using its intrinsic `fptosi.sat` and `fptoui.sat` conversions, so it
doesn't need the manual implementation. However, the GCC backend still
needs it, so we can move all of that code down there.
Use object instead of LLVM for reading bitcode from rlibs
Together with changes I plan to make as part of https://github.com/rust-lang/rust/pull/97485 this will allow entirely removing usage of LLVM's archive reader and thus allow removing `archive_ro.rs` and `ArchiveWrapper.cpp`.
5 commits in 6da726708a4406f31f996d813790818dce837161..4ed54cecce3ce9ab6ff058781f4c8a500ee6b8b5
2022-08-23 21:39:56 +0000 to 2022-08-27 18:41:39 +0000
- doc: pause, for readability (rust-lang/cargo#11027)
- Bump git2 to 0.15 and libgit2-sys to 0.14 (rust-lang/cargo#11004)
- Fix typo (rust-lang/cargo#11025)
- Update cargo-toml-vs-cargo-lock.md (rust-lang/cargo#11021)
- Apply GitHub fast path even for partial hashes (rust-lang/cargo#10807)
`rustc_data_structures::thin_vec::ThinVec` looks like this:
```
pub struct ThinVec<T>(Option<Box<Vec<T>>>);
```
It's just a zero word if the vector is empty, but requires two
allocations if it is non-empty. So it's only usable in cases where the
vector is empty most of the time.
This commit removes it in favour of `thin_vec::ThinVec`, which is also
word-sized, but stores the length and capacity in the same allocation as
the elements. It's good in a wider variety of situation, e.g. in enum
variants where the vector is usually/always non-empty.
The commit also:
- Sorts some `Cargo.toml` dependency lists, to make additions easier.
- Sorts some `use` item lists, to make additions easier.
- Changes `clean_trait_ref_with_bindings` to take a
`ThinVec<TypeBinding>` rather than a `&[TypeBinding]`, because this
avoid some unnecessary allocations.
Migrate rustc_driver to SessionDiagnostic
First timer noob here 👋🏽 I'm having a problem understanding how I can retrieve the span, and how to properly construct the error structs to avoid the current compilation errors.
Any help pointing me in the right direction would be much appreciated 🙌🏽
Migrate `rustc_ty_utils` to `SessionDiagnostic`
I have migrated the `rustc_ty_utils` crate to use `SessionDiagnostic`, motivated by the [recent blog post about the diagnostic translation effort](https://blog.rust-lang.org/inside-rust/2022/08/16/diagnostic-effort.html).
This is my first PR to the Rust repository, so if I have missed anything, or anything needs to be changed, please let me know! 😄
`@rustbot` label +A-translation
Migrate ast lowering to session diagnostic
I migrated the whole rustc_ast_lowering crate to session diagnostic *except* the for the use of `span_fatal` at /compiler/rustc_ast_lowering/src/expr.rs#L1268 because `#[fatal(...)]` is not yet supported (see https://github.com/rust-lang/rust/pull/100694).
Migrate `rustc_plugin_impl` to `SessionDiagnostic`
Migration of the `rustc_plugin_impl` crate.
~Draft PR because it is blocked on #100694 for `#[fatal(...)]` support~ (this has been merged, and I've changed over to `#[diag(...)]` now too), but I would also like to know if what I did with `LoadPluginError` is okay, because all it does is display the error message from `libloading` ([See conversation on zulip](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.23100717.20diagnostic.20translation/near/294327843)). This crate is apparently for a deprecated feature which is used by servo, so I don't know how much this matters anyway.
Update cargo
3 commits in efd4ca3dc0b89929dc8c5f5c023d25978d76cb61..9809f8ff33c2b998919fd0432c626f0f7323697a
2022-08-12 01:28:28 +0000 to 2022-08-16 22:10:06 +0000
- Improve error message for an array value in the manifest (rust-lang/cargo#10944)
- Fix file locking being not supported on Android raising an error (rust-lang/cargo#10975)
- Bump to 0.66.0, update changelog (rust-lang/cargo#10983)
Migrate emoji identifier diagnostics to `SessionDiagnostic` in rustc_interface
* Migrate emoji identifier diagnostics to `interface_ferris_identifier` and `interface_emoji_identifier`.
This is my first PR! I'm learning how to migrate these diagnostics. Thanks in advance.
r? rust-lang/diagnostics
Now that we require at least LLVM 13, that codegen backend is always
using its intrinsic `fptosi.sat` and `fptoui.sat` conversions, so it
doesn't need the manual implementation. However, the GCC backend still
needs it, so we can move all of that code down there.
Update cargo
8 commits in ce40690a5e4e315d3dab0aae1eae69d0252c52ac..efd4ca3dc0b89929dc8c5f5c023d25978d76cb61
2022-08-09 22:32:17 +0000 to 2022-08-12 01:28:28 +0000
- Use `std:🧵:scope` to replace crossbeam (rust-lang/cargo#10977)
- [docs] Remove extra "in" from `cargo-test.md` (rust-lang/cargo#10978)
- Enable two windows tests (rust-lang/cargo#10930)
- Improve error msg for get target runner (rust-lang/cargo#10968)
- Ensure rustc-echo-wrapper works with an overridden build.target-dir (rust-lang/cargo#10962)
- Switch back to `available_parallelism` (rust-lang/cargo#10969)
- Only override published resolver when the workspace is different (rust-lang/cargo#10961)
- Add `CARGO_LOG` to "Environment variables Cargo reads" (rust-lang/cargo#10967)
compiletest: use target cfg instead of hard-coded tables
This changes compiletest to use `rustc --print=cfg` to dynamically determine the properties of a target when matching `ignore` and `only` rules instead of using hard-coded tables or target-triple parsing (which don't always follow the `<arch><sub>-<vendor>-<sys>-<abi>` pattern). The benefit here is that it will more accurately match the target properties, and not require maintaining these extra tables.
This also adds matching the `target_family` in ignore rules. The primary benefit here is so that `ignore-wasm` works as expected (matching all wasm-like targets). There were already several tests that had `ignore-wasm` in them (which previously had no effect), so it is evident that some people expected that to work. This also adds `ignore-unix/only-unix`.
There is some risk that this changes the behavior from before since the tables aren't quite the same as the target properties. However, I did fairly extensive comparisons to see what would be different. https://gist.github.com/ehuss/5bf7ab347605160cefb6f84ba5ea5f6b contains a full list of differences for all targets for all tests. I do not think any of the affected target/test combinations are things that are actually tested in CI. I tested several of the more unusual test images (test-various, dist-various-1, wasm32), and they seem fine.
A summary of most of the reasons behind the differences:
- wasm64-unknown-unknown wasm32-wasi now match "wasm"
- Targets now match "gnu" because they have target_env=gnu
- aarch64-wrs-vxworks
- armv7-wrs-vxworks-eabihf
- i686-wrs-vxworks
- powerpc-wrs-vxworks
- powerpc64-wrs-vxworks
- x86_64-wrs-vxworks
- wasm64-unknown-unknown now matches wasm64
- x86_64-unknown-none-linuxkernel no longer matches "linux", but will match "gnu" and "none"
- Various arm targets now match "aarch64" or "arm":
- arm64_32-apple-watchos
- armebv7r-none-eabi
- armv6-unknown-freebsd
- armv6-unknown-netbsd-eabihf
- armv6k-nintendo-3ds
- armv7-wrs-vxworks-eabihf
- armv7a-kmc-solid_asp3-eabi
- armv7a-kmc-solid_asp3-eabihf
- armv7a-none-eabi
- armv7a-none-eabihf
- armv7k-apple-watchos
- armv7r-none-eabi
- armv7r-none-eabihf
- Now matches "thumb" and "arm"
- thumbv4t-none-eabi
- thumbv6m-none-eabi
- thumbv7a-pc-windows-msvc
- thumbv7a-uwp-windows-msvc
- thumbv7em-none-eabi
- thumbv7em-none-eabihf
- thumbv7m-none-eabi
- thumbv7neon-linux-androideabi
- thumbv7neon-unknown-linux-gnueabihf
- thumbv7neon-unknown-linux-musleabihf
- thumbv8m.base-none-eabi
- thumbv8m.main-none-eabi
- asmjs-unknown-emscripten now matches "wasm32" because that it is its defined arch
- avr-unknown-gnu-atmega328 now matches "none" (because target_os="none")
- now matches 64bit:
- bpfeb-unknown-none
- bpfel-unknown-none
- sparcv9-sun-solaris
- now matches endian-big:
- m68k-unknown-linux-gnu
- now matches 16bit:
- msp430-none-elf
- now matches 32bit:
- arm64_32-apple-watchos
- now matches riscv32 (and needs-asm-support):
- riscv32gc-unknown-linux-gnu
- riscv32gc-unknown-linux-musl
- riscv32i-unknown-none-elf
- riscv32im-unknown-none-elf
- riscv32imac-unknown-none-elf
- riscv32imac-unknown-xous-elf
- riscv32imc-esp-espidf
- riscv32imc-unknown-none-elf
- riscv64imac-unknown-none-elf
Implement `#[rustc_default_body_unstable]`
This PR implements a new stability attribute — `#[rustc_default_body_unstable]`.
`#[rustc_default_body_unstable]` controls the stability of default bodies in traits.
For example:
```rust
pub trait Trait {
#[rustc_default_body_unstable(feature = "feat", isssue = "none")]
fn item() {}
}
```
In order to implement `Trait` user needs to either
- implement `item` (even though it has a default implementation)
- enable `#![feature(feat)]`
This is useful in conjunction with [`#[rustc_must_implement_one_of]`](https://github.com/rust-lang/rust/pull/92164), we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way — making implementation of only `PartialEq::ne` unstable.
r? `@Aaron1011`
cc `@nrc` (iirc you were interested in this wrt `read_buf`), `@danielhenrymantilla` (you were interested in the related `#[rustc_must_implement_one_of]`)
P.S. This is my first time working with stability attributes, so I'm not sure if I did everything right 😅
Rollup of 5 pull requests
Successful merges:
- #100071 (deps: dedupe `annotate-snippets` crate versions)
- #100127 (Remove Windows function preloading)
- #100130 (Avoid pointing out `return` span if it has nothing to do with type error)
- #100169 (Optimize `pointer::as_aligned_to`)
- #100175 (ascii -> ASCII in code comment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Bump cc version in bootstrap
Among other changes, the newer cc release pulls in this fix:
b2792e33ff
This fixes errors when building compiler_builtins for UEFI targets.
Rollup of 6 pull requests
Successful merges:
- #99933 (parallelize HTML checking tool)
- #99958 (Improve position named arguments lint underline and formatting names)
- #100008 (Update all pre-cloned submodules on startup)
- #100049 (⬆️ rust-analyzer)
- #100070 (Clarify Cargo.toml comments)
- #100074 (rustc-docs: Be less specific about the representation of `+bundle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
parallelize HTML checking tool
there's a lot of IO, so timings on my laptop are far from stable, but it seems to be considerably faster.
this step often appears to take 5+ minutes in CI, so hopefully this offers a speedup
This is done by having the crossbeam dependency inserted into the
proc_macro server code from the server side, to avoid adding a
dependency to proc_macro.
In addition, this introduces a -Z command-line option which will switch
rustc to run proc-macros using this cross-thread executor. With the
changes to the bridge in #98186, #98187, #98188 and #98189, the
performance of the executor should be much closer to same-thread
execution.
In local testing, the crossbeam executor was substantially more
performant than either of the two existing CrossThread strategies, so
they have been removed to keep things simple.
This initial implementation handles transmutations between types with specified layouts, except when references are involved.
Co-authored-by: Igor null <m1el.2027@gmail.com>
Upgrade indexmap and thorin-dwp to use hashbrown 0.12
This removes the last dependencies on hashbrown 0.11.
This also upgrades to hashbrown 0.12.3 to fix a double-free (#99372).
Add fine-grained LLVM CFI support to the Rust compiler
This PR improves the LLVM Control Flow Integrity (CFI) support in the Rust compiler by providing forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types.
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue https://github.com/rust-lang/rust/issues/89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
Thank you again, `@eddyb,` `@nagisa,` `@pcc,` and `@tmiasko` for all the help!
This commit improves the LLVM Control Flow Integrity (CFI) support in
the Rust compiler by providing forward-edge control flow protection for
Rust-compiled code only by aggregating function pointers in groups
identified by their return and parameter types.
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).
LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e.,
-Clto).
Use constant eval to do strict mem::uninit/zeroed validity checks
I'm not sure about the code organisation here, I just dumped the check in rustc_const_eval at the root. Not hard to move it elsewhere, in any case.
Also, this means cranelift codegen intrinsics lose the strict checks, since they don't seem to depend on rustc_const_eval, and I didn't see a point in keeping around two copies.
I also left comments in the is_zero_valid methods about "uhhh help how do i do this", those apply to both methods equally.
Also rustc_codegen_ssa now depends on rustc_const_eval... is this okay?
Pinging `@RalfJung` since you were the one who mentioned this to me, so I'm assuming you're interested.
Haven't had a chance to run full tests on this since it's really warm, and it's 1AM, I'll check out any failures/comments in the morning :)
Stop keeping metadata in memory before writing it to disk
Fixes#96358
I created this PR according with the instruction given in the issue except for the following points:
- While the issue says "Write metadata into the temporary file in `encode_and_write_metadata` even if `!need_metadata_file`", I could not do that. That is because though I tried to do that and run `x.py test`, I got a lot of test failures as follows.
<details>
<summary>List of failed tests</summary>
<pre>
<code>
failures:
[ui] src/test/ui/json-multiple.rs
[ui] src/test/ui/json-options.rs
[ui] src/test/ui/rmeta/rmeta-rpass.rs
[ui] src/test/ui/save-analysis/emit-notifications.rs
[ui] src/test/ui/svh/changing-crates.rs
[ui] src/test/ui/svh/svh-change-lit.rs
[ui] src/test/ui/svh/svh-change-significant-cfg.rs
[ui] src/test/ui/svh/svh-change-trait-bound.rs
[ui] src/test/ui/svh/svh-change-type-arg.rs
[ui] src/test/ui/svh/svh-change-type-ret.rs
[ui] src/test/ui/svh/svh-change-type-static.rs
[ui] src/test/ui/svh/svh-use-trait.rs
test result: FAILED. 12915 passed; 12 failed; 100 ignored; 0 measured; 0 filtered out; finished in 71.41s
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
Build completed unsuccessfully in 0:01:58
</code>
</pre>
</details>
- I could not resolve the extra tasks about `create_rmeta_file` and `create_compressed_metadata_file` for my lack of ability.
macros: `LintDiagnostic` derive
- Move `LintDiagnosticBuilder` into `rustc_errors` so that a diagnostic derive can refer to it.
- Introduce a `DecorateLint` trait, which is equivalent to `SessionDiagnostic` or `AddToDiagnostic` but for lints. Necessary without making more changes to the lint infrastructure as `DecorateLint` takes a `LintDiagnosticBuilder` and re-uses all of the existing logic for determining what type of diagnostic a lint should be emitted as (e.g. error/warning).
- Various refactorings of the diagnostic derive machinery (extracting `build_field_mapping` helper and moving `sess` field out of the `DiagnosticDeriveBuilder`).
- Introduce a `LintDiagnostic` derive macro that works almost exactly like the `SessionDiagnostic` derive macro except that it derives a `DecorateLint` implementation instead. A new derive is necessary for this because `SessionDiagnostic` is intended for when the generated code creates the diagnostic. `AddToDiagnostic` could have been used but it would have required more changes to the lint machinery.
~~At time of opening this pull request, ignore all of the commits from #98624, it's just the last few commits that are new.~~
r? `@oli-obk`
`SessionDiagnostic` isn't suitable for use on lints as whether or not it
creates an error or a warning is decided at compile-time by the macro,
whereas lints decide this at runtime based on the location of the lint
being reported (as it will depend on the user's `allow`/`deny`
attributes, etc). Re-using most of the machinery for
`SessionDiagnostic`, this macro introduces a `LintDiagnostic` derive
which implements a `DecorateLint` trait, taking a
`LintDiagnosticBuilder` and adding to the lint according to the
diagnostic struct.
Bump RLS to latest master on rust-lang/rls
Of primary interest, this merges
rust-lang/rls@ece09b88c0 into rust-lang/rust,
which brings in the changes that fix RLS tests broken by #97853. #97853 already
introduced that commit's changes (under
rust-lang/rls@27f4044df0) but without putting those changes on
rust-lang/rls as a branch, so we ended up with an orphan commit that caused
trouble when updating submodules in rust-lang/rust.
This commit, once merged into rust-lang/rust, should continue to let RLS tests
to pass on rust-lang/rust's side and move us back into a healthy state where tip
of the submodule points to a valid master commit in the rust-lang/rls
repository.
cc https://github.com/rust-lang/rust/issues/98451, but not marking as fixed as I believe we need to add verification to prevent future oversights.
Fully remove submodule handling from bootstrap.py
These submodules were previously updated in python because Cargo gives a hard error if toml files
are missing from the workspace:
```
error: failed to load manifest for workspace member `/home/jnelson/rust-lang/rust/src/tools/rls`
Caused by:
failed to read `/home/jnelson/rust-lang/rust/src/tools/rls/Cargo.toml`
Caused by:
No such file or directory (os error 2)
failed to run: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/jnelson/rust-lang/rust/src/bootstrap/Cargo.toml
```
However, bootstrap doesn't actually need to be part of the workspace.
Remove it so we can move submodule handling fully to Rust, avoiding duplicate code between Rust and Python.
Note that this does break `cargo run`; it has to be `cd src/bootstrap && cargo run` now.
Given that we're planning to make the main entrypoint a shell script (or rust binary),
I think this is a good tradeoff for reduced complexity in bootstrap.py.
To get this working, I also had to remove support for vendoring when using the git sources, because `cargo vendor` requires all submodules to be checked out. I think this is ok; people who care about this are likely already using the pre-vendored `rustc-src` tarball.
Fixes https://github.com/rust-lang/rust/issues/90764. Helps with #94829
Of primary interest, this merges
rust-lang/rls@ece09b88c0 into rust-lang/rust,
which brings in the changes that fix RLS tests broken by #97853. #97853 already
introduced that commit's changes (under
27f4044df03d15c7c38a483c3e4635cf4f51807d) but without putting those changes on
rust-lang/rls as a branch, so we ended up with an orphan commit that caused
trouble when updating submodules in rust-lang/rust.
This commit, once merged into rust-lang/rust, should continue to let RLS tests
to pass on rust-lang/rust's side and move us back into a healthy state where tip
of the submodule points to a valid master commit in the rust-lang/rls
repository.
Migrate two diagnostics from the `rustc_builtin_macros` crate
Migrate two diagnostics to use the struct derive and be translatable.
r? ```@davidtwco```
These submodules were previously updated in python because Cargo gives a hard error if toml files
are missing from the workspace:
```
error: failed to load manifest for workspace member `/home/jnelson/rust-lang/rust/src/tools/rls`
Caused by:
failed to read `/home/jnelson/rust-lang/rust/src/tools/rls/Cargo.toml`
Caused by:
No such file or directory (os error 2)
failed to run: /home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/jnelson/rust-lang/rust/src/bootstrap/Cargo.toml
```
However, bootstrap doesn't actually need to be part of the workspace.
Remove it so we can move submodule handling fully to Rust, avoiding duplicate code between Rust and Python.
Note that this does break `cargo run`; it has to be `cd src/bootstrap && cargo run` now.
Given that we're planning to make the main entrypoint a shell script (or rust binary),
I think this is a good tradeoff for reduced complexity in bootstrap.py.
Make "Assemble stage1 compiler" orders of magnitude faster (take 2)
This used to take upwards of 5 seconds for me locally. I found that the culprit was copying the downloaded LLVM shared object:
```
[22:28:03] Install "/home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/ci-llvm/lib/libLLVM-14-rust-1.62.0-nightly.so" to "/home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libLLVM-14-rust-1.62.0-nightly.so"
[22:28:09] c Sysroot { compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) } }
```
It turned out that `install()` used full copies unconditionally. Change it to try using a hard-link before falling back to copying.
- Panic if we generate a symbolic link in a tarball
- Change install to use copy internally, like in my previous PR
- Change copy to dereference symbolic links, which avoids the previous regression in #96803.
I also took the liberty of fixing `x dist llvm-tools` to work even if you don't call `x build` previously.
add comments in `store_dead_field_or_variant`
support multiple log level
add a item ident label
fix ui tests
fix a ui test
fix a rustdoc ui test
use let chain
refactor: remove `store_dead_field_or_variant`
fix a tiny bug
4 commits in 4d92f07f34ba7fb7d7f207564942508f46c225d3..8d42b0e8794ce3787c9f7d6d88b02ae80ebe8d19
2022-06-10 01:11:04 +0000 to 2022-06-17 16:46:26 +0000
- Use specific terminology for sparse HTTP-based registry (rust-lang/cargo#10764)
- chore: Upgrade to clap 3.2 (rust-lang/cargo#10753)
- Improve testing framework for http registries (rust-lang/cargo#10738)
- doc: Improve example of using the links field (rust-lang/cargo#10728)
This adds the typeid and `vcall_visibility` metadata to vtables when the
-Cvirtual-function-elimination flag is set.
The typeid is generated in the same way as for the
`llvm.type.checked.load` intrinsic from the trait_ref.
The offset that is added to the typeid is always 0. This is because LLVM
assumes that vtables are constructed according to the definition in the
Itanium ABI. This includes an "address point" of the vtable. In C++ this
is the offset in the vtable where information for RTTI is placed. Since
there is no RTTI information in Rust's vtables, this "address point" is
always 0. This "address point" in combination with the offset passed to
the `llvm.type.checked.load` intrinsic determines the final function
that should be loaded from the vtable in the
`WholeProgramDevirtualization` pass in LLVM. That's why the
`llvm.type.checked.load` intrinsics are generated with the typeid of the
trait, rather than with that of the function that is called. This
matches what `clang` does for C++.
The vcall_visibility metadata depends on three factors:
1. LTO level: Currently this is always fat LTO, because LLVM only
supports this optimization with fat LTO.
2. Visibility of the trait: If the trait is publicly visible, VFE
can only act on its vtables after linking.
3. Number of CGUs: if there is more than one CGU, also vtables with
restricted visibility could be seen outside of the CGU, so VFE can
only act on them after linking.
To reflect this, there are three visibility levels: Public, LinkageUnit,
and TranslationUnit.
Update minifier version to 0.2.1
This change and these changes come from an idea of `@camelid:` instead of creating a string, we just `write` the type into the file directly.
I don't think it'll have a big impact on perf but it's still a potential small improvement.
r? `@notriddle`
Update cargo
7 commits in 38472bc19f2f76e245eba54a6e97ee6821b3c1db..85e457e158db216a2938d51bc3b617a5a7fe6015
2022-05-31 02:03:24 +0000 to 2022-06-07 21:57:52 +0000
- Make -Z http-registry use index.crates.io when accessing crates-io (rust-lang/cargo#10725)
- Respect submodule update=none strategy in .gitmodules (rust-lang/cargo#10717)
- Expose rust-version through env var (rust-lang/cargo#10713)
- add validation for string "true"/"false" in lto profile (rust-lang/cargo#10676)
- Enhance documentation of testing (rust-lang/cargo#10726)
- Clear disk space on CI. (rust-lang/cargo#10724)
- Enforce to use tar v0.4.38 (rust-lang/cargo#10720)
