https://github.com/rust-lang/rust/community currently shows that we have
no code of conduct. This will make it understand.
This is an exact copy of the page on the website.
Add warning to BufWriter documentation
When using `BufWriter`, it is very easy to unintentionally ignore errors, because errors which occur when flushing buffered data when the `BufWriter` is dropped are ignored. This has been noted in a couple places: #32677, #37045.
There has been some discussion about how to fix this problem in #32677, but no solution seems likely to land in the near future. For now, anyone who wishes to have robust error handling must remember to manually call `flush()` on a `BufWriter` before it is dropped. Until a permanent fix is in place, it seems worthwhile to add a warning to that effect to the documentation.
Add `isize` and `usize` constructors to Literal
This commit fills out the remaining integer literal constructors on the
`proc_macro::Literal` type with `isize` and `usize`. (I think these were just
left out by accident)
Implement Eq/Hash/Debug etc. for unsized tuples.
As I mentioned in [the comment in #18469](https://github.com/rust-lang/rust/issues/18469#issuecomment-306767422), the implementations of `PartialEq`, `Eq`, `PartialOrd`, `Ord`, `Debug`, `Hash` can be generalized to unsized tuples.
This is consistent with the `derive` behavior for unsized structs.
```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Debug, Default, Hash)]
struct MyTuple<X, Y, Z: ?Sized>(X, Y, Z);
fn f(x: &MyTuple<i32, i32, [i32]>) {
x == x;
x < x;
println!("{:?}", x);
}
```
Questions:
- Need an RFC?
- Need a feature gate? I don't think it does because the unsized tuple coercion #42527 is feature-gated.
- I changed `builder.field($name);` into `builder.field(&$name);` in the `Debug` implementation to pass compilation. This won't affect the behavior because `Debug for &'a T` is a mere redirection to `Debug for T`. However, I don't know if it affects code size / performance.
`rustc_on_unimplemented` supports referring to trait
Add support to `rustc_on_unimplemented` to reference the full path of
the annotated trait. For the following code:
```rust
pub mod Bar {
#[rustc_on_unimplemented = "test error `{Self}` with `{Bar}` `{Baz}` `{Quux}` in `{Foo}`"]
pub trait Foo<Bar, Baz, Quux> {}
}
```
the error message will be:
```
test error `std::string::String` with `u8` `_` `u32` in `Bar::Foo`
```
Note different versions of same crate when absolute paths of different types match.
The current check to address #22750 only works when the paths of the mismatched types relative to the current crate are equal, but this does not always work if one of the types is only included through an indirect dependency. If reexports are involved, the indirectly included path can e.g. [contain private modules](https://github.com/rust-lang/rust/issues/22750#issuecomment-302755516).
This PR takes care of these cases by also comparing the *absolute* path, which is equal if the type hasn't moved in the module hierarchy between versions. A more coarse check would be to compare only the crate names instead of full paths, but that might lead to too many false positives.
Additionally, I believe it would be helpful to show where the differing crates came from, i.e. the information in `rustc::middle::cstore::CrateSource`, but I'm not sure yet how to nicely display all of that, so I'm leaving it to a future PR.
This still does not work on 32-bit archs because of an LLVM limitation,
but this is only an optimization, so let's push it on 64-bit only for now.
Fixes#37945
Refactor pretty printing slightly
This doesn't introduce any functional changes (that I'm aware of). The primary intention here is to clean up the code a little. Each commit is intended to stand alone, reviewing commit-by-commit may be easiest.
incr.comp.: Don't include span information in the ICH of type definitions
This should improve some of the `regex` tests on perf.rlo. Not including spans into the ICH is harmless until we also cache warnings. To really solve the problem, we need to do more refactoring (see #43088).
r? @nikomatsakis
update crate dependencies
I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.
I am not sure if updating this much stuff is considered a Good Idea or not; happy to figure out how to make it smaller if someone can help me figure out how to use x.py to do it.
compilertest (UI test): Support custom normalization.
Closes#42434.
Adds this header for UI tests:
```rust
// normalize-stderr-32bit: "fn() (32 bits)" -> "fn() ($PTR bits)"
```
It will normalize the `stderr` output on 32-bit platforms, by replacing all instances of `fn() (32 bits)` by `fn() ($PTR bits)`.
Extends the UI tests in #42304 and #41968 to 32-bit targets.
r? @nikomatsakis
The literal index was increased in only next_lit, so it isn't
necessary: code now uses an iterator. The cur_cmnt field is also moved
to be increased in print_comment instead of after each call to
print_comment.
Downgrade ProjectionTy's TraitRef to its substs
Addresses the second part of #42171 by removing the `TraitRef` from
`ProjectionTy`, and directly storing its `Substs`.
Closes#42171.
Use similar compression settings as before updating to use flate2
Fixes#42879
(My first PR to rust-lang yay)
This changes the compression settings back to how they were before the change to use the flate2 crate rather than the in-tree flate library. The specific changes are to use the `Fast` compression level (which should be equivialent to what was used before), and use a raw deflate stream rather than wrapping the stream in a zlib wrapper. The [zlib](https://tools.ietf.org/html/rfc1950) wrapper adds an extra 2 bytes of header data, and 4 bytes for a checksum at the end. The change to use a faster compression level did give some compile speedups in the past (see #37298). Having to calculate a checksum also added a small overhead, which didn't exist before the change to flate2.
r? @alexcrichton
Only match a fragment specifier the if it starts with certain tokens.
When trying to match a fragment specifier, we first predict whether the current token can be matched at all. If it cannot be matched, don't bother to push the Earley item to `bb_eis`. This can fix a lot of issues which otherwise requires full backtracking (#42838).
In this PR the prediction treatment is not done for `:item`, `:stmt` and `:tt`, but it could be expanded in the future.
Fixes#24189.
Fixes#26444.
Fixes#27832.
Fixes#34030.
Fixes#35650.
Fixes#39964.
Fixes the 4th comment in #40569.
Fixes the issue blocking #40984.
