Allow multiple derefs to be splitted in deref_separator
Previously in #95649 only a single deref within projection was supported and multiple derefs caused a bunch of issues, this PR fixes those issues.
```@oli-obk``` helped a ton again ❤️
Check for git submodules in non-git source tree.
People occasionally download the source from https://github.com/rust-lang/rust/releases, but those source distributions will not work because they are missing the submodules. They will get a confusing `failed to load manifest for workspace member` error.
Unfortunately AFAIK there is no way to disable the GitHub source links. This change tries to detect this scenario and provide an error message that guides them toward a solution.
Closes#95608
Suggest replacing `typeof(...)` with an actual type
This PR adds suggestion to replace `typeof(...)` with an actual type of `...`, for example in case of `typeof(1)` we suggest replacing it with `i32`.
If the expression
1. Is not const (`{ let a = 1; let _: typeof(a); }`)
2. Can't be found (`let _: typeof(this_variable_does_not_exist)`)
3. Or has non-suggestable type (closure, generator, error, etc)
we don't suggest anything.
The 1 one is sad, but it's not clear how to support non-consts expressions for `typeof`.
_This PR is inspired by [this tweet]._
[this tweet]: https://twitter.com/compiler_errors/status/1511945354752638976
Avoid duplication of doc comments in `std::char` constants and functions
For those consts and functions, only the summary is kept and a reference to the `char` associated const/method is included.
Additionaly, re-exported functions have been converted to function definitions that call the previously re-exported function. This makes it easier to add a deprecated attribute to these functions in the future.
Avoid accessing HIR from MIR passes
`hir_owner_nodes` contains a lot of information, and the query result is typically dirty. This forces dependent queries to be re-executed needlessly.
This PR refactors some accesses to HIR to go through more targeted queries that yield the same result.
Based on https://github.com/rust-lang/rust/pull/95435 and https://github.com/rust-lang/rust/pull/95436
Make it possible to run `cargo test` for bootstrap
Note that this only runs bootstrap's self-tests, not compiler or library tests.
Helps with https://github.com/rust-lang/rust/issues/94829.
Remove ptr-int transmute in std::sync::mpsc
Since https://github.com/rust-lang/rust/pull/95340 landed, Miri with `-Zmiri-check-number-validity` produces an error on the test suites of some crates which implement concurrency tools<sup>*</sup>, because it seems like such crates tend to use `std::sync::mpsc` in their tests. This fixes the problem by storing pointer bytes in a pointer.
<sup>*</sup> I have so far seen errors in the test suites of `once_cell`, `parking_lot`, and `crossbeam-utils`.
(just updating the list for fun, idk)
Also `threadpool`, `async-lock`, `futures-timer`, `fragile`, `scoped_threadpool`, `procfs`, `slog-async`, `scheduled-thread-pool`, `tokio-threadpool`, `mac`, `futures-cpupool`, `ntest`, `actix`, `zbus`, `jsonrpc-client-transports`, `fail`, `libp2p-gossipsub`, `parity-send-wrapper`, `async-broadcast,` `libp2p-relay`, `http-client`, `mockito`, `simple-mutex`, `surf`, `pollster`, and `pulse`. Then I turned the bot off.
Running `./x.py build -h -v` shows a list of available build targets,
but the short alias `./x.py b -h -v` does not. Fix so that the aliases
behave the same as their spelled out counterparts.
Fix `cargo run` on Windows
Fixes the following error:
```
error: failed to run custom build command for `bootstrap v0.0.0 (C:\Users\Walther\git\rust\src\bootstrap)`
Caused by:
process didn't exit successfully: `C:\Users\Walther\git\rust\target\debug\build\bootstrap-7757a4777dec0f86\build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=build.rs
cargo:rerun-if-env-changed=RUSTC
cargo:rustc-env=BUILD_TRIPLE=x86_64-pc-windows-msvc
cargo:rerun-if-env-changed=PATH
--- stderr
thread 'main' panicked at 'assertion failed: rustc.is_absolute()', src\bootstrap\build.rs:22:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
```
The problem was that the `dir.join` check only works with `rustc.exe`, not `rustc`.
Thanks `@Walther` for the help testing the fix!
Helps with https://github.com/rust-lang/rust/issues/94829.
Make def names and HIR names consistent.
The name in the `DefKey` is interned to create the `DefId`, so it does not
require any query to access. This can be leveraged to avoid a few useless
HIR accesses for names.
~In order to achieve that, generic parameters created from universal
impl-trait are given the pretty-printed ast as a name, instead of
`{{opaque}}`.~
~Drive-by: the `TyCtxt::opt_item_name` used a dummy span for non-local
definitions. We have access to `def_ident_span`, so we use it.~
We may sometimes emit an `invoke` instead of a `call` for inline
assembly during the MIR -> LLVM IR lowering. But we failed to update
the IR builder's current basic block before writing the results to the
outputs. This would result in invalid IR because the basic block would
end in a `store` instruction, which isn't a valid terminator.
Use bitwise XOR in to_ascii_uppercase
This saves an instruction compared to the previous approach, which
was to unset the fifth bit with bitwise OR.
Comparison of generated assembly on x86: https://godbolt.org/z/GdfvdGs39
This can also affect autovectorization, saving SIMD instructions as well: https://godbolt.org/z/cnPcz75T9
Not sure if `u8::to_ascii_lowercase` should also be changed, since using bitwise OR for that function does not require an extra bitwise negate since the code is setting a bit rather than unsetting a bit. `char::to_ascii_uppercase` already uses XOR, so no change seems to be required there.
expand: Remove `ParseSess::missing_fragment_specifiers`
It was used for deduplicating some errors for legacy code which are mostly deduplicated even without that, but at cost of global mutable state, which is not a good tradeoff.
cc https://github.com/rust-lang/rust/pull/95747#issuecomment-1091619403
r? ``@nnethercote``
Left overs of #95761
These are just nits. Feel free to close this PR if all modifications are not worth merging.
* `#![feature(decl_macro)]` is not needed anymore in `rustc_expand`
* `tuple_impls` does not require `$Tuple:ident`. I guess it is there to enhance readability?
r? ```@petrochenkov```
Fix `x test src/librustdoc` with `download-rustc` enabled
The problem was two-fold:
- Bootstrap was hard-coding that unit tests should always run with stage1, not stage2, and
- It hard-coded the sysroot layout in stage1, which puts libLLVM.so in `lib/rustlib/` instead of just `lib/`.
This also takes the liberty of fixing `test src/librustdoc --no-doc`, which has been broken since it was first added. It would be nice at some point to unify this logic with other tests; I opened a Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Inconsistency.20in.20.60x.20test.60
Fixes https://github.com/rust-lang/rust/issues/91071.
Make non-power-of-two alignments a validity error in `Layout`
Inspired by the zulip conversation about how `Layout` should better enforce `size <= isize::MAX as usize`, this uses an N-variant enum on N-bit platforms to require at the validity level that the existing invariant of "must be a power of two" is upheld.
This was MIRI can catch it, and means there's a more-specific type for `Layout` to store than just `NonZeroUsize`.
It's left as `pub(crate)` here; a future PR could consider giving it a tracking issue for non-internal usage.
Clarify indexing into Strings
**This Commit**
Adds some clarity around indexing into Strings.
**Why?**
I was reading through the `Range` documentation and saw an
implementation for `SliceIndex<str>`. I was surprised to see this and
went to read the [`String`][0] documentation and, to me, it seemed to
say (at least) three things:
1. you cannot index into a `String`
2. indexing into a `String` could not be constant-time
3. indexing into a `String` does not have an obvious return type
I absolutely agree with the last point but the first two seemed
contradictory to the documentation around [`SliceIndex<str>`][1]
which mention:
1. you can do substring slicing (which is probably different than
"indexing" but, because the method is called `index` and I associate
anything with square brackets with "indexing" it was enough to
confuse me)
2. substring slicing is constant-time (this may be algorithmic ignorance
on my part but if `&s[i..i+1]` is O(1) then it seems confusing that
`&s[i]` _could not possibly_ be O(1))
So I was hoping to clarify a couple things and, hopefully, in this PR
review learn a little more about the nuances here that confused me in
the first place.
[0]: https://doc.rust-lang.org/stable/std/string/struct.String.html#utf-8
[1]: https://doc.rust-lang.org/stable/std/slice/trait.SliceIndex.html#impl-SliceIndex%3Cstr%3E
