Use true previous lint level when detecting overriden forbids
Previously, cap-lints was ignored when checking the previous forbid level, which
meant that it was a hard error to do so. This is different from the normal
behavior of lints, which are silenced by cap-lints; if the forbid would not take
effect regardless, there is not much point in complaining about the fact that we
are reducing its level.
It might be considered a bug that even `--cap-lints deny` would suffice to
silence the error on overriding forbid, depending on if one cares about failing
the build or precisely forbid being set. But setting cap-lints to deny is quite
odd and not really done in practice, so we don't try to handle it specially.
This also unifies the code paths for nested and same-level scopes. However, the
special case for CLI lint flags is left in place (introduced by #70918) to fix
the regression noted in #70819. That means that CLI flags do not lint on forbid
being overridden by a non-forbid level. It is unclear whether this is a bug or a
desirable feature, but it is certainly inconsistent. CLI flags are a
sufficiently different "type" of place though that this is deemed out of scope
for this commit.
r? `@pnkfelix` perhaps?
cc #77713 -- not marking as "Fixes" because of the lack of proper unused attribute handling in this PR
std::io: Use sendfile for UnixStream
`UnixStream` was forgotten in #75272 .
Benchmark yields the following results.
Before:
`running 1 test
test sys::unix::kernel_copy::tests::bench_file_to_uds_copy ... bench: 54,399 ns/iter (+/- 6,817) = 2409 MB/s`
After:
`running 1 test
test sys::unix::kernel_copy::tests::bench_file_to_uds_copy ... bench: 18,627 ns/iter (+/- 6,007) = 7036 MB/s`
Warn if `dsymutil` returns an error code
This checks the error code returned by `dsymutil` and warns if it failed. It
also provides the stdout and stderr logs from `dsymutil`, similar to the native
linker step.
I tried to think of ways to test this change, but so far I haven't found a good way, as you'd likely need to inject some nonsensical args into `dsymutil` to induce failure, which feels too artificial to me. Also, https://github.com/rust-lang/rust/issues/79361 suggests Rust is on the verge of disabling `dsymutil` by default, so perhaps it's okay for this change to be untested. In any case, I'm happy to add a test if someone sees a good approach.
Fixes https://github.com/rust-lang/rust/issues/78770
Add wasm32 support to inline asm
There is some contention around inline asm and wasm, and I really only made this to figure out the process of hacking on rustc, but I figured as long as the code existed, it was worth uploading.
cc `@Amanieu`
Respond to comments and start adding tests
Fix re-exports and extern-crate
Add expected output tests
Add restricted paths
Format
Fix: associated methods missing in output
Ignore stripped items
Mark stripped items
removing them creates dangling references
Fix tests and update conversions
Don't panic if JSON backend fails to create a file
Fix attribute error in JSON testsuite
Move rustdoc-json to rustdoc/
This way it doesn't have to build rustc twice. Eventually it should
probably get its own suite, like rustdoc-js, but that can be fixed in a
follow-up.
Small cleanups
Don't prettify json before printing
This fully halves the size of the emitted JSON.
Add comments
[BREAKING CHANGE] rename version -> crate_version
[BREAKING CHANGE] rename source -> span
Use exhaustive matches
Don't qualify imports for DefId
Rename clean::{ItemEnum -> ItemKind}, clean::Item::{inner -> kind}
Fix Visibility conversion
clean::Visability was changed here:
https://github.com/rust-lang/rust/pull/77820/files#diff-df9f90aae0b7769e1eb6ea6f1d73c1c3f649e1ac48a20e169662a8930eb427beL1467-R1509
More churn catchup
Format
Implement lazy decoding of DefPathTable during incremental compilation
PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However, it requires decoding the entire `DefPathTable` when incremental compilation is active, so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate.
This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active.
When we load the incremental cache and dep
graph, we need the ability to map a `DefPathHash` to a `DefId` in the
current compilation session (if the corresponding definition still
exists).
This is accomplished by storing the old `DefId` (that is, the `DefId`
from the previous compilation session) for each `DefPathHash` we need to
remap. Since a `DefPathHash` includes the owning crate, the old crate is
guaranteed to be the right one (if the definition still exists). We then
use the old `DefIndex` as an initial guess, which we validate by
comparing the expected and actual `DefPathHash`es. In most cases,
foreign crates will be completely unchanged, which means that we our
guess will be correct. If our guess is wrong, we fall back to decoding
the entire `DefPathTable` for the foreign crate. This still represents
an improvement over the status quo, since we can skip decoding the
entire `DefPathTable` for other crates (where all of our guesses were
correct).
Rollup of 11 pull requests
Successful merges:
- #79038 (Change ui test that are run-pass and that do not test the compiler to library tests)
- #79184 (Stop adding '*' at the end of slice and str typenames for MSVC case)
- #79227 (Remove const_fn_feature_flags test)
- #79444 (Move const ip in ui test to unit test)
- #79522 (Validate lint docs separately.)
- #79525 (Add -Z normalize-docs and enable it for compiler docs)
- #79527 (Move intra-doc link tests into a subdirectory)
- #79548 (Show since when a function is const in stdlib)
- #79568 (update Miri)
- #79573 (Update with status for various NetBSD ports.)
- #79583 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Update books
## nomicon
1 commits in 23c49f1d5ce4720bc5b7e3a920f47eccc8da6b63..d8383b65f7948c2ca19191b3b4bd709b403aaf45
2020-11-05 13:30:53 +0900 to 2020-11-22 10:24:42 -0500
- Clarify that any alignment is valid for ZSTs
## reference
5 commits in a7de763c213292f5b44bf10acb87ffa38724814d..a8afdca5d0715b2257b6f8b9a032fd4dd7dae855
2020-11-11 19:13:21 -0800 to 2020-11-30 06:44:46 -0800
- Describe relationship between reference and optimizers (rust-lang/reference#902)
- A simple missing space (rust-lang/reference#909)
- Cleanup formatting (rust-lang/reference#907)
- Use `doc`, not `test` for fn item inner attr example (rust-lang/reference#906)
- Update where our chat is. (rust-lang/reference#903)
## book
1 commits in 13e1c05420bca86ecc79e4ba5b6d02de9bd53c62..a190438d77d28041f24da4f6592e287fab073a61
2020-10-20 14:57:32 -0500 to 2020-11-16 10:44:08 -0600
- Change SipHash not found (404) link to SipHash in Wikipedia (rust-lang/book#2503)
## rust-by-example
4 commits in 1886fda6981b723e4de637074455558f8bc1e83c..236c734a2cb323541b3394f98682cb981b9ec086
2020-10-28 13:46:54 -0500 to 2020-11-30 14:05:49 -0300
- Update old invalid link (rust-lang/rust-by-example#1392)
- Moved "See also" link to the correct page. (rust-lang/rust-by-example#1389)
- Fix some markdown lint warnings (rust-lang/rust-by-example#1388)
- Minor grammar suggestion (rust-lang/rust-by-example#1386)
## embedded-book
1 commits in ca8169e69b479f615855d0eece7e318138fcfc00..ba34b8a968f9531d38c4dc4411d5568b7c076bfe
2020-10-15 15:06:35 +0000 to 2020-11-17 00:20:43 +0000
- Clarify CAS availability (rust-embedded/book#273)
Update with status for various NetBSD ports.
The NetBSD ports of rust to aarch64, armv7*, i686, and powerpc**
all both build and run. Status is as of rust 1.47.0.
*) Natively requires repeated successive build attempts (`rustc` is
such a resource pig VM-consumption-wise), or run in a chroot
on an aarch64 host where the available VM space is 4GB instead
of the native 2GB.
**) Powerpc either requires `-latomic` in a directory searched by
default by `ld` or to be built within pkgsrc which has a patch and
support package to tackle this issue.
Validate lint docs separately.
This addresses some concerns raised in https://github.com/rust-lang/rust/pull/76549#issuecomment-727638552 about errors with the lint docs being confusing and cumbersome. Errors from validating the lint documentation were being generated during `x.py doc` (and `x.py dist`), since extraction and validation are being done in a single step. This changes it so that extraction and validation are separated, so that `x.py doc` will not error if there is a validation problem, and tests are moved to `x.py test src/tools/lint-docs`.
This includes the following changes:
* Separate validation to `x.py test`.
* Added some more documentation on how to more easily modify and test the docs.
* Added more help to the error messages to hopefully provide more information on how to fix things.
The first commit just moves the code around, so you may consider looking at the other commits for a smaller diff.
Remove const_fn_feature_flags test
## Overview
Helps with #76268
I found `const_fn_feature_flags` is targeting feature-gate and remove it.
r? ``@matklad``
Stop adding '*' at the end of slice and str typenames for MSVC case
When computing debug info for MSVC debuggers, Rust compiler emits C++ style type names for compatibility with .natvis visualizers. All Ref types are treated as equivalences of C++ pointers in this process, and, as a result, their type names end with a '\*'. Since Slice and Str are treated as Ref by the compiler, their type names also end with a '\*'. This causes the .natvis engine for WinDbg fails to display data of Slice and Str objects. We addressed this problem simply by removing the '*' at the end of type names for Slice and Str types.
Debug info in WinDbg before the fix:
Debug info in WinDbg after the fix:
This change has also been tested with debuggers for Visual Studio, VS Code C++ and VS Code LLDB to make sure that it does not affect the behavior of other kinds of debugger.
Make keyboard interactions in the settings menu more pleasant
#78868 improved the keyboard interactions with the settings page. This PR goes a bit further by allowing more than just "space" to toggle the checkboxes.
r? `@jyn514`
Add built-in support for the armv5te-unknown-linux-uclibcgnueabi target
Hi!
I'd like to add built-in support for the `armv5te-unknown-linux-uclibcgnueabi` target. It's a pretty common target used by many devices like routers and IP cameras. It's mostly a copy-paste of `armv5te-unknown-linux-gnueabi`. I've tested it on a quite complex application that uses tokio, openssl and a lot of other stuff and everything seems to be working fine.
I'm not sure about the `post_link_args` but the point is that my linker fails when `-ldl` isn't specified. Maybe there is a better place where to put this option...
It's my first contribution to Rust itself, so feel free to wash my head 😄
_Note: The app mentioned above was built with this in my `.cargo/config`:_
```
[unstable]
build-std = ["core", "std", "alloc", "proc_macro", "panic_abort"]
build-std-features = ["panic_immediate_abort"]
```
More intra doc links
Helps with #75080.
I did a commit by group of file, I can squash if wanted.
`@rustbot` modify labels: T-doc, A-intra-doc-links
r? `@jyn514`
