diff options
| author | Mazdak Farrokhzad <twingoow@gmail.com> | 2019-04-25 03:05:25 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-04-25 03:05:25 +0200 |
| commit | 3fffcd33141da118c0224914bf9418ba9c37d157 (patch) | |
| tree | 9b6ddd5820ccba213652b3fb3ae6e48965b8c501 /src/test/incremental/thinlto | |
| parent | a4ef188ab6008c6f600e06a7e01e81f75370d574 (diff) | |
| parent | 7af0fccc88127619ec7e0fa695437525678db0b2 (diff) | |
| download | rust-3fffcd33141da118c0224914bf9418ba9c37d157.tar.gz rust-3fffcd33141da118c0224914bf9418ba9c37d157.zip | |
Rollup merge of #60185 - NieDzejkob:int-error-kind-reexport, r=rkruppe
Reexport IntErrorKind in std Currently `IntErrorKind` can only be found in `core`. @Centril confirmed on Discord that this is unintentional (should I r? him in this situation?). Should there be a test for this? As far as this *specific* situation goes, I don't think so, I'll risk it and say that there's no way this regresses. However, it might be a good idea to have some tool detect public items in `core` that are not reexported in `std`. Does this belong in tidy, or should that be a separate tool? Is there some rustc-specific *linter*? Unless that's entirely a dumb idea, this should probably get an issue. Note: My local build hasn't finished yet, but it's well past the point where I would expect problems.
Diffstat (limited to 'src/test/incremental/thinlto')
0 files changed, 0 insertions, 0 deletions