If crate declares `rust_eh_personality`, re-use existing declaration
as otherwise attempts to set function attributes that follow the
declaration will fail (unless it happens to have exactly the same
type signature as the one predefined in the compiler).
The LLD + ThinLTO __morestack bug has been fixed in 12.0.1, so
we can now update our clang version. This also means that we no
longer need to build Python 2.
only check cg defaults wf once instantiated
the previous fixmes here didn't make too much sense as I didn't yet fully understand the code further below.
That code only runs if the predicates using our generic param default are fully concrete after substituting our default, which never happens if our default is generic.
r? `@oli-obk` `@BoxyUwU`
Remove `missing_docs` lint on private 2.0 macros
798baebde1/compiler/rustc_lint/src/builtin.rs (L573-L584)
This code is the source of #57569. The problem is subtle, so let me point it out. This code makes the mistake of assuming that all of the macros in `krate.exported_macros` are exported.
...Yeah. For some historical reason, all `macro` macros are marked as exported, regardless of whether they actually are, which is dreadfully confusing. It would be more accurate to say that `exported_macros` currently contains only macros that have paths.
This PR renames `exported_macros` to `importable_macros`, since these macros can be imported with `use` while others cannot. It also fixes the code above to no longer lint on private `macro` macros, since the `missing_docs` lint should only appear on exported items.
Fixes#57569.
Add support for raw-dylib with stdcall, fastcall functions
Next stage of work for #58713: allow `extern "stdcall"` and `extern "fastcall"` with `#[link(kind = "raw-dylib")]`.
I've deliberately omitted support for vectorcall, as that doesn't currently work, and I wanted to get this out for review. (I haven't really investigated the vectorcall failure much yet, but at first (very cursory) glance it appears that the problem is elsewhere.)
Use #[track_caller] in const panic diagnostics.
This change stops const panic diagnostics from reporting inside #[track_caller] functions by skipping over them.
Change linked tracking issue for more_qualified_paths
This updates the linked tracking issue for the `more_qualified_paths` feature from the implementation PR #80080 to an actual tracking issue #86935.
Fix double warning about illegal floating-point literal pattern
This PR fixes#86600. The problem is that the `ConstToPat` struct contains a field `include_lint_checks`, which determines whether lints should be emitted or not, but this field is currently not obeyed at one point, leading to a warning being emitted more than once. I have fixed this behavior here.
Account for capture kind in auto traits migration
Modifies the current auto traits migration for RFC2229 so it takes into account capture kind
Closes https://github.com/rust-lang/project-rfc-2229/issues/51
r? `@nikomatsakis`
2229: Reduce the size of closures with `capture_disjoint_fields`
One key observation while going over the closure size profile of rustc
was that we are disjointly capturing one or more fields starting at an
immutable reference.
Disjoint capture over immutable reference doesn't add too much value
because the fields can either be borrowed immutably or copied.
One possible edge case of the optimization is when a fields of a struct
have a longer lifetime than the structure, therefore we can't completely
get rid of all the accesses on top of sharef refs, only the rightmost
one. Here is a possible example:
```rust
struct MyStruct<'a> {
a: &'static A,
b: B,
c: C<'a>,
}
fn foo<'a, 'b>(m: &'a MyStruct<'b>) -> impl FnMut() + 'static {
let c = || drop(&*m.a.field_of_a);
// Here we really do want to capture `*m.a` because that outlives `'static`
// If we capture `m`, then the closure no longer outlives `'static'
// it is constrained to `'a`
}
```
r? `@nikomatsakis`
Document rustdoc with `--document-private-items`
The `tool_doc` macro introduced in #86737 did not use `false` as the default value for `binary` when it is not provided, so the `if` is not even expanded and thus the argument is never provided if the `binary` argument isn't.
Resolves#86900
r? ```@Mark-Simulacrum```
Checking that function is const if marked with rustc_const_unstable
Fixes#69630
This one is still missing tests to check the behavior but I checked by hand and it seemed to work.
I would not mind some direction for writing those unit tests!
Support pretty printing slices using GDB
Support pretty printing `&[T]`, `&mut [T]` and `&mut str` types using GDB.
Support pretty printing `&mut [T]` and `&mut str` types using LLDB.
Fixes#85219.
remove trailing newline
fix: test with attribute but missing const
Update compiler/rustc_passes/src/stability.rs
Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
Add test for extern functions
fix: using span_help instead of span_suggestion
add test for some ABIs + fmt fix
Update compiler/rustc_passes/src/stability.rs
Co-authored-by: Léo Lanteri Thauvin <leseulartichaut@gmail.com>
Refractor and add test for `impl const`
Add test to make sure no output + cleanup condition
-----------------------------
remove stdcall test, failing CI test
C abi is already tested in this, so it is not that useful to test another one.
The tested code is blind to which specific ABI for now, as long as it's not an intrinsic one
Clean up rustdoc static files
The `html/static` of rustdoc was starting to be quite a mess... So I moved files in sub-folders to make it easier to follow. Here what remains in `html/static` folder:
```
$ ls
COPYRIGHT.txt css fonts images js LICENSE-APACHE.txt LICENSE-MIT.txt
```
cc ```@jyn514```
r? ```@Manishearth```
Fix ICE when misplaced visibility cannot be properly parsed
Fixes#86895
The issue was that a failure to parse the visibility was causing the original error to be dropped before being emitted.
The resulting error isn't quite as nice as when the visibility is parsed properly, but I'm not sure which error to prioritize here. Displaying both errors might be too confusing.
r? ```@estebank```
Sync rustc_codegen_cranelift
The main hightlight this sync is basic support for AArch64. Most things should work on Linux, but there does seem to be an ABI incompatibility causing proc-macros to crash, see https://github.com/bjorn3/rustc_codegen_cranelift/issues/1184. Thanks to ```@afonso360``` for implementing all Cranelift features that were necessary to compile for AArch64 using cg_clif. Also thanks to ```@shamatar``` for implementing the `llvm.x86.addcarry.64` and `llvm.x86.subborrow.64` llvm intrinsics used by num-bigint (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1178) and ```@eggyal``` for implementing multi-threading support for the lazy jit mode. (https://github.com/bjorn3/rustc_codegen_cranelift/pull/1166)
r? ```@ghost```
```@rustbot``` label +A-codegen +A-cranelift +T-compiler
Recover from `&dyn mut ...` parse errors
Consider this example:
```rust
fn main() {
let r: &dyn mut Trait;
}
```
This currently leads to:
```
error: expected one of `!`, `(`, `;`, `=`, `?`, `for`, lifetime, or path, found keyword `mut`
--> src/main.rs:2:17
|
2 | let r: &dyn mut Trait;
| ^^^ expected one of 8 possible tokens
error: aborting due to previous error
```
However, especially for beginners, I think it is easy to get `&dyn mut` and `&mut dyn` confused. With my changes, I get a help message, and the parser even recovers:
```
error: `mut` must precede `dyn`
--> test.rs:2:12
|
2 | let r: &dyn mut Trait;
| ^^^^^^^^ help: place `mut` before `dyn`: `&mut dyn`
error[E0405]: cannot find trait `Trait` in this scope
--> test.rs:2:21
|
2 | let r: &dyn mut Trait;
| ^^^^^ not found in this scope
error: aborting due to 2 previous errors
```
Support lint tool names in rustc command line options
When rustc is running without a lint tool such as clippy enabled, options for lints such as `clippy::foo` are meant to be ignored. This was already working for those specified by attrs, such as `#![allow(clippy::foo)]`, but this did not work for command line arguments like `-A clippy::foo`. This PR fixes that issue.
Note that we discovered this issue while discussing https://github.com/rust-lang/cargo/issues/5034.
Fixes#86628.
This change merges `check_lint_and_tool_name` into `check_lint_name` in
order to avoid having two very similar functions.
Also adds the `.stderr` file back for the test case, since apparently
it is still needed.
All eabi targets have target_abi = "eabi".
All eabihf targets have target_abi = "eabihf".
armv6_unknown_freebsd and armv7_unknown_freebsd have target_abi = "eabihf".
All abi64 targets have target_abi = "abi64".
All ilp32 targets have target_abi = "ilp32".
All softfloat targets have target_abi = "softfloat".
All *-uwp-windows-* targets have target_abi = "uwp".
All spe targets have target_abi = "spe".
All macabi targets have target_abi = "macabi".
aarch64-apple-ios-sim has target_abi = "sim".
x86_64-fortanix-unknown-sgx has target_abi = "fortanix".
x86_64-unknown-linux-gnux32 has target_abi = "x32".
Add FIXME entries for targets for which existing values need to change
once cfg_target_abi becomes stable. (All of them are tier 3 targets.)
Add a test for target_abi in `--print cfg`.
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.
Gated by `feature(cfg_target_abi)`.
Add a test for `target_abi`, and a test for the feature gate.
Add `target_abi` to tidy as a platform-specific cfg.
This does not add an abi to any existing target.
Update books
## nomicon
8 commits in b9ca313e687c991223e23e5520529815dc281205..7a13537f96af4b9b8e3ea296d6e5c3c7ab72ce9f
2021-06-22 12:02:20 -0400 to 2021-07-05 23:34:47 -0400
- Apply review comments
- Fix some style issues
- Move the list of coercions to the reference
- Add an example that shows the null-pointer opt does not happen
- Remove casting list from the nomicon (rust-lang-nursery/nomicon#287)
- Audit `ignore` annotations (rust-lang-nursery/nomicon#288)
- rename typo "lifetime" to "reference" (rust-lang-nursery/nomicon#286)
- Add an incomplete warning to the top page (rust-lang-nursery/nomicon#274)
## reference
7 commits in d9699fa8f3186440fdaadd703d63d8d42322c176..ab60513a3a5a0591e237fddff5d027a982648392
2021-06-21 12:23:10 -0700 to 2021-07-05 08:27:31 -0700
- fix grammar in Expressions (rust-lang-nursery/reference#1057)
- fix comment in function parameter drop scope example (rust-lang-nursery/reference#1056)
- fix typo in macro-ambiguity.md (rust-lang-nursery/reference#1058)
- Mention (negative) infinity values on float-to-int casting (rust-lang-nursery/reference#1054)
- (rust-lang-nursery/reference#841)
- Missing TypeParamBounds in TypeAlias (rust-lang-nursery/reference#1036)
- Be more precise about array offset in type layouts (rust-lang-nursery/reference#1034)
## book
34 commits in 55a26488ddefc8433e73a2e8352d70f7a5c7fc2b..a90f07f1e9a7fc75dc9105a6c6f16d5c13edceb0
2021-05-09 12:03:18 -0500 to 2021-07-05 14:43:12 -0400
- Clarify ?Sized syntax. Fixesrust-lang/book#2422.
- Add some notes that macros are different than functions
- Break up a long sentence. Fixesrust-lang/book#2329.
- Further clarify and make consistent the reference to deref coercion
- Update ch04-03-slices.md
- add usage for `String` reference
- Update ch15-02-deref.md (rust-lang/book#2780)
- Remove claim about performance of i32
- Reword to avoid awkward pluralization
- Make the link to the reference relative
- Merge remote-tracking branch 'origin/pr/2753'
- Reword number of library crates a package contains (rust-lang/book#2750)
- Clarify explanation of why you can test private functions; add link
- Merge remote-tracking branch 'origin/pr/2743'
- Fix code hiding that I broke in eb60fedc9
- Link to the exact later section we're talking about
- improve cross-references for newtype pattern
- ch12-05, listing 12-20: Add missing "does not compile" warning (rust-lang/book#2731)
- cargo format
- Merge remote-tracking branch 'origin/pr/2724'
- Remove ordinal numbers and only refer to indexes to avoid confusion
- Let's mention the former and current authors of tlborm.
- Update tlborm link to point to Veykril's up-to-date version (rust-lang/book#2722)
- Merge remote-tracking branch 'origin/pr/2720'
- Describe the ferris pictures in the alt text
- Merge remote-tracking branch 'origin/pr/2707'
- Reword ... explanation to include the word deprecated, list that first
- Precise that the `...` inclusive range pattern has been replaces (rust-lang/book#2714)
- (rust-lang/book#2696)
- fix typo: missing "type" after generic (rust-lang/book#2777)
- (rust-lang/book#2709)
- Remove sentence about how Rust used to be
- Fix a potentially confusing statement about static lifetimes of static variables. (rust-lang/book#2692)
- Replace 'which'. (rust-lang/book#2663)
## rust-by-example
2 commits in 805e016c5792ad2adabb66e348233067d5ea9f10..028f93a61500fe8f746ee7cc6b204ea6c9f42935
2021-05-20 17:08:34 -0300 to 2021-07-06 06:28:53 -0300
- Fix a couple of typos in the `integration_testing.md` file (rust-lang/rust-by-example#1448)
- Fix Structures type list (rust-lang/rust-by-example#1446)
## rustc-dev-guide
13 commits in fe34beddb41dea5cb891032512a8d5b842b99696..60e282559104035985331645907c3d9f842312c5
2021-06-21 21:50:12 +0200 to 2021-07-05 11:21:03 -0400
- Fixed typos in inline code
- Document lang items (rust-lang/rustc-dev-guide#1119)
- More specifics on what future-incompatible lints are used for
- Fix line lens
- Update information on lints particularly on future-incompatible
- Update section of lint store
- Update around half of the January 2021 date references (rust-lang/rustc-dev-guide#1155)
- Create issues for many TODOs (rust-lang/rustc-dev-guide#1163)
- Links from rustc-dev-guide to std-dev-guide (rust-lang/rustc-dev-guide#1152)
- Document how to mark features as incomplete (rust-lang/rustc-dev-guide#1151)
- Remove requests or suggestions about rebase and fixup contradictory to rust-highfive bot comment (rust-lang/rustc-dev-guide#1111)
- Generate glossary table correctly (rust-lang/rustc-dev-guide#1146)
- Correct the wrong serial number (rust-lang/rustc-dev-guide#1147)
## edition-guide
3 commits in c74b2a0d6bf55774cf15d69f05dfe05408b8f81a..5d57b3832f8d308a9f478ce0a69799548f27ad4d
2021-06-14 10:48:27 -0700 to 2021-07-05 10:33:32 +0200
- Add more info for warnings promoted to errors (rust-lang-nursery/edition-guide#247)
- Create triagebot.toml
- Clarify snippets in 2021 panic docs. (rust-lang-nursery/edition-guide#245)
## embedded-book
1 commits in cbec77fbd8eea0c13e390dd9eded1ae200e811d1..506840eb73b0749336e1d5274e16d6393892ee82
2021-06-10 06:26:32 +0000 to 2021-06-24 00:01:32 +0000
- Update book to track quickstart changes (rust-embedded/book#296)
Migrate `cpu-usage-over-time.py` to Python 3
The only change here is a fix for `sys.platform` on Linux. Python 3.3 changed the API to return `"linux"` instead of `"linux2"`/`"linux3"`, so this PR uses `.startswith("linux")` to make the code work on Python 3 without breaking Python 2.
Clean up rustdoc IDs
I cherry-picked the commit from https://github.com/rust-lang/rust/pull/86178. It adds missing rustdoc IDs (for the HTML) and remove unused ones.
cc `@camelid`
r? `@jyn514`
Rename some Rust 2021 lints to better names
Based on conversation in https://github.com/rust-lang/rust/issues/85894.
Rename a bunch of Rust 2021 related lints:
Lints that are officially renamed because they are already in beta or stable:
* `disjoint_capture_migration` => `rust_2021_incompatible_closure_captures`
* `or_patterns_back_compat` => `rust_2021_incompatible_or_patterns`
* `non_fmt_panic` => `non_fmt_panics`
Lints that are renamed but don't require any back -compat work since they aren't yet in stable:
* `future_prelude_collision` => `rust_2021_prelude_collisions`
* `reserved_prefix` => `rust_2021_token_prefixes`
Lints that have been discussed but that I did not rename:
* ~`non_fmt_panic` and `bare_trait_object`: is making this plural worth the headache we might cause users?~
* `array_into_iter`: I'm unsure of a good name and whether bothering users with a name change is worth it.
r? `@nikomatsakis`
Refactor linker code
This merges `LinkerInfo` into `CrateInfo` as there is no reason to keep them separate. `LinkerInfo::to_linker` is merged into `get_linker` as both have different logic for each linker type and `to_linker` is directly called after `get_linker`. Also contains a couple of small cleanups.
See the individual commits for all changes.
The only change here is a fix for `sys.platform` on Linux. Python 3.3
changed the API to return "linux" instead of "linux2"/"linux3", so this
commit uses `.startswith("python")` to make the code work on Python 3
without breaking Python 2.
Replace per-target ABI denylist with an allowlist
It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.
This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.
In this PR we got rid of the per-target ABI denylists, and instead compute
which ABIs are supported with a simple match based on, mostly, the
`Target::arch` field. Among other things, this makes it impossible to
forget to consider this problem (in either direction) and forces one to
consider what the ABI support looks like when adding an ABI (rarely)
rather than target (often), which should hopefully also reduce the
cognitive load on both contributors as well as reviewers.
Fixes#57182
Sponsored by: standard.ai
---
## Summary for teams
One significant user-facing change after this PR is that there's now a future compat warning when building…
* `stdcall`, `fastcall`, `thiscall` using code with targets other than 32-bit x86 (i386...i686) or *-windows-*;
* `vectorcall` using code when building for targets other than x86 (either 32 or 64 bit) or *-windows-*.
Previously these ABIs have been accepted much more broadly, even for architectures and targets where this made no sense (e.g. on wasm32) and would fall back to the C ABI. In practice this doesn't seem to be used too widely and the [breakages in crater](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) that we see are mostly about Windows-specific code that was missing relevant `cfg`s and just happened to successfully `check` on Linux for one reason or another.
The intention is that this warning becomes a hard error after some time.
It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.
This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.
Fixes#57182
Sponsored by: standard.ai
rustdoc: Replace `FakeDefId` with new `ItemId` type
Follow up from #84707
`@Manishearth` [suggested](https://github.com/rust-lang/rust/pull/84707#issuecomment-831994669) that there should be a new `ItemId` type that can distinguish between auto traits, normal ids, and blanket impls instead of using `FakeDefId`s.
This type is introduced by this PR.
There are still some `FIXME`s left, because I was unsure what the best solution for them would be.
Especially the naming in general now is a bit weird right now and needs to be cleaned up. Now there are no "fake" ids so the `is_fake` method on `Item` does not really make sense and maybe the methods on `ItemId` should be renamed too?
Also, we need to represent the new item ids in the JSON backend somehow.
Remove `impl Clean for {Ident, Symbol}`
These were only used once, in a place where it was trivial to replace.
Also, it's unclear what 'clean' would mean for these, so it seems better
to be explicit.
Found while reviewing https://github.com/rust-lang/rust/pull/86841, which makes the same change to `build_macro`, so the two will conflict.
r? `@GuillaumeGomez`
Query-ify global limit attribute handling
Currently, we read various 'global limits' from inner attributes the crate root (`recursion_limit`, `move_size_limit`, `type_length_limit`, `const_eval_limit`). These limits are then stored in `Sessions`, allowing them to be access from a `TyCtxt` without registering a dependency on the crate root attributes.
This PR moves the calculation of these global limits behind queries, so that we properly track dependencies on crate root attributes. During the setup of macro expansion (before we've created a `TyCtxt`), we need to access the recursion limit, which is now done by directly calling into the code shared by the normal query implementations.
These were only used once, in a place where it was trivial to replace.
Also, it's unclear what 'clean' would mean for these, so it seems better
to be explicit.
Bump deps
tidy: updated cargo_metadata to 0.12 (rustfmt only one left, that depends on 0.8 version in tree, waiting when it merges into rustc repo)
miow v0.3.6 -> v0.3.7, drops socket2 v0.3.19
curl v0.4.36 -> v0.4.38
curl-sys v0.4.42+curl-7.76.0 -> v0.4.44+curl-7.77.0
fixes CVE's https://curl.se/docs/vuln-7.76.0.html
Make x.py less verbose on failures
- Don't print the exact command run by rustbuild unless `--verbose` is set.
This is almost always unhelpful, since it's just cargo with a lot of
arguments (and you can't replicate it anyway unless you have the environment variables, which aren't printed by default).
- Don't print "Build completed unsuccessfully" unless --verbose is set.
You can already tell the build failed by the errors above, and the
time isn't particularly helpful.
- Don't print the full path to bootstrap. This is useless to everyone,
even including when working on x.py itself. You can still opt-in to
this being shown with `--verbose`, since it will throw an exception.
Before:
```
error[E0432]: unresolved import `x`
--> library/std/src/lib.rs:343:5
|
343 | use x;
| ^ no external crate `x`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `std`
To learn more, run the command again with --verbose.
command did not execute successfully: "/home/joshua/rustc4/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/home/joshua/rustc4/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit status: 101
failed to run: /home/joshua/rustc4/build/bootstrap/debug/bootstrap check
Build completed unsuccessfully in 0:00:13
```
After:
```
error[E0432]: unresolved import `x`
--> library/std/src/lib.rs:343:5
|
343 | use x;
| ^ no external crate `x`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `std`
To learn more, run the command again with --verbose.
```
cc https://github.com/rust-lang/rust/issues/86854, https://github.com/rust-lang/rust/pull/86022
r? `@Mark-Simulacrum`
Add check to ensure error code explanations are not removed anymore even if not emitted
The error explanations are useful in case you use older version of the compiler. Even more if they had an explanation. If they are not emitted, their explanations should be updated but not removed (as we did for a few of them, like E0001).
r? `@Mark-Simulacrum`
Hack: Ignore inference variables in certain queries
Fixes#84841Fixes#86753
Some queries are not built to accept types with inference variables, which can lead to ICEs. These queries probably ought to be converted to canonical form, but as a quick workaround, we can return conservative results in the case that inference variables are found.
We should file a follow-up issue (and update the FIXMEs...) to do the proper refactoring.
cc `@arora-aman`
r? `@oli-obk`
core: add unstable no_fp_fmt_parse to disable float formatting code
In some projects (e.g. kernel), floating point is forbidden. They can disable
hardware floating point support and use `+soft-float` to avoid fp instructions
from being generated, but as libcore contains the formatting code for `f32`
and `f64`, some fp intrinsics are depended. One could define stubs for these
intrinsics that just panic [1], but it means that if any formatting functions
are accidentally used, mistake can only be caught during the runtime rather
than during compile-time or link-time, and they consume a lot of space without
LTO.
This patch provides an unstable cfg `no_fp_fmt_parse` to disable these.
A panicking stub is still provided for the `Debug` implementation (unfortunately)
because there are some SIMD types that use `#[derive(Debug)]`.
[1]: https://lkml.org/lkml/2021/4/14/1028
Support allocation failures when interpreting MIR
This closes#79601 by handling the case where memory allocation fails during MIR interpretation, and translates that failure into an `InterpError`. The error message is "tried to allocate more memory than available to compiler" to make it clear that the memory shortage is happening at compile-time by the compiler itself, and that it is not a runtime issue.
Now that memory allocation can fail, it would be neat if Miri could simulate low-memory devices to make it easy to see how much memory a Rust program needs.
Note that this breaks Miri because it assumes that allocation can never fail.
Warn when `rustdoc::` group is omitted from lint names
When rustdoc lints were first made a tool lint, they gave an unconditional warning when you used the original name:
```
warning: lint `broken_intra_doc_links` has been renamed to `rustdoc::broken_intra_doc_links`
--> $DIR/renamed-lint-still-applies.rs:2:9
|
LL | #![deny(broken_intra_doc_links)]
| ^^^^^^^^^^^^^^^^^^^^^^ help: use the new name: `rustdoc::broken_intra_doc_links`
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
```
That was reverted in https://github.com/rust-lang/rust/pull/83203 because adding `rustdoc::x` lints would cause the code to break on old versions of the compiler (due to https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, "fixed" in https://github.com/rust-lang/rust/pull/83216 in the sense that you can now opt-in to not breaking on nightly, which is not ideal but `register_tool` is a long way from stabilizing). Since https://github.com/rust-lang/rust/pull/80527 is now on 1.52.0 stable, we can re-enable the warning. For nightly users, they can change immediately and still have their code work on stable; for stable users, they can change their code in 12 weeks and still have it work up to 3 releases back (about 18 weeks). That seems reasonable to me.
r? `@Manishearth` cc `@rust-lang/rustdoc`
Remove the deprecated `core::raw` and `std::raw` module.
A few months has passed since #84207. I think now it's time for the final removal.
Closes#27751.
r? `@m-ou-se`
- Don't print the exact command run by rustbuild unless `--verbose` is set.
This is almost always unhelpful, since it's just cargo with a lot of
arguments.
- Don't print "Build completed unsuccessfully" unless --verbose is set.
You can already tell the build failed by the errors above, and the
time isn't particularly helpful.
- Don't print the full path to bootstrap. This is useless to everyone,
even including when working on x.py itself. You can still opt-in to
this being shown with `--verbose`, since it will throw an exception.
Before:
```
error[E0432]: unresolved import `x`
--> library/std/src/lib.rs:343:5
|
343 | use x;
| ^ no external crate `x`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `std`
To learn more, run the command again with --verbose.
command did not execute successfully: "/home/joshua/rustc4/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/home/joshua/rustc4/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit status: 101
failed to run: /home/joshua/rustc4/build/bootstrap/debug/bootstrap check
Build completed unsuccessfully in 0:00:13
```
After:
```
error[E0432]: unresolved import `x`
--> library/std/src/lib.rs:343:5
|
343 | use x;
| ^ no external crate `x`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0432`.
error: could not compile `std`
To learn more, run the command again with --verbose.
```
Return `EvaluatedToOk` when type in outlives predicate is global
A global type doesn't reference any local regions or types, so it's
guaranteed to outlive any region.
Update cargo
5 commits in 4952979031e2cf1d901c817a32e25a156a19db4c..3ebb5f15a940810f250b68821149387af583a79e
2021-07-01 01:14:50 +0000 to 2021-07-02 20:35:38 +0000
- Adjust the edition2021 resolver diff report. (rust-lang/cargo#9649)
- Include the linker in the fingerprint. (rust-lang/cargo#9647)
- Temporarily disable windows env test. (rust-lang/cargo#9646)
- Handle git deleted files with dirty worktree. (rust-lang/cargo#9645)
- Adjust error message with offline and frozen. (rust-lang/cargo#9644)
deny using default function in impl const Trait
Fixes#79450.
I don't know if my implementation is correct:
- The check is in `rustc_passes::check_const`, should I put it somewhere else instead?
- Is my approach (to checking the impl) optimal? It works for the current tests, but it might have some issues or there might be a better way of doing this.
Fix const-generics ICE related to binding
Fixes#83765, fixes#85848
r? `@jackh726` as you're familiar with `Binding`. I'd like to get some views if the current approach is right path.
Previously, only the fields would be displayed with no indication of the
variant name. If you already knew the enum was univariant, this was ok
but if the enum was univariant because of layout, for example, a
`Result<T, !>` then it could be very confusing which variant was the
active one.
Prior to this, we only showed the `[variant]` synthetic property when
the dataful variant is active. With this change, we now always show it
so the behavior is consistent.
Previously, directly tagged enums had a `variant$` field which would
show the name of the active variant. We now show the variant using a
`[variant]` synthetic item just like we do for niche-layout enums.
In some projects (e.g. kernel), floating point is forbidden. They can disable
hardware floating point support and use `+soft-float` to avoid fp instructions
from being generated, but as libcore contains the formatting code for `f32`
and `f64`, some fp intrinsics are depended. One could define stubs for these
intrinsics that just panic [1], but it means that if any formatting functions
are accidentally used, mistake can only be caught during the runtime rather
than during compile-time or link-time, and they consume a lot of space without
LTO.
This patch provides an unstable cfg `no_fp_fmt_parse` to disable these.
A panicking stub is still provided for the `Debug` implementation (unfortunately)
because there are some SIMD types that use `#[derive(Debug)]`.
[1]: https://lkml.org/lkml/2021/4/14/1028
Rollup of 7 pull requests
Successful merges:
- #84029 (add `track_path::path` fn for usage in `proc_macro`s)
- #85001 (Merge `sys_common::bytestring` back into `os_str_bytes`)
- #86308 (Docs: clarify that certain intrinsics are not unsafe)
- #86796 (Add a regression test for issue-70703)
- #86803 (Remove & from Command::args calls in documentation)
- #86807 (Fix double import in wasm thread )
- #86813 (Add a help message to `unused_doc_comments` lint)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add a help message to `unused_doc_comments` lint
Fixes#83492
This adds a help message to suggest a plain comment like the E0658 error. I've yet to come up with the best message about the doc attribute but the current shouldn't harm anything.
I was thinking of recovering in the `doc_comment_between_if_else` case, but I came to the conclusion that it unlikely happened and was an overkill.
add `track_path::path` fn for usage in `proc_macro`s
Adds a way to declare a dependency on external files without including them, to either re-trigger the build of a file as well as covering the use case of including dependencies within the `rustc` invocation, such that tools like `sccache`/`cachepot` are able to handle references to external files which are not included.
Ref #73921
Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger
There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types).
Instead, each debug symbol name should be unique and useful:
* Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified.
* Qualify the principal trait for dynamic types.
* If there is no principal trait for a dynamic type, emit all other traits instead.
* Respect the `qualified` argument when emitting ref and pointer types.
* For implementations, emit the disambiguator.
* Print const generics when emitting generic parameters or arguments.
Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly:
* Avoid characters with special meaning (`#`, `[`, `"`, `+`).
* Never start a name with `<` or `{` as this is treated as an operator.
* `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this).
* Emit function declarations using C/C++ style syntax (e.g., leading return type).
* Emit arrays as a synthetic `array$<type, size>` type.
* Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
Document rustfmt on nightly-rustc
- Refactor the doc step for Rustdoc into a macro
- Call the macro for both rustdoc and rustfmt
- Add a `recursion_limit` macro to avoid overflow errors
This does not currently pass --document-private-items for rustfmt due to https://github.com/rust-lang/cargo/pull/8422#issuecomment-871082935.
r? `@Mark-Simulacrum` cc `@calebcartwright`
Revert "Don't load all extern crates unconditionally"
Fixes https://github.com/rust-lang/rust/issues/84738.
This reverts https://github.com/rust-lang/rust/pull/83738.
For the "smart" load of external crates, we need to be able to access their items in order to check their doc comments, which seems, if not impossible, quite complicated using only the AST.
For some context, I first tried to extend the `IntraLinkCrateLoader` visitor by adding `visit_foreign_item`. Unfortunately, it never enters into this call, so definitely not the right place...
I then added `visit_use_tree` to then check all the imports outside with something like this:
```rust
let mut loader = crate::passes::collect_intra_doc_links::IntraLinkCrateLoader::new(resolver);
ast::visit::walk_crate(&mut loader, krate);
let mut items = Vec::new();
for import in &loader.imports_to_check {
if let Some(item) = krate.items.iter().find(|i| i.id == *import) {
items.push(item);
}
}
for item in items {
ast::visit::walk_item(&mut item);
for attr in &item.attrs {
loader.check_attribute(attr);
}
}
```
This was, of course, a failure. We find the items without problems, but we still can't go into the external crate to check its items' attributes.
Finally, `@jyn514` suggested to look into the [`CrateLoader`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/creader/struct.CrateLoader.html), but it only seems to provide metadata (I went through [`CStore`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/creader/struct.CStore.html) and [`CrateMetadata`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/decoder/struct.CrateMetadata.html)).
I think we are too limited here (with AST only) to be able to determine the crates we actually need to import, but it's very likely that I missed something. Maybe `@petrochenkov` or `@Aaron1011` have an idea?
So until we find a way to make it work completely, we need to revert it to fix the ICE. Once merged, we'll need to re-open #68427.
r? `@jyn514`
Redefine `ErrorKind::Other` and stop using it in std.
This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only*, and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change, since the user couldn't match on these errors anyway. This way, we use the `#[non_exhaustive]` property of the enum in a more effective way.
Open questions:
- How do we check this change doesn't cause too much breakage? Will a crate run help and be enough?
- How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`.
cc https://github.com/rust-lang/rust/pull/79965
cc `@rust-lang/libs` `@ijackson`
r? `@dtolnay`
The recursion_limit attribute avoids the following error:
```
error[E0275]: overflow evaluating the requirement `std::ptr::Unique<rustc_ast::Pat>: std::marker::Send`
|
= help: consider adding a `#![recursion_limit="256"]` attribute to your crate (`rustfmt_nightly`)
```
Test for const trait impls behind feature gates
- Make the previous cross-crate tests use revisions instead of being separate files
- Added test for gating const trait impls.
cc ``@oli-obk`` ``@jonas-schievink``
fix(rustdoc): generics search
This commit adds a test case for generics, re-adds generics data
to the search index, and tweaks function indexing to use less space in JSON.
This partially reverts commit 14ca89446c.
Check the number of generic lifetime and const parameters of intrinsics
This pull request fixes#85855. The current code for type checking intrinsics only checks the number of generic _type_ parameters, but does not check for an incorrect number of lifetime or const parameters, which can cause problems later on, such as the ICE in #85855, where the code thought that it was looking at a type parameter but found a lifetime parameter:
```
error: internal compiler error: compiler/rustc_middle/src/ty/generics.rs:188:18:
expected type parameter, but found another generic parameter
```
The changes in this PR add checks for the number of lifetime and const parameters, expand the scope of `E0094` to also apply to these cases, and improve the error message by properly pluralizing the number of expected generic parameters.
Also an fix issue with tuple type names where we can't cast to them in
natvis (required by the visualizer for `HashMap`) because of
peculiarities with the natvis expression evaluator.
This commit adds a test case for generics, re-adds generics data
to the search index, and tweaks function indexing to use less space in JSON.
This reverts commit 14ca89446c.
Update cargo
9 commits in 9233aa06c801801cff75df65df718d70905a235e..4952979031e2cf1d901c817a32e25a156a19db4c
2021-06-22 21:32:55 +0000 to 2021-07-01 01:14:50 +0000
- Fix `BorrowMutError` when calling `cargo doc --open` (rust-lang/cargo#9531)
- Exclude `target` from content-indexing on Windows (rust-lang/cargo#9635)
- Temporarily ignore 2021 edition fix. (rust-lang/cargo#9642)
- Temporarily disable future_incompat tests. (rust-lang/cargo#9638)
- Include toolchain specification in error message (rust-lang/cargo#9625)
- Error when packaging with git dependencies without version (rust-lang/cargo#9612)
- simply 'if' block (rust-lang/cargo#9615)
- tidy some closures and iterators (rust-lang/cargo#9614)
- use 'writeln' instead of appending newline character (rust-lang/cargo#9620)
Enable the tests developed with #86594
This PR requires `browser-ui-test@0.4.1`. Can we centralise the version number somehow and maybe automatically install it when tests are run?
r? `@GuillaumeGomez`
Fix misleading "impl Trait" error
The kinds can't be compared directly, as types with references are treated as different because the lifetimes aren't bound in ty, but are in expected.
Closes#84160
Add support for leaf function frame pointer elimination
This PR adds ability for the target specifications to specify frame
pointer emission type that's not just “always” or “whatever cg decides”.
In particular there's a new mode that allows omission of the frame
pointer for leaf functions (those that don't call any other functions).
We then set this new mode for Aarch64-based Apple targets.
Fixes#86196
Fix ICE when `main` is declared in an `extern` block
Changes in #84401 to implement `imported_main` changed how the crate entry point is found, and a declared `main` in an `extern` block was detected erroneously. This was causing the ICE described in #86110.
This PR adds a check for this case and emits an error instead. Previously a `main` declaration in an `extern` block was not detected as an entry point at all, so emitting an error shouldn't break anything that worked previously. In 1.52.1 stable this is demonstrated, with a `` `main` function not found`` error.
Fixes#86110
Test cross-crate usage of `feature(const_trait_impl)`
This PR does two things:
- Fixes metadata not encoded properly for functions in const trait impls.
- Adds tests for using const trait impls cross-crate with the feature gate on the user crate either enabled or disabled.
AFAIK, this means we can now constify some trait impls in the standard library 🎉
See #67792 for the tracking issue, cc `@oli-obk`
Fix rustdoc query type filter
I realized while reviewing #86659 that the type filter was broken on search so I'd prefer it to get merged before merging #86659.
r? `@notriddle`
copy rust-lld as ld in dist
Fixes bug in https://github.com/rust-lang/rust/pull/85961. Linking seems to work for pure Rust projects, but not when a C library needs to be dynamically linked.
Check node kind to avoid ICE in `check_expr_return()`
This PR fixes#86721. The ICE described there is apparently due to a misunderstanding:
e98897e5dc/compiler/rustc_typeck/src/check/expr.rs (L684-L685)
Intuitively, one would think that calling `expect_item()` after `get_parent_item()` should succeed, but as it turns out, `get_parent_item()` can also return foreign, trait, and impl items as well as crates, whereas `expect_item()` specifically expects a `Node::Item`. I have therefore added an extra check to prevent this ICE.
There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types).
Instead, each debug symbol name should be unique and useful:
* Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified.
* Qualify the principal trait for dynamic types.
* If there is no principal trait for a dynamic type, emit all other traits instead.
* Respect the `qualified` argument when emitting ref and pointer types.
* For implementations, emit the disambiguator.
* Print const generics when emitting generic parameters or arguments.
Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly:
* Avoid characters with special meaning (`#`, `[`, `"`, `+`).
* Never start a name with `<` or `{` as this is treated as an operator.
* `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this).
* Emit function declarations using C/C++ style syntax (e.g., leading return type).
* Emit arrays as a synthetic `array$<type, size>` type.
* Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
This PR adds ability for the target specifications to specify frame
pointer emission type that's not just “always” or “whatever cg decides”.
In particular there's a new mode that allows omission of the frame
pointer for leaf functions (those that don't call any other functions).
We then set this new mode for Aarch64-based Apple targets.
Fixes#86196
