Allow crate:: in local paths
Currently if you want to use `crate` locally you have to do `::crate::`. This shouldn't be necessary
(will fix up tests later)
r? @petrochenkov
… rather than the module’s.
Remove code definition of the Error trait from its doc-comment
It was out of date, and rustdoc already shows the same information.
Add a default impl for Error::description and document it as deprecated.
It is redundant with Display while being much less flexible for implementors.
This is only a "soft" deprecation: it is not worth the hassle of a warning to existing users.
Tweak Error trait docs to reflect actual requirements
Introduce compile-pass
r? @alexcrichton
The plan is to move things that cannot fail (no assert, unwrap, etc) out so we don't have to run them, and in the long term we can also stop running LLVM for them.
Out of 3215 tests...
```
Language Files Lines Code Comments Blanks
Rust 3215 119254 64688 35135 19431
```
16% of them has an empty main (which is already moved in this PR).
```
grep -rnPzl 'fn main\(\)\s*{\s*}' | xargs rg --files-without-match cfg | wc -l
547
```
And only 50% of the tests contains assertions:
```
rg -e assert -e unwrap -e expect -e panic -l | wc -l
1600
```
The remainder is likely able to get moved, but they need check by a human so I didn't touch them in PR.
cc @rust-lang/compiler
* [ ] Update documentation
Edition breakage lint for absolute paths starting with modules
We plan to enable `extern_absolute_paths` in the 2018 edition. To allow for that, folks must transition their paths in a previous edition to the new one. This makes paths which import module contents via `use module::` or `::module::` obsolete, and we must edition-lint these.
https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205?u=manishearth is the current plan for paths.
r? @nikomatsakis
Fixes#48722
As of now, Box only contains a Unique pointer, so this is the sole
argument to box_free. Consequently, we remove the code supporting
the previous box_free signature. We however keep the old definition
for bootstrapping purpose.
Provide better names for builtin deriving-generated attributes
First attempt at fixing #49967
Not in love with any choices here, don't be shy if you aren't happy with anything :)
I've tested that this produces nicer names in documentation, and that it no longer has issues conflicting with constants with the same name. (I guess we _could_ make a test for that... unsure if that would be valuable)
In all cases I took the names from the methods as declared in the relevant trait.
In some cases I had to prepend the names with _ otherwise there were errors about un-used variables. I'm uneasy with the inconsistency... do they all need to be like that? Is there a way to generate an alternate impl or use a different name (`_`?) in the cases where the arguments are not used?
Lastly the gensym addition to Ident I implemented largely as suggested, but I want to point out it's a little circuitous (at least, as far as I understand it). `cx.ident_of(name)` is just `Ident::from_str`, so we create an Ident then another Ident from it. `Ident::with_empty_ctxt(Symbol::gensym(string))` may or may not be equivalent, I don't know if it's important to intern it _then_ gensym it. It seems like either we could use that, or if we do want a new method to make this convenient, it could be on Ident instead (`from_str_gensymed`?)
A comment already stated that this test should be disabled, but its
`should_fail` is not enough to excuse it from a compiler panic. Remove
it from the `revisions` list to disable it harder.
Android abstract unix domain sockets AddressKind correction
The prior check causes abstract unix domain sockets to return AddressKind::Unnamed instead of AddressKind::Abstract on Android.
Other than the immediately proceeding comment "macOS seems to return a len of 16 and a zeroed sun_path for unnamed addresses" the check as-implemented does not seem to have alternative explanation. I couldn't find an alternative explanation while stepping though git blame. I suspect the AddressKind::Unnamed nonzero check should instead be if macos, length 16, and zeroed array. @sfackler could you comment on this, the code as-is is the same from your initial addition of abstract uds support.
