Move layout_of and friends from rustc_middle to rustc_ty_utils
Breaks up the very large module that is `rustc_middle::ty::layout` by fork-lifting some queries into `rustc_ty_utils::{abi, layout}`.
This does set back `rustc_ty_utils` to having untranslatable diagnostics. I'd like to leave this as a separate task.
re-add git-commit-hash file to tarballs
rust-lang/rust#100557 removed the `git-commit-hash` file and replaced it with `git-commit-info`. However, build-manifest relies on the `git-commit-hash` file being present, so this adds it back.
r? `@Mark-Simulacrum`
Fix duplicate usage of `a` article.
This fixes a typo first appearing in #94624 in which test-macro diagnostic uses "a" article twice.
Since I searched the sources for " a a " sequences, I also fixed the same issue in a few files where I found it.
Get rid of exclude-list for Windows-only tests
Main purpose of this change is to get rid of a quite long (and growing) list of excluded targets, while this test should only be useful on Windows (as far as I understand it). The `// only-windows` header seams to implement exactly what we need here.
I don't know why there are some whitespace changes, but `x.py fmt` and `.git/hooks/pre-push` are happy.
fix: use git-commit-info for version information
Fixes#33286.
Fixes#86587.
This PR changes the current `git-commit-hash` file that `./x.py` dist puts in the `rustc-{version}-src.tar.{x,g}z` to contain the hash, the short hash, and the commit date from which the tarball was created, assuming git was available when it was. It uses this for reading the version so that rustc has all the appropriate metadata.
# Testing
Testing this is kind of a pain. I did it with something like
```sh
./x.py dist # ensure that `ignore-git` is `false` in config.toml
cp ./build/dist/rustc-1.65.0-dev-src.tar.gz ../rustc-1.65.0-dev-src.tar.gz
cd .. && tar -xzf rustc-1.65.0-dev-src && cd rustc-1.65.0-dev-src
./x.py build
```
Then, the output of `rustc -vV` with the stage1 compiler should have the `commit-hash` and `commit-date` fields filled, rather than be `unknown`. To be completely sure, you can use `rustc --sysroot` with the stdlib that the original `./x.py dist` made, which will require that the metadata matches.
This fixes a typo first appearing in #94624
in which test-macro diagnostic uses "a" article twice.
Since I searched sources for " a a " sequences,
I also fixed the same issue in a few source files where I found it.
Signed-off-by: Petr Portnov <gh@progrm-jarvis.ru>
Change argument handling in `remote-test-server` and add new flags
This PR updates `remote-test-server` to add two new flags:
* `--sequential` disables parallel test execution, accepting one connection at the time instead. We need this for Ferrocene as one of our emulators occasionally deadlocks when running multiple tests in parallel.
* `--bind <ip:port>` allows customizing the IP and port `remote-test-server` binds to, rather than using the default value.
While I was changing the flags, and [after chatting on what to do on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/remote-test-server.20flags), I took this opportunity to cleanup argument handling in `remote-test-server`, which is a breaking change:
* The `verbose` argument has been renamed to the `--verbose` flag.
* The `remote` argument has been removed in favor of the `--bind 0.0.0.0:12345` flag. The only thing the argument did was to change the bound IP to 0.0.0.0, which can easily be replicated with `--bind` and also is not secure as our "remote" default.
I'm also open to keep the old arguments with deprecation warnings.
r? `@Mark-Simulacrum`
remove outdated coherence hack
we have a more precise detection for downstream conflicts in candidate assembly: the `is_knowable` check in `candidate_from_obligation_no_cache`.
r? types cc `@nikomatsakis`
Fix perf regression from TypeVisitor changes
Regression occurred in https://github.com/rust-lang/rust/pull/101858#issuecomment-1248732579
Instead of just reverting, we only fixed part of the regression. The main regression was due to actually correctly visiting a type that contains types and consts and should therefor be visited. This is not actually observable (yet?), but we should still do it correctly instead of risking major bugs in the future.
Enable inline stack probes on PowerPC and SystemZ
The LLVM PowerPC and SystemZ targets have both supported `"probe-stack"="inline-asm"` for longer than our current minimum LLVM 13 requirement, so we can turn this on for all `powerpc`, `powerpc64`, `powerpc64le`, and `s390x` targets in Rust. These are all tier-2 or lower, so CI does not run their tests, but I have confirmed that their `linux-gnu` variants do pass on RHEL.
cc #43241
Make the `c` feature for `compiler-builtins` an explicit opt-in
Its build script doesn't support cross-compilation. I tried fixing it, but the cc crate itself doesn't appear to support cross-compiling to windows either unless you use the -gnu toolchain:
```
error occurred: Failed to find tool. Is `lib.exe` installed?
```
Fixes https://github.com/rust-lang/rust/issues/101172.
Rewrite and refactor format_args!() builtin macro.
This is a near complete rewrite of `compiler/rustc_builtin_macros/src/format.rs`.
This gets rid of the massive unmaintanable [`Context` struct](76531befc4/compiler/rustc_builtin_macros/src/format.rs (L176-L263)), and splits the macro expansion into three parts:
1. First, `parse_args` will parse the `(literal, arg, arg, name=arg, name=arg)` syntax, but doesn't parse the template (the literal) itself.
2. Second, `make_format_args` will parse the template, the format options, resolve argument references, produce diagnostics, and turn the whole thing into a `FormatArgs` structure.
3. Finally, `expand_parsed_format_args` will turn that `FormatArgs` structure into the expression that the macro expands to.
In other words, the `format_args` builtin macro used to be a hard-to-maintain 'single pass compiler', which I've split into a three phase compiler with a parser/tokenizer (step 1), semantic analysis (step 2), and backend (step 3). (It's compilers all the way down. ^^)
This can serve as a great starting point for https://github.com/rust-lang/rust/issues/99012, which will only need to change the implementation of 3, while leaving step 1 and 2 unchanged.
It also makes https://github.com/rust-lang/compiler-team/issues/541 easier, which could then upgrade the new `FormatArgs` struct to an `ast` node and remove step 3, moving that step to later in the compilation process.
It also fixes a few diagnostics bugs.
This also [significantly reduces](https://gist.github.com/m-ou-se/b67b2d54172c4837a5ab1b26fa3e5284) the amount of generated code for cases with arguments in non-default order without formatting options, like `"{1} {0}"` or `"{a} {}"`, etc.
Don't drop parent substs when we have no generic parameters in `create_substs_for_ast_path`
This bug is being shadowed by an explicit check for `generics.params.is_empty()` in the only parent caller that could trigger it (`create_substs_for_associated_item`). I triggered it on another branch where I'm messing around with astconv stuff.
Also, the second commit simplifies `create_substs_for_associated_item`. Removing that explicit check I mentioned above^ and also the special case call to `Astconv::prohibit_generics` causes the UI test `src/test/ui/structs/struct-path-associated-type.stderr` to change, but I think that it's clearer now. The suggestion to remove the generics is actually useful.
Make ZST checks in core/alloc more readable
There's a bunch of these checks because of special handing for ZSTs in various unsafe implementations of stuff.
This lets them be `T::IS_ZST` instead of `mem::size_of::<T>() == 0` every time, making them both more readable and more terse.
*Not* proposed for stabilization. Would be `pub(crate)` except `alloc` wants to use it too.
(And while it doesn't matter now, if we ever get something like #85836 making it a const can help codegen be simpler.)
Distribute bootstrap in CI
This pre-compiles bootstrap from source and adds it to the existing `rust-dev` component. There are two main goals here:
1. Make it faster to build rust from source, both the first time and incrementally
2. Make it easier to add non-python entrypoints, since they can call out to bootstrap directly rather than having to figure out the right flags to pre-compile it. This second part is still in a bit of flux, see the tracking issue below for more information.
There are also several changes to make bootstrap able to run on a machine other than the one it was built (particularly around `config.src` and `config.out` detection). I (`@jyn514)` am slightly concerned these will regress unless tested - maybe we should add an automated test that runs bootstrap in a chroot or something? Unclear whether the effort is worth the test coverage.
Helps with https://github.com/rust-lang/rust/issues/94829.
Use internal iteration in `Iterator` comparison methods
Updates the `Iterator` methods `cmp_by`, `partial_cmp_by`, and `eq_by` to use internal iteration on `self`. I've also extracted their shared logic into a private helper function `iter_compare`, which will either short-circuit once the comparison result is known or return the comparison of the lengths of the iterators.
This change also indirectly benefits calls to `cmp`, `partial_cmp`, `eq`, `lt`, `le`, `gt`, and `ge`.
Unsurprising benchmark results: iterators that benefit from internal iteration (like `Chain`) see a speedup, while other iterators are unaffected.
```
name before ns/iter after ns/iter diff ns/iter diff % speedup
iter::bench_chain_partial_cmp 208,301 54,978 -153,323 -73.61% x 3.79
iter::bench_partial_cmp 55,527 55,702 175 0.32% x 1.00
iter::bench_lt 55,502 55,322 -180 -0.32% x 1.00
```
Inline SyntaxContext in both encoded span representation.
The current interned representation for spans does not use the `ctxt_or_zero: u16` field. This PR proposes to use this field to store the `SyntaxContext` of the interned span instead. When `ctxt_or_zero` and the interned span's `ctxt` don't match, the inlined one takes precedence.
This allows to implement `Span::ctxt` and `Span::with_ctxt` with much less probability to access the interner. Those functions are used a lot for hygiene, so this may be worth it.
use partition_point instead of binary_search when looking up source lines
In local benchmarks this results in 0.4% fewer cycles in a critical sequential section when compiling libcore.
Add armv5te-none-eabi and thumbv5te-none-eabi targets
Creates two new Tier 3 targets, `armv5te-none-eabi` and `thumbv5te-none-eabi`. They are for the same target architecture (armv5te), but one defaults to the A32 instruction set and the other defaults to T32. Based on the existing `armv4t-none-eabi` and `thumbv4t-none-eabi` targets.
My particular use case for these targets is Nintendo DS homebrew, but they should be usable for any armv5te system.
Going through the Tier 3 target policy:
> A 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.)
That will be me.
> Targets must use naming consistent with any existing targets.
Naming is consistent with previous targets.
>> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility.
No 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.
Doesn't create any legal issues.
>> The target must not introduce license incompatibilities.
This doesn't introduce any new licenses.
>> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Yep.
>> 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.
No new license requirements.
>> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries.
Everything this uses is FOSS, no proprietary required.
> 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.
OK.
>> 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.
OK.
> 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.
This is a bare-metal target with only support for `core` (and `alloc`, if the user provides an allocator).
> 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 binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Documentation has been added.
> 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.
OK.
> 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.
OK.
> 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.
This doesn't break any other targets.
>> 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 unnecessary unconditional features here.
a fn pointer doesn't implement `Fn`/`FnMut`/`FnOnce` if its return type isn't sized
I stumbled upon #83915 which hasn't received much attention recently, and I wanted to revive it since this is one existing soundness hole that seems pretty easy to fix.
I'm not actually sure that the [alternative approach described here](https://github.com/rust-lang/rust/pull/83915#issuecomment-823643322) is sufficient, given the `src/test/ui/function-pointer/unsized-ret.rs` example I provided below. Rebasing the branch mentioned in that comment and testing that UI test, it seems that we actually end up only observing that `str: !Sized` during monomorphization, whereupon we ICE. Even if we were to fix that ICE, ideally we'd be raising an error that a fn pointer is being used badly during _typecheck_ instead of monomorphization, hence adapting the original approach in #83915.
I am happy to close this if people would prefer we rebase the original PR and land that -- I am partly opening to be annoying and get people thinking about this unsoundness again ❤️😸
cc: `@estebank` and `@nikomatsakis`
r? types
Here's a link to the thread: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/PR.20.2383915/near/235421351 for more context.
Optimize `array::IntoIter`
`.into_iter()` on arrays was slower than it needed to be (especially compared to slice iterator) since it uses `Range<usize>`, which needs to handle degenerate ranges like `10..4`.
This PR adds an internal `IndexRange` type that's like `Range<usize>` but with a safety invariant that means it doesn't need to worry about those cases -- it only handles `start <= end` -- and thus can give LLVM more information to optimize better.
I added one simple demonstration of the improvement as a codegen test.
(`vec::IntoIter` uses pointers instead of indexes, so doesn't have this problem, but that only works because its elements are boxed. `array::IntoIter` can't use pointers because that would keep it from being movable.)
std: use `sync::RwLock` for internal statics
Since `sync::RwLock` is now `const`-constructible, it can be used for internal statics, removing the need for `sys_common::StaticRwLock`. This adds some extra allocations on platforms which need to box their locks (currently SGX and some UNIX), but these will become unnecessary with the lock improvements tracked in #93740.
Improve error for when query is unsupported by crate
This is an improvement to the error message mentioned on #101666. It seems like a good idea to also add [this link to the rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/query.html), if explaining the query system in detail is a concern here, but I'm unsure if there is any restrictions on adding links to error messages.
Distribute json doc
# Overview
We add a new component, `rust-json-docs`, to distribute the JSON version of rustdoc's output for public compiler crates (i.e. `std`, `alloc`, `proc_macro`, `core` and `test`).
As discussed in #101383, we do not bundle this up as part of the existing `rust-docs` component since `rustdoc`'s JSON format is still unstable.
# Open questions / Doubts
I tried my best, but I never touched this codebase and I couldn't find much documentation on how `dist` works - I pattern-matched existing code, which might have led to some non-sensical choices in the eyes of people more familiar with the codebase. In particular, I am not sure if my choice of adding a new config flag is appropriate or if the decision to build/not build the JSON docs is more appropriately gated by one of the existing flags.
Any suggestion is more than welcome.
Closes#101383
Add a new configuration settings to set env vars when running cargo, rustc, etc. commands: cargo.extraEnv and checkOnSave.extraEnv
It can be extremely useful to be able to set environment variables when rust-analyzer is running various cargo or rustc commands (such as `cargo check`, `cargo --print cfg` or `cargo metadata`): users may want to set custom `RUSTFLAGS`, change `PATH` to use a custom toolchain or set a different `CARGO_HOME`.
There is the existing `server.extraEnv` setting that allows env vars to be set when the rust-analyzer server is launched, but using this as the recommended mechanism to also configure cargo/rust has some drawbacks:
- It convolutes configuring the rust-analyzer server with configuring cargo/rustc (one may want to change the `PATH` for cargo/rustc without affecting the rust-analyzer server).
- The name `server.extraEnv` doesn't indicate that cargo/rustc will be affected but renaming it to `cargo.extraEnv` doesn't indicate that the rust-analyzer server would be affected.
- To make the setting useful, it needs to be dynamically reloaded without requiring that the entire extension is reloaded. It might be possible to do this, but it would require the client communicating to the server what the overwritten env vars were at first launch, which isn't easy to do.
This change adds two new configuration settings: `cargo.extraEnv` and `checkOnSave.extraEnv` that can be used to change the environment for the rust-analyzer server after launch (thus affecting any process that rust-analyzer invokes) and the `cargo check` command respectively. `cargo.extraEnv` supports dynamic changes by keeping track of the pre-change values of environment variables, thus it can undo changes made previously before applying the new configuration (and then requesting a workspace reload).
Fix add reference action on macros.
Before we were using the range of the corresponding expression node in the macro expanded file, which is obviously incorrect as we are setting the text in the original source.
For some reason, the test I added is failing and I haven't found a way to fix it. Does anyone know why `check_fix` wouldn't work with macros? Getting this error:
```text
thread 'handlers::type_mismatch::tests::test_add_reference_to_macro_call' panicked at 'no diagnostics', crates/ide-diagnostics/src/handlers/type_mismatch.rs:317:9
```
closes#13219
