There is a minor [breaking-change] for lint authors - some functions which were previously defined on `lint::Context` have moved to a trait - `LintContext`, you may need to import that trait to avoid name resolution errors.

Fixes #28431

r? @Manishearth 

This is a work in progress.

Fixes #28431

This was pointed out by @filsmick and @swatteau in #28412.

Closes #23036.

r? @steveklabnik 

This could be a [breaking-change] if your lint or syntax extension (is that even possible?) uses HIR attributes or literals.

This could be a [breaking-change] if your lint or syntax extension (is that even possible?) uses HIR attributes or literals.

I'd love to have any tips about highlights and lang stuff I missed. Sadly, this needs to be merged *tomorrow*.

[Rendered](https://github.com/brson/rust/blob/relnotes/RELEASES.md)

Contributing to the Rust error explanations. Should I also add a better error for it by default?

clean a few things discovered during my split_ty work

r? @EddyB 

Closes #23036.

…e len is actually one more than the length of argv[0]. However, this is precarious and should probably be replaced with more robust logic.

This was missing from https://github.com/rust-lang/rust/pull/27451

r? @EddyB 

new error style:
```
path.rs:4:6: 4:7 error: the trait `core::marker::Sized` is not implemented for the type `[u8]` [E0277]
path.rs:4 fn f(p: Path) {}
               ^
path.rs:4:6: 4:7 help: run `rustc --explain E0277` to see a detailed explanation
path.rs:4:6: 4:7 note: `[u8]` does not have a constant size known at compile-time
path.rs:4:6: 4:7 note: required because it appears within the type `std::sys::os_str::Slice`
path.rs:4:6: 4:7 note: required because it appears within the type `std::ffi::os_str::OsStr`
path.rs:4:6: 4:7 note: required because it appears within the type `std::path::Path`
path.rs:4:6: 4:7 note: all local variables must have a statically known size
path.rs:7:5: 7:36 error: the trait `core::marker::Send` is not implemented for the type `alloc::rc::Rc<()>` [E0277]
path.rs:7     foo::<BTreeMap<Rc<()>, Rc<()>>>();
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
path.rs:7:5: 7:36 help: run `rustc --explain E0277` to see a detailed explanation
path.rs:7:5: 7:36 note: `alloc::rc::Rc<()>` cannot be sent between threads safely
path.rs:7:5: 7:36 note: required because it appears within the type `collections::btree::node::Node<alloc::rc::Rc<()>, alloc::rc::Rc<()>>`
path.rs:7:5: 7:36 note: required because it appears within the type `collections::btree::map::BTreeMap<alloc::rc::Rc<()>, alloc::rc::Rc<()>>`
path.rs:7:5: 7:36 note: required by `foo`
error: aborting due to 2 previous errors
```

Fixes #21793 
Fixes #23286

r? @nikomatsakis 

Closes https://github.com/rust-lang/rust/issues/26082

Fixes #28344

The second commit in this PR will stop printing the macro definition site in backtraces, which cuts their length in half and increases readability (the definition site was only correct for local macros).

The third commit will not print an invocation if the last one printed occurred at the same place (span). This will make backtraces caused by a self-recursive macro much shorter.

(A possible alternative would be to capture the backtrace first, then limit it to a few frames at the start and end of the chain and print `...` inbetween. This would also work with multiple macros calling each other, which is not addressed by this PR - although the backtrace will still be halved)

Example:
```rust
macro_rules! m {
 ( 0 $($t:tt)* ) => ( m!($($t)*); );
 () => ( fn main() {0} );
}

m!(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0);
```

On a semi-recent nightly, this yields:
```
test.rs:3:21: 3:22 error: mismatched types:
 expected `()`,
    found `_`
(expected (),
    found integral variable) [E0308]
test.rs:3  () => ( fn main() {0} );
                              ^
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:2:23: 2:34 note: expansion site
test.rs:1:1: 4:2 note: in expansion of m!
test.rs:6:1: 6:35 note: expansion site
test.rs:3:21: 3:22 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
```

After this patch:
```
test.rs:3:21: 3:22 error: mismatched types:
 expected `()`,
    found `_`
(expected (),
    found integral variable) [E0308]
test.rs:3  () => ( fn main() {0} );
                              ^
test.rs:2:23: 2:34 note: in this expansion of m!
test.rs:6:1: 6:35 note: in this expansion of m!
test.rs:3:21: 3:22 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
```

That file got way too big for its own good. It could be split more - this is just a start.

r? @nikomatsakis 

This patch transforms functions of the form
```
fn f<Generic: AsRef<Concrete>>(arg: Generic) {
	let arg: &Concrete = arg.as_ref();
	// Code using arg
}
```
to the next form:
```
#[inline]
fn f<Generic: AsRef<Concrete>>(arg: Generic) {
	fn f_inner(arg: &Concrete) {
		// Code using arg
	}
	
	f_inner(arg.as_ref());
}
```

Therefore, most of the code is concrete and not duplicated during monomorphisation (unless inlined)
and only the tiny bit of conversion code is duplicated. This method was mentioned by @aturon in the
Conversion Traits RFC (https://github.com/rust-lang/rfcs/blame/master/text/0529-conversion-traits.md#L249) and similar techniques are not uncommon in C++ template libraries.

This patch goes to the extremes and applies the transformation even to smaller functions<sup>1</sup>
for purity of the experiment. *Some of them can be rolled back* if considered too ridiculous.

<sup>1</sup> However who knows how small are these functions are after inlining and everything.

The functions in question are mostly `fs`/`os` functions and not used especially often with variety
of argument types, so the code size reduction is rather small (but consistent). Here are the sizes
of stage2 artifacts before and after the patch:
https://gist.github.com/petrochenkov/e76a6b280f382da13c5d
https://gist.github.com/petrochenkov/6cc28727d5256dbdfed0

Note:
All the `inner` functions are concrete and unavailable for cross-crate inlining, some of them may
need `#[inline]` annotations in the future.

r? @aturon

Remove a needless memset(). It's okay that we don't append NUL because len is actually one more than the length of argv[0]. However, this is precarious and should probably be replaced with more robust logic.

there is no need for 3 versions of the function

as per #28243.

Windows's scheduler apparently has "problems" unblocking calls in the
asked for time period.

Windows's scheduler apparently has "problems" unblocking calls in the
asked for time period.

Overflows in integer pow() computations would be missed if they
preceded a 0 bit of the exponent being processed. This made
calls such as 2i32.pow(1024) not trigger an overflow.

Fixes #28012