const_trait in conjunction with specialization was
deemed not ready for usage in this scenario. So
instead a two-stage trait specialization approach
is used. This approach is likely worse for
compile-times. Future work that enables
const_trait can revert back to the previous
version as outlined in the comment marked
FIXME(effects).
rustc_span: Minor improvements
Introduce `{IndexNewtype,SyntaxContext}::from_u16` for convenience because small indices are sometimes encoded as `u16`.
Use `SpanData::span` instead of `Span::new` where appropriate.
Add a clarifying comment about decoding span parents.
Introduce `{IndexNewtype,SyntaxContext}::from_u16` for convenience because small indices are sometimes encoded as `u16`.
Use `SpanData::span` instead of `Span::new` where appropriate.
Add a clarifying comment about decoding span parents.
Update `Arc::try_unwrap()` docs
Clarify the language wrt "race condition" not meaning "memory unsafety".
The docs make an important point about a 'logical' race condition that can occur if the `Err`-case in `Arc::try_unwrap()` is not handled properly. The language as is uses the term "race condition", which the reader may associate with "memory unsafety". This PR tries to clarify the scenario and qualify "race condition without memory unsafety".
unify git command preperation
Due to https://github.com/rust-lang/rust/issues/125954, we had to modify git invocations with certain flags in https://github.com/rust-lang/rust/pull/126255. However, because there are so many instances of `Command::new("git")` in bootstrap, it is difficult to apply these solutions to all of them.
This PR creates a helper function that unifies the git usage in bootstrap. Meaning, whenever special flags or hacks are needed, we can apply them to this single function which makes things much simpler for the bootstrap team.
Spell out other trait diagnostic
I recently saw somebody confused about the diagnostic thinking it was suggesting to add an `as` cast. This change is longer but I think it's clearer
Document behavior of `create_dir_all` wrt. empty path
The behavior makes sense because `Path::new("one_component").parent() == Some(Path::new(""))`, so if one naively wants to create the parent directory for a file to be written, it simply works.
Closes#105108 by documenting the current behavior.
These tests might have originally been useful as an implementation aid, but now
they don't provide enough value to justify the burden of updating them as the
underlying code changes.
The code they test is still exercised by the main end-to-end coverage tests.
Only compute vtable information during codegen
This PR removes vtable information from the `Object` and `TraitUpcasting` candidate sources in the trait solvers, and defers the computation of relevant information to `Instance::resolve`. This is because vtables really aren't a thing in the trait world -- they're an implementation detail in codegen.
Previously it was just easiest to tangle this information together since we were already doing the work of looking at all the supertraits in the trait solver, and specifically because we use traits to represent when it's possible to call a method via a vtable (`Object` candidate) and do upcasting (`Unsize` candidate). but I am somewhat suspicious we're doing a *lot* of extra work, especially in polymorphic contexts, so let's see what perf says.
Remove superfluous UbChecks from `SliceIndex` methods
The current implementation calls the unsafe ones from the safe ones, but that means they end up emitting UbChecks that are impossible to hit, since we just checked those things.
This PR adds some new module-local helpers for the code shared between them, so the safe methods can be small enough to inline by avoiding those extra checks, while the unsafe methods still help catch length mistakes.
r? `@saethlin`
Disable `llvm-bitcode-linker` in the default bootstrap profiles
I don't think that we really need to enable `llvm-bitcode-linker` in the default bootstrap profiles, since it seems that it is only useful for running `nvptx` tests. It should be enabled on CI, which it is, and that should be enough. People can enable it easily locally, if they want.
The linker causes occasionally some rebuild issues (https://github.com/rust-lang/rust/issues/122491, https://github.com/rust-lang/rust/issues/126464), but more importantly it is just needless work to build it locally.
I kept it enabled for `dist`, because it is distributed as a `rustup` component (for some reason it's not included in `extended`? not sure).
Fixes: https://github.com/rust-lang/rust/issues/126464
ci: Update centos:7 to use vault repos
CentOS 7 is going EOL on June 30, after which its package repos will no
longer exist on the regular mirrors. We'll still be able to access
packages from the vault server though, and can start doing so now. This
affects `dist-i686-linux` and `dist-x86_64-linux`.
I also removed `epel-release` because we were only using that for its
`cmake3`, but we've been building our own version for a while.
try-job: dist-i686-linux
try-job: dist-x86_64-linux
