| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rustdoc font test
Add a font test based on #85669 fixes #85632.
r? `@jsha` `@GuillaumeGomez`
|
|
Skip assert ICE with default_method_body_is_const
functions marked with #[default_method_body_is_const] would
ICE when being const checked due to it not being a const function:
`tcx.is_const_fn_raw(did)` returns false. We should skip this assert
when it is marked with that attribute.
r? `@oli-obk`
|
|
Enable `--all-targets` for `x.py check` unconditionally
Now that Cargo deduplicates diagnostics from different targets, this doesn't flood the console with
duplicate errors.
Note that this doesn't add `--all-targets` in `Builder::cargo` directly because `impl Step for Std`
actually wants to omit `--all-targets` the first time while it's still building libtest.
When passed `--all-targets`, this warns that the option isn't needed, but still continues to compile.
Fixes https://github.com/rust-lang/rust/issues/87846.
r? ``@Mark-Simulacrum``
|
|
r=estebank
Closure migration multispan suggestions
This changes the `rust_2021_incompatible_closure_captures` lint to only suggest inserting the parts that need to be inserted, instead of suggesting to replace the entire closure by an almost identical closure with one statement added.
Before:
```
[...]
help: add a dummy let to cause `a` to be fully captured
|
5 ~ let _ = || {
6 + let _ = &a;
7 + dbg!(a.0);
8 + println!("1");
9 + println!("2");
10 + println!("3");
...
|
[...]
help: add a dummy let to cause `b` to be fully captured
|
14 | let _ = || { let _ = &b; dbg!(b.0); };
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
help: add a dummy let to cause `c` to be fully captured
|
16 | let _ = || { let _ = &c; dbg!(c.0) };
| ~~~~~~~~~~~~~~~~~~~~~~~~~
```
After:
```
[...]
help: add a dummy let to cause `a` to be fully captured
|
5 ~ let _ = || {
6 + let _ = &a;
|
[...]
help: add a dummy let to cause `b` to be fully captured
|
14 | let _ = || { let _ = &b; dbg!(b.0); };
| +++++++++++
[...]
help: add a dummy let to cause `c` to be fully captured
|
16 | let _ = || { let _ = &c; dbg!(c.0) };
| +++++++++++++ +
```
|
|
Adding explicit notice of lack of documentation for Tier 2 Platforms
Fixing: https://github.com/rust-lang/rustup/issues/2788
|
|
[rustdoc] Copy only item path to clipboard rather than full `use` statement.
The (somewhat) recent addition of the "copy item import to clipboard" button is extremely nice.
However, i tend to write my code with fully qualified paths wherever feasible and only resort to `use` statements as a refactoring pass. This makes the "copy to clipboard" workflow awkward to use, as i would be copy-pasting that as, say
```rust
impl use std::ops::Add; for MyType {
```
and then go back and remove the `use ` and `;`.
This PR removes the `use ;` decorations, making it much nicer to use for fully-qualified items. I argue, however, that this does not noticeably degrade experience for those who prefer to import items, since the hard part about those is getting the path right, and writing the `use ;` decoration can be done by hand with little effort.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Since https://reviews.llvm.org/D103355 this will usually also use
internal rather than private on Windows as well. We don't
particularly care about this implementation detail, just accept
either.
|
|
|
|
|
|
|
|
|
|
When LLVM_INCLUDE_TESTS is enabled (by default), LLVM requires
Python 3.6 for the lit test runner, otherwise only Python 3.0 is
required.
As we have many docker images using Ubuntu 16.04, which only has
Python 3.5, this avoids the need to install a newer Python version
for them.
|
|
The #[used] attribute explicitly only requires symbols to be
retained in object files, but allows the linker to drop them
if dead. This corresponds to llvm.compiler.used semantics.
The motivation to change this *now* is that https://reviews.llvm.org/D97448
starts emitting #[used] symbols into unique sections with
SHF_GNU_RETAIN flag. This triggers a bug in some version of gold,
resulting in the ARGV_INIT_ARRAY symbol part of the .init_array
section to be incorrectly placed.
|
|
This uses comdats since LLVM 13, causing various minor changes to the
output.
|
|
This has regressed due to https://bugs.llvm.org/show_bug.cgi?id=51211.
It's pretty likely that we'll have to eat this regression for this
release.
|
|
This is how InlineAsm diagnostics with source information are
reported now. Previously a separate InlineAsm diagnostic handler
was used.
|
|
|
|
|
|
|
|
|
|
|
|
Add future-incompat lint for `doc(primitive)`
## What is `doc(primitive)`?
`doc(primitive)` is an attribute recognized by rustdoc which adds documentation for the built-in primitive types, such as `usize` and `()`. It has been stable since Rust 1.0.
## Why change anything?
`doc(primitive)` is useless for anyone outside the standard library. Since rustdoc provides no way to combine the documentation on two different primitive items, you can only replace the docs, and since the standard library already provides extensive documentation there is no reason to do so.
While fixing rustdoc's handling of primitive items (https://github.com/rust-lang/rust/pull/87073) I discovered that even rustdoc's existing handling of primitive items was broken if you had more than two crates using it (it would pick randomly between them). That meant both:
- Keeping rustdoc's existing treatment was nigh-impossible, because it was random.
- doc(primitive) was even more useless than it would otherwise be.
The only use-case for this outside the standard library is for no-std libraries which want to link to primitives (https://github.com/rust-lang/rust/issues/73423) which is being fixed in https://github.com/rust-lang/rust/pull/87073.
https://github.com/rust-lang/rust/pull/87073 makes various breaking changes to `doc(primitive)` (breaking in the sense that they change the semantics, not in that they cause code to fail to compile). It's not possible to avoid these and still fix rustdoc's issues.
## What can we do about it?
As shown by the crater run (https://github.com/rust-lang/rust/pull/87050#issuecomment-886166706), no one is actually using doc(primitive), there wasn't a single true regression in the whole run. We can either:
1. Feature gate it completely, breaking anyone who crater missed. They can easily fix the breakage just by removing the attribute.
2. add it to the `INVALID_DOC_ATTRIBUTES` future-incompat lint, and at the same time make it a no-op unless you add a feature gate. That would mean rustdoc has to look at the features of dependent crates, because it needs to know where primitives are defined in order to link to them.
3. add it to `INVALID_DOC_ATTRIBUTES`, but still use it to determine where primitives come from
4. do nothing; the behavior will silently change in https://github.com/rust-lang/rust/pull/87073.
My preference is for 2, but I would also be happy with 1 or 3. I don't think we should silently change the behavior.
This PR currently implements 3.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix `reachable_set` for non-function items in non-library crates
I unintentionally changed `reachable_set` to ignore non-function items when `!self.any_library` in https://github.com/rust-lang/rust/pull/86492, which can lead to "undefined reference" errors in non-library (`cdylib`/`staticlib`/`bin`) crates, for example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6bb2c5065a9be7e40943d0541e161b5a
This PR restores the behavior of `reachable_set` for non-function items.
Fixes https://github.com/rust-lang/rust/issues/88016.
<details>
<summary>The modified test will fail with this output without the `reachable_set` change</summary>
```
---- [codegen] codegen/external-no-mangle-statics.rs#staticlib stdout ----
error in revision `staticlib`: verification with 'FileCheck' failed
status: exit status: 1
command: "/checkout/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck" "--input-file" "/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll" "/checkout/src/test/codegen/external-no-mangle-statics.rs" "--check-prefixes" "CHECK,NONMSVC,staticlib"
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
/checkout/src/test/codegen/external-no-mangle-statics.rs:10:11: error: CHECK: expected string not found in input
// CHECK: `@A` = local_unnamed_addr constant
^
/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll:1:1: note: scanning from here
; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
^
/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll:1:6: note: possible intended match here
; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
^
Input file: /checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll
Check file: /checkout/src/test/codegen/external-no-mangle-statics.rs
-dump-input=help explains the following input dump.
Input was:
<<<<<<
1: ; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
check:10'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
check:10'1 ? possible intended match
2: source_filename = "external_no_mangle_statics.b50529d3-cgu.0"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3: target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4: target triple = "x86_64-unknown-linux-gnu"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5:
check:10'0 ~
6: !llvm.module.flags = !{!0, !1}
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.
.
.
>>>>>>
------------------------------------------
failures:
[codegen] codegen/external-no-mangle-statics.rs#staticlib
```
</details>
|
|
Uplift the invalid_atomic_ordering lint from clippy to rustc
This is mostly just a rebase of https://github.com/rust-lang/rust/pull/79654; I've copy/pasted the text from that PR below.
r? `@lcnr` since you reviewed the last one, but feel free to reassign.
---
This is an implementation of https://github.com/rust-lang/compiler-team/issues/390.
As mentioned, in general this turns an unconditional runtime panic into a (compile time) lint failure. It has no false positives, and the only false negatives I'm aware of are if `Ordering` isn't specified directly and is comes from an argument/constant/whatever.
As a result of it having no false positives, and the alternative always being strictly wrong, it's on as deny by default. This seems right.
In the [zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Uplift.20the.20.60invalid_atomic_ordering.60.20lint.20from.20clippy/near/218483957) `@joshtriplett` suggested that lang team should FCP this before landing it. Perhaps libs team cares too?
---
Some notes on the code for reviewers / others below
## Changes from clippy
The code is changed from [the implementation in clippy](https://github.com/rust-lang/rust-clippy/blob/68cf94f6a66e47234e3adefc6dfbe806cd6ad164/clippy_lints/src/atomic_ordering.rs) in the following ways:
1. Uses `Symbols` and `rustc_diagnostic_item`s instead of string literals.
- It's possible I should have just invoked Symbol::intern for some of these instead? Seems better to use symbol, but it did require adding several.
2. The functions are moved to static methods inside the lint struct, as a way to namespace them.
- There's a lot of other code in that file — which I picked as the location for this lint because `@jyn514` told me that seemed reasonable.
3. Supports unstable AtomicU128/AtomicI128.
- I did this because it was almost easier to support them than not — not supporting them would have (ideally) required finding a way not to give them a `rustc_diagnostic_item`, which would have complicated an already big macro.
- These don't have tests since I wasn't sure if/how I should make tests conditional on whether or not the target has the atomic... This is to a certain extent an issue of 64bit atomics too, but 128-bit atomics are much less common. Regardless, the existing tests should be *more* than thorough enough here.
4. Minor changes like:
- grammar tweaks ("loads cannot have `Release` **and** `AcqRel` ordering" => "loads cannot have `Release` **or** `AcqRel` ordering")
- function renames (`match_ordering_def_path` => `matches_ordering_def_path`),
- avoiding clippy-specific helper methods that don't exist in rustc_lint and didn't seem worth adding for this case (for example `cx.struct_span_lint` vs clippy's `span_lint_and_help` helper).
## Potential issues
(This is just about the code in this PR, not conceptual issues with the lint or anything)
1. I'm not sure if I should have used a diagnostic item for `Ordering` and its variants (I couldn't figure out how really, so if I should do this some pointers would be appreciated).
- It seems possible that failing to do this might possibly mean there are more cases this lint would miss, but I don't really know how `match_def_path` works and if it has any pitfalls like that, so maybe not.
2. I *think* I deprecated the lint in clippy (CC `@flip1995` who asked to be notified about clippy changes in the future in [this comment](https://github.com/rust-lang/rust/pull/75671#issuecomment-718731659)) but I'm not sure if I need to do anything else there.
- I'm kind of hoping CI will catch if I missed anything, since `x.py test src/tools/clippy` fails with a lot of errors with and without my changes (and is probably a nonsense command regardless). Running `cargo test` from src/tools/clippy also fails with unrelated errors that seem like refactorings that didnt update clippy? So, honestly no clue.
3. I wasn't sure if the description/example I gave good. Hopefully it is. The example is less thorough than the one from clippy here: https://rust-lang.github.io/rust-clippy/master/index.html#invalid_atomic_ordering. Let me know if/how I should change it if it needs changing.
4. It pulls in the `if_chain` crate. This crate was already used in clippy, and seems like it's used elsewhere in rustc, but I'm willing to rewrite it to not use this if needed (I'd prefer not to, all things being equal).
|
|
|
|
|
|
The iOS toolchain can be built on Linux with minor changes. The
compilation will invoke `xcrun` to find the path to the iPhone SDK but
a fake `xcrun` executable can be used.
```
#!/bin/sh
echo "/path/to/sdk"
```
The iOS toolchain can then be built and linked with rustup.
```
$ ./x.py build --stage 2 --host x86_64-unknown-linux-gnu \
--target aarch64-apple-ios
$ rustup toolchain link stage1 build/x86_64-unknown-linux-gnu/stage1
```
It's possible to take this toolchain and compile an iOS executable
with it. This requires the ld64 linker and an iOS SDK. The ld64 linker
can be taken from
[cctools](https://github.com/tpoechtrager/cctools-port). A project's
.cargo/config can then be edited to use the linker for this target.
```
[target.aarch64-apple-ios]
linker = "/path/to/cctools/bin/arm-apple-darwin-ld"
rustflags = [
"-C",
"""
link-args=
-F/path/to/sdk/System/Library/Frameworks
-L/path/to/sdk/usr/lib
-L/path/to/sdk/usr/lib/system/
-adhoc_codesign
""",
]
```
|
|
- Deprecate clippy::invalid_atomic_ordering
- Use rustc_diagnostic_item for the orderings in the invalid_atomic_ordering lint
- Reduce code duplication
- Give up on making enum variants diagnostic items and just look for
`Ordering` instead
I ran into tons of trouble with this because apparently the change to
store HIR attrs in a side table also gave the DefIds of the
constructor instead of the variant itself. So I had to change
`matches_ordering` to also check the grandparent of the defid as well.
- Rename `atomic_ordering_x` symbols to just the name of the variant
- Fix typos in checks - there were a few places that said "may not be
Release" in the diagnostic but actually checked for SeqCst in the lint.
- Make constant items const
- Use fewer diagnostic items
- Only look at arguments after making sure the method matches
This prevents an ICE when there aren't enough arguments.
- Ignore trait methods
- Only check Ctors instead of going through `qpath_res`
The functions take values, so this couldn't ever be anything else.
- Add if_chain to allowed dependencies
- Fix grammar
- Remove unnecessary allow
|
|
|
|
This reverts commit 8007b506ac5da629f223b755f5a5391edd5f6d01, reversing
changes made to e55c13e1099b78b1a485202fabc9c1b10b1f1d15.
|
|
This is possible now that rustdoc allows passing
`--document-private-items` more than once.
|
|
Introduce `hir::ExprKind::Let` - Take 2
Builds on #68577 and depends on #79328.
cc #53667
|
|
|
|
Deprecate llvm_asm!
We would like to remove `llvm_asm!` from the compiler once `asm!` is stabilized. This PR deprecates `llvm_asm!` to encourage any remaining users to migrate to `asm!` (or if `asm!` is not supported for their target, to add this support to rustc).
The only remaining user of `llvm_asm!` in the standard library was `black_box`, which has been rewritten to use volatile operations when `asm!` is not available on the current target.
cc `@rust-lang/wg-inline-asm`
cc `@RalfJung` for the changes to `black_box` which might affect Miri.
r? `@nagisa`
|
|
|
|
Fixes #85019
A `SourceFile` created during compilation may have a relative
path (e.g. if rustc itself is invoked with a relative path).
When we write out crate metadata, we convert all relative paths
to absolute paths using the current working direction.
However, the working directory is not included in the crate hash.
This means that the crate metadata can change while the crate
hash remains the same. Among other problems, this can cause a
fingerprint mismatch ICE, since incremental compilation uses
the crate metadata hash to determine if a foreign query is green.
This commit moves the field holding the working directory from
`Session` to `Options`, including it as part of the crate hash.
|
|
|
|
Add automatic migration for assert!(.., string).
Fixes part of #87313.
|
