| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Add a regression test for issue-51446
Closes #51446
r? `@estebank`
|
|
Fix NixOS patching
Moving the `.nix-deps` has resulted in rpath links being broken and
therefore bootstrap on NixOS broken entirely.
This PR still produces a `.nix-deps` but only for the purposes of
producing a gc root. We rpath a symlink-resolved result instead.
For purposes of simplicity we also use joinSymlink to produce a single
merged output directory so that we don't need to update multiple
locations every time we add a library or something.
Fixes a regression from https://github.com/rust-lang/rust/pull/82739.
|
|
fix incorrect Box::from_raw_in doctest
Now that Miri can run doctests, I ran it on liballoc, and found exactly one problem: this test creates a `Box<u8>` to deallocate a 4-byte allocation!
Introduced by https://github.com/rust-lang/rust/pull/80310 so r? `@Manishearth` `@kennytm`
|
|
Expand derive invocations in left-to-right order
While derives were being collected in left-to-order order, the
corresponding `Invocation`s were being pushed in the wrong order.
|
|
While derives were being collected in left-to-order order, the
corresponding `Invocation`s were being pushed in the wrong order.
|
|
Moving the `.nix-deps` has resulted in rpath links being broken and
therefore bootstrap on NixOS broken entirely.
This PR still produces a `.nix-deps` but only for the purposes of
producing a gc root. We rpath a symlink-resolved result instead.
For purposes of simplicity we also use joinSymlink to produce a single
merged output directory so that we don't need to update multiple
locations every time we add a library or something.
|
|
Add some proc-macro attribute token handling tests
Split out from https://github.com/rust-lang/rust/pull/82608
r? `@petrochenkov`
|
|
|
|
fix Miri errors in libcore doctests
Now that Miri can run doctests, it found some issues in the libcore doctests:
* The `AtomicPtr` tests accessed dangling memory! `AtomicPtr::new(&mut 10);` makes the `10` a temporary that is deallocated after the end of this expression.
* The tests for `set_ptr_value` used `&array[0] as *const _` to get a pointer to the array; this needs to be `array.as_ptr()` instead (Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/134).
* I reduced a buffer size in a `MaybeUninit` test to make it less slow in Miri, and added a spin loop hint to fix a diverging loop in Miri.
|
|
Don't tell users to use a nightly flag on the stable channel
When a crate requires a newer edition, currently rustc tells users to use `-Z unstable-options`. This is not ideal, because:
* This flag doesn't work on the stable channel, so solution to one error only causes another error, which is frustrating.
* Directs users towards the nightly channel, which is not necessarily the correct solution. Once the next edition is released, this message will be mostly seen by users of out-of-date stable Rust versions who merely need to update their Rust to the latest stable.
|
|
Hint upgrading to a newer Rust version instead
|
|
Update LLVM submodule
Fixes #84028
|
|
|
|
|
|
|
|
update Miri
Let's ship https://github.com/rust-lang/miri/pull/1761.
Cc `@rust-lang/miri` r? `@ghost`
|
|
|
|
Avoid `;` -> `,` recovery and unclosed `}` recovery from being too verbose
Those two recovery attempts have a very bad interaction that causes too
unnecessary output. Add a simple gate to avoid interpreting a `;` as a
`,` when there are unclosed braces.
Fix #83498.
|
|
doc asm feature - Added new 'Label' section with example and explanations
Fixes #76704
|
|
r=petrochenkov
Categorize and explain target features support
There are 3 different uses of the `-C target-feature` args passed to rustc:
1. All of the features are passed to LLVM, which uses them to configure code-generation. This is sort-of stabilized since 1.0 though LLVM does change/add/remove target features regularly.
2. Target features which are in [the compiler's allowlist](https://github.com/rust-lang/rust/blob/69e1d22ddbc67b25141a735a22a8895a678b32ca/compiler/rustc_codegen_ssa/src/target_features.rs#L12-L34) can be used in `cfg!(target_feature)` etc. These may have different names than in LLVM and are renamed before passing them to LLVM.
3. Target features which are in the allowlist and which are stabilized or feature-gate-enabled can be used in `#[target_feature]`.
It can be confusing that `rustc --print target-features` just prints out the LLVM features without separating out the rustc features or even mentioning that the dichotomy exists.
This improves the situation by separating out the rustc and LLVM target features and adding a brief explanation about the difference.
Abbreviated Example Output:
```
$ rustc --print target-features
Features supported by rustc for this target:
adx - Support ADX instructions.
aes - Enable AES instructions.
...
xsaves - Support xsaves instructions.
crt-static - Enables libraries with C Run-time Libraries(CRT) to be statically linked.
Code-generation features supported by LLVM for this target:
16bit-mode - 16-bit mode (i8086).
32bit-mode - 32-bit mode (80386).
...
x87 - Enable X87 float instructions.
xop - Enable XOP instructions.
Use +feature to enable a feature, or -feature to disable it.
For example, rustc -C target-cpu=mycpu -C target-feature=+feature1,-feature2
Code-generation features cannot be used in cfg or #[target_feature],
and may be renamed or removed in a future version of LLVM or rustc.
```
Motivated by #83975.
CC https://github.com/rust-lang/rust/issues/49653
|
|
Fix perf regression in rustdoc::bare_urls
This regressed in #81764. After that PR, rustdoc compiled the regex for every single item in the crate: https://perf.rust-lang.org/compare.html?start=125505306744a0a5bb01d62337260a95d9ff8d57&end=2e495d2e845cf27740e3665f718acfd3aa17253e&stat=instructions%3Au
This would have been caught by `clippy::declare_interior_mutable_const` (cc https://github.com/rust-lang/rust/issues/77983).
|
|
Those two recovery attempts have a very bad interaction that causes too
unnecessary output. Add a simple gate to avoid interpreting a `;` as a
`,` when there are unclosed braces.
|
|
reduce threads spawned by ui-tests
The test harness already spawns enough tests to keep all cores busy.
Individual tests should keep their own threading to a minimum to avoid context switch overhead.
When running ui tests with lld enabled this shaves about 10% off that testsuite on my machine.
Resolves #81946
|
|
|
|
Before, this was compiling the regex on every single item in the crate.
This would have been caught by `clippy::declare_interior_mutable_const`.
|
|
rustdoc: Don't generate blanket impls when running --show-coverage
`get_blanket_impls` is the slowest part of rustdoc, and the coverage pass
completely ignores blanket impls. This stops running it at all, and also
removes some unnecessary checks in `calculate_doc_coverage` that ignored
the impl anyway.
We don't currently measure --show-coverage in perf.rlo, but I tested
this locally on cargo and it brought the time down from 2.9 to 1.6
seconds.
This also adds back a commented-out test; Rustdoc has been able to deal with `impl trait` for almost a year now.
r? `@GuillaumeGomez`
|
|
|
|
Rustdoc has been able to deal with `impl trait` for almost a year now.
|
|
get_blanket_impls is the slowest part of rustdoc, and the coverage pass
completely ignores blanket impls. This stops running it at all, and also
removes some unnecessary checks in `calculate_doc_coverage` that ignored
the impl anyway.
We don't currently measure --show-coverage in perf.rlo, but I tested
this locally on cargo and it brought the time down from 2.9 to 1.6
seconds.
|
|
|
|
|
|
|
|
issue-76704-fix
merging
|
|
|
|
Mention missing 1.38.0 change in RELEASES.md
Mention that doc comments on `pub use` statements are prepended to the documentation of the reexported item
Fixes #84007
|
|
Use a more appropriate span for `;` suggestion
Fix #83892.
|
|
the test harness already spawns enough tests for all cores, individual
tests should keep their own threading to a minimum to avoid context switch
overhead
some tests fail with 1 CGU, so explicit compile flags have been added
to keep their old behavior
|
|
|
|
Don't concatenate binders across types
Partially addresses #83737
There's actually two issues that I uncovered in #83737. The first is that we are concatenating bound vars across types, i.e. in
```
F: Fn(&()) -> &mut (dyn Future<Output = ()> + Unpin)
```
the bound vars on `Future` get set as `for<anon>` since those are the binders on `Fn(&()`. This is obviously wrong, since we should only concatenate directly nested trait refs. This is solved here by introducing a new `TraitRefBoundary` scope, that we put around the "syntactical" trait refs and basically don't allow concatenation across.
Now, this alone *shouldn't* be a super terrible problem. At least not until you consider the other issue, which is a much more elusive and harder to design a "perfect" fix. A repro can be seen in:
```
use core::future::Future;
async fn handle<F>(slf: &F)
where
F: Fn(&()) -> &mut (dyn for<'a> Future<Output = ()> + Unpin),
{
(slf)(&()).await;
}
```
Notice the `for<'a>` around `Future`. Here, `'a` is unused, so the `for<'a>` Binder gets changed to a `for<>` Binder in the generator witness, but the "local decl" still has it. This has heavy intersections with region anonymization and erasing. Luckily, it's not *super* common to find this unique set of circumstances. It only became apparently because of the first issue mentioned here. However, this *is* still a problem, so I'm leaving #83737 open.
r? `@nikomatsakis`
|
|
Improve debuginfo for closures and async functions on Windows MSVC
The issue was that the resulting debuginfo was too complex for LLVM to
translate into CodeView records correctly. As a result, it simply
ignored the debuginfo which meant Windows debuggers could not display
any closed over variables when stepping inside a closure or async fn.
This fixes that by creating additional allocas on the stack so that
the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and
LLVM can generate the correct CV records.
I also updated some of our existing tests to run in CDB to cover this case.
Before (closure):
After (closure):
Before (async):
After (async):
Fixes #83709
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #80733 (Improve links in inline code in `core::pin`.)
- #81764 (Stabilize `rustdoc::bare_urls` lint)
- #81938 (Stabilize `peekable_peek_mut`)
- #83980 (Fix outdated crate names in compiler docs)
- #83992 (Merge idents when generating source content)
- #84001 (Update Clippy)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Mention that doc comments on `pub use` statements are prepended to the documentation of the reexported item
|
|
Update Clippy
Biweekly Clippy update
r? ``@Manishearth``
|
|
Merge idents when generating source content
The idea here is to not have a span for each part of a path. Currently, for `a::b::c` we generate `<span>a</span>::<span>b</span>::<span>c</span>`, with this change, we will generate `<span>a::b::c</span>`.
A nice "side-effect" is that it reduces the size of the output HTML too. :)
cc `@notriddle`
|
|
Fix outdated crate names in compiler docs
Changes `librustc_X` to `rustc_X`, only in documentation comments.
Plain code comments are left unchanged.
|
|
Stabilize `peekable_peek_mut`
Resolves #78302. Also adds some documentation on `std::iter::Iterator::peekable()` regarding the new method.
The feature was added in #77491 in Nov' 20, which is recently, but the feature seems reasonably small. Never did a stabilization-pr, excuse my ignorance if there is a protocol I'm not aware of.
|
|
Stabilize `rustdoc::bare_urls` lint
Closes https://github.com/rust-lang/rust/issues/77501. Closes https://github.com/rust-lang/rust/issues/83598.
|
