| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Improve `derive(Debug)`
r? `@ghost`
|
|
update Miri
Fixes https://github.com/rust-lang/rust/issues/98493 (this is a flaky test, that's why the toolstate already says Miri is fixed)
r? `@ghost` Cc `@rust-lang/miri`
|
|
Rollup of 8 pull requests
Successful merges:
- #98371 (Fix printing `impl trait` under binders)
- #98385 (Work around llvm 12's memory ordering restrictions.)
- #98474 (x.py: Support systems with only `python3` not `python`)
- #98488 (Bump RLS to latest master on rust-lang/rls)
- #98491 (Fix backtrace UI test when panic=abort is used)
- #98502 (Fix source sidebar hover in ayu theme)
- #98509 (diagnostics: consider parameter count when suggesting smart pointers)
- #98513 (Fix LLVM rebuild with download-ci-llvm.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix LLVM rebuild with download-ci-llvm.
This fixes an issue where updating a local checkout that includes a change in `src/version` causes a linking failure.
The cause is that the `rustc_llvm` build script uses `rerun-if-changed` of `llvm-config` to know if it needs to rerun. Cargo only compares the timestamp of the last time the build script to the file. However, extracting the tar files retains the timestamps in the tarball which may be some time in the past. Since `src/version` is included in the LLVM `.so` filename, `rustc` attempts to load the wrong shared library since the `rustc_llvm` build script doesn't rerun.
https://github.com/rust-lang/cargo/issues/10791 contains a more detailed explanation.
The solution here is a hack which updates the timestamp of `llvm-config` to the current time when it is extracted.
This is a bit of a hack, but seems to be the best solution I can think of until https://github.com/rust-lang/cargo/issues/10791 is fixed. There are likely several other situations where this is a problem (such as using system LLVM), and this isn't really a complete fix.
Note that apple platforms are not directly affected by this problem because they don't have a version in the dylib filename.
How to test this:
1. On a linux host, enable download-ci-llvm
2. Check out 7036449c774860a5b348dbbe01c20704c557382e (the commit just before the last version bump)
3. `./x.py build library/std`
4. Check out 5f015a24f99f52ea9b67beb420aff24f82acf1af (the commit that bumped the version)
5. `./x.py build library/std`
Fixes #98495
|
|
diagnostics: consider parameter count when suggesting smart pointers
Fixes #96834
|
|
Fix source sidebar hover in ayu theme
In the screenshot below, `rc.rs` should be orange:
It's because the CSS selector was not precise enough and was "overloaded" with another one. This PR fixes it and adds a test for the colors in the source sidebar.
cc `@jsha`
r? `@notriddle`
|
|
Fix backtrace UI test when panic=abort is used
The function `contains_verbose_expected` is only used when the panic strategy is not abort, so it caused a warning when it was abort, which made the UI test failed on stderr comparison.
|
|
Bump RLS to latest master on rust-lang/rls
Of primary interest, this merges
rust-lang/rls@ece09b88c0365947af79c0ffdeea02bc6c1eec25 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@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.
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.
|
|
x.py: Support systems with only `python3` not `python`
Fixes #71818 without the pitfalls so far described in previous attempts.
|
|
Work around llvm 12's memory ordering restrictions.
Older llvm has the pre-C++17 restriction on success and failure memory ordering, requiring the former to be at least as strong as the latter. So, for llvm 12, this upgrades the success ordering to a stronger one if necessary.
See https://github.com/rust-lang/rust/issues/68464
|
|
Fix printing `impl trait` under binders
Before, we would render `impl for<'a> Trait<'a>` like `impl Trait<for<'a> 'a>`, lol.
|
|
|
|
compiletest: strip debuginfo by default for mode=ui
This reduces occupied disk space, for example for src/test/ui it drops from 1972mb to 132mb (x86_64-pc-windows-msvc).
Individual tests that require debuginfo/symbols should turn this option off (as in fixed tests).
|
|
|
|
|
|
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
|
|
|
|
|
|
Sync rustfmt
We had a bug in the update we made ~1 week ago, so running a somewhat early sync to pull the fix in
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #96412 (Windows: Iterative `remove_dir_all`)
- #98126 (Mitigate MMIO stale data vulnerability)
- #98149 (Set relocation_model to Pic on emscripten target)
- #98194 (Leak pthread_{mutex,rwlock}_t if it's dropped while locked.)
- #98298 (Point to type parameter definition when not finding variant, method and associated item)
- #98311 (Reverse folder hierarchy)
- #98401 (Add tracking issues to `--extern` option docs.)
- #98429 (Use correct substs in enum discriminant cast)
- #98431 (Suggest defining variable as mutable on `&mut _` type mismatch in pats)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Of primary interest, this merges
rust-lang/rls@ece09b88c0365947af79c0ffdeea02bc6c1eec25 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.
|
|
Suggest defining variable as mutable on `&mut _` type mismatch in pats
Suggest writing `mut a` where `&mut a` was written but a non-ref type provided.
Since we still don't have "apply either one of the suggestions but not both" kind of thing, the interaction with the suggestion of removing `&[mut]` or moving it to the type is weird, and idk how to make it better..
r? ``@compiler-errors``
|
|
Use correct substs in enum discriminant cast
Fixes https://github.com/rust-lang/rust/issues/97634
r? ```@lcnr```
|
|
Add tracking issues to `--extern` option docs.
|
|
Reverse folder hierarchy
#91318 introduced a trait for infallible folders distinct from the fallible version. For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible. Moreover the `Error` associated type was defined on the infallible trait! It's so absurd that it has me questioning whether I was entirely sane.
This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation). This of course makes much more sense! It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.
There is one downside however: folders expose a `tcx` accessor method. Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate. Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate. If desired, I can submit that as a separate PR.
r? ````@jackh726````
|
|
r=compiler-errors
Point to type parameter definition when not finding variant, method and associated item
fixes #77391
|
|
Leak pthread_{mutex,rwlock}_t if it's dropped while locked.
Fixes https://github.com/rust-lang/rust/issues/85434.
|
|
Set relocation_model to Pic on emscripten target
So we can support dynamically linking libraries with Emscripten (otherwise we need to use nightly and `-Zbuild-std` to rebuild std with relocations).
`````@sbc100`````
|
|
r=cuviper
Mitigate MMIO stale data vulnerability
Intel publicly disclosed the MMIO stale data vulnerability on June 14. To mitigate this vulnerability, compiler changes are required for the `x86_64-fortanix-unknown-sgx` target.
cc: ````@jethrogb````
|
|
Windows: Iterative `remove_dir_all`
This will allow better strategies for use of memory and File handles. However, fully taking advantage of that is left to future work.
Note to reviewer: It's probably best to view the `remove_dir_all_recursive` as a new function. The diff is not very helpful (imho).
|
|
Make RwLockReadGuard covariant
Hi, first time contributor here, if anything is not as expected, please let me know.
`RwLockReadGoard`'s type constructor is invariant. Since it behaves like a smart pointer to an immutable reference, there is no reason that it should not be covariant. Take e.g.
```
fn test_read_guard_covariance() {
fn do_stuff<'a>(_: RwLockReadGuard<'_, &'a i32>, _: &'a i32) {}
let j: i32 = 5;
let lock = RwLock::new(&j);
{
let i = 6;
do_stuff(lock.read().unwrap(), &i);
}
drop(lock);
}
```
where the compiler complains that &i doesn't live long enough. If `RwLockReadGuard` is covariant, then the above code is accepted because the lifetime can be shorter than `'a`.
In order for `RwLockReadGuard` to be covariant, it can't contain a full reference to the `RwLock`, which can never be covariant (because it exposes a mutable reference to the underlying data structure). By reducing the data structure to the required pieces of `RwLock`, the rest falls in place.
If there is a better way to do a test that tests successful compilation, please let me know.
Fixes #80392
|
|
Add `Iterator::next_chunk`
See also https://github.com/rust-lang/rust/pull/92393
### Prior art
- [`Itertools::next_tuple()`](https://docs.rs/itertools/latest/itertools/trait.Itertools.html#method.next_tuple)
### Unresolved questions
- Should we also add `next_chunk_back` to `DoubleEndedIterator`?
- Should we rather call this `next_array()` or `next_array_chunk`?
|
|
|
|
Bump version to 1.64.0
r? `@ghost`
|
|
|
|
|
|
|
|
Co-authored-by: Michael Goulet <michael@errs.io>
|
|
|
|
|
|
|
|
update Miri
Fixes https://github.com/rust-lang/rust/issues/98366
r? `@ghost` Cc `@rust-lang/miri`
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #91264 (Add macro support in jump to definition feature)
- #96955 (Remove (transitive) reliance on sorting by DefId in pretty-printer)
- #97633 (Session object: Set OS/ABI)
- #98039 (Fix `panic` message for `BTreeSet`'s `range` API and document `panic` cases)
- #98214 (rustc_target: Remove some redundant target properties)
- #98280 (Improve suggestion for calling fn-like expr on type mismatch)
- #98394 (Fixup missing renames from `#[main]` to `#[rustc_main]`)
- #98411 (Update tendril)
- #98419 (Remove excess rib while resolving closures)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Remove excess rib while resolving closures
I've mentioned this on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60ClosureOrAsyncRibKind.60.20weirdness/near/286982959), in `rustc_resolve`, while resolving closures we add an excess `ClosureOrAsyncRibKind`. It's excess because we later add another one in `visit_fn`.
I couldn't find a way in which removing this will break anything, all test seem to pass, etc.
r? ``@compiler-errors``
cc ``@davidtwco``
|
