Check that executable file is in-tree before failing tidy check
I silenced stdout and stderr for ls-files, not sure if that's appropriate (is `make tidy` intended to give debugging information)? Otherwise it prints each file it find to stdout/stderr, which currently prints nothing (only executable files are checked).
I have not done major testing regarding the behavior of ls-files when the file is ignored, but judging by the man page everything should be fine.
I've duplicated the code which makes the path git-friendly from the `Cargo.lock` checking code; I can extract that into a common helper if wanted (it's only two lines).
Fixes#35689.
Carrier trait (third attempt)
This adds a `Carrier` trait to operate with `?`. The only public implementation is for `Result`, so effectively the trait does not exist, however, it ensures future compatibility for the `?` operator. This is not intended to be used, nor is it intended to be a long-term solution.
Although this exact PR has not been through Crater, I do not expect it to be a breaking change based on putting numerous similar PRs though Crater in the past.
cc:
* [? tracking issue](https://github.com/rust-lang/rust/issues/31436)
* [previous PR](https://github.com/rust-lang/rust/pull/35056)
* [RFC issue](https://github.com/rust-lang/rfcs/issues/1718) for discussion of long-term Carrier trait solutions.
r? @nikomatsakis
Wording fixes in error messages
This PR is largely wording fixes to existing PRs that I found going back through the ones that have already been updated. Sometimes seeing the message in context made me think "oh there's a better wording!"
There's one additional fix. This will also prevent the secondary underlining of derive call (since they look like macros to the system in the way I was using):
```
error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
--> src/test/compile-fail/E0184.rs:11:10
|
11 | #[derive(Copy)] //~ ERROR E0184
| ^^^^
| |
| in this macro invocation
```
Is now just:
```
error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
--> src/test/compile-fail/E0184.rs:11:10
|
11 | #[derive(Copy)] //~ ERROR E0184
| ^^^^
```
Add workaround to detect correct compiler version
This adds a workaround which fixes a rustbuild issue where the wrong compiler is checked for the version number. The bug would arise if you build the system correctly then changed to any other version (eg doing a `git pull`). After changing to the new version, building would fail and complain that crates were built with the wrong compiler.
There are actually two compilers at play, the bootstrapping compiler (called the "snapshot" compiler) and the actual compiler being built (the "real" compiler). In the case of this issue, the wrong compiler was being checked for version mismatch.
r? @alexcrichton
replace `Add` example with something more evocative of addition
Currently most of the operator traits use trivial implementation
examples that only perform side effects. Honestly, that might not be too
bad for the sake of documentation; but anyway, here's a proposal to move
a slightly modified version of the module-level point-addition example
into the `Add` documentation, since it's more evocative of addition
semantics.
Part of #29365
rustdoc: remove the `!` from macro URLs and titles
Because the `!` is part of a macro use, not the macro's name. E.g., you write `macro_rules! foo` not `macro_rules! foo!`, also `#[macro_import(foo)]`.
(Pulled out of #35020).
Specific error message for missplaced doc comments
Identify when documetation comments have been missplaced in the following places:
* After a struct element:
```rust
// file.rs:
struct X {
a: u8 /** document a */,
}
```
```bash
$ rustc file.rs
file.rs:2:11: 2:28 error: found documentation comment that doesn't
document anything
file.rs:2 a: u8 /** document a */,
^~~~~~~~~~~~~~~~~
file.rs:2:11: 2:28 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
* As the last line of a struct:
```rust
// file.rs:
struct X {
a: u8,
/// incorrect documentation
}
```
```bash
$ rustc file.rs
file.rs:3:5: 3:27 error: found a documentation comment that doesn't
document anything
file.rs:3 /// incorrect documentation
^~~~~~~~~~~~~~~~~~~~~~
file.rs:3:5: 3:27 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
* As the last line of a `fn`:
```rust
// file.rs:
fn main() {
let x = 1;
/// incorrect documentation
}
```
```bash
$ rustc file.rs
file.rs:3:5: 3:27 error: found a documentation comment that doesn't
document anything
file.rs:3 /// incorrect documentation
^~~~~~~~~~~~~~~~~~~~~~
file.rs:3:5: 3:27 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
Fix#27429, #30322
rustdoc: Fix a couple of issues with the search results
* Fix links to static items in the search results.
* Don't include the path for primitive methods in the search results. Displaying `std::u32::max_value` is misleading so just display `u32::max_value`.
Part of #29365
explain that std::mem::drop in prelude will invoke Drop
change "prelude" -> "the prelude"; change links to reference-style
move link references to links' section
Restructure metadata encoder to track deps precisely
This issue restructures meta-data encoding to track dependencies very precisely. It uses a cute technique I hope to spread elsewhere, where we can guard the data flowing into a new dep-graph task and ensure that it is not "leaking" information from the outside, which would result in missing edges. There are no tests because we don't know of any bugs in the old system, but it's clear that there was leaked data.
The commit series is standalone, but the refactorings are kind of "windy". It's a good idea to read the comment in `src/librustc_metadata/index_builder.rs` to get a feeling for the overall strategy I was aiming at.
In several cases, I wound up adding some extra hashtable lookups, I think primarily for looking up `AdtDef` instances. We could remove these by implementing `DepGraphRead` for an `AdtDef` and then having it register a read to the adt-defs table, I guess, but I doubt it is really noticeable.
Eventually I think I'd like to extend this pattern to the dep-graph more generally, since it effectively guarantees that data cannot leak.
Fixes#35111.
r? @michaelwoerister
