Pass the unadjusted type into the unsize_info function, which seems to be what it expects. Fixes#17322.
r? @nick29581
Full disclosure: still running make check locally ;)
After more than a month of sitting on this patch, rebasing and tracking down some nasty bugs (there's might be still one out there, but it only manifested in `middle::trans::reflect` which is now gone), I'd like to merge it as it is.
This changeset makes middle::ty safe, linking the lifetime of a type to the type context it was created in.
It's a prerequisite for introducing function-local type contexts to localize types with inference variables, in order to (potentially) free hundreds of MBs from rustc's memory usage peak.
Make old-fashioned functions in the `std::os` module utilize `IoResult`.
I'm still investigating the possibility to include more functions in this pull request. Currently, it covers `getcwd()`, `make_absolute()`, and `change_dir()`. The issues covered by this PR are #16946 and #16315.
A few concerns:
- Should we provide `OsError` in distinction from `IoError`? I'm saying this because in Python, those two are distinguished. One advantage that we keep using `IoError` is that we can make the error cascade down other functions whose return type also includes `IoError`. An example of such functions is `std::io::TempDir::new_in()`, which uses `os::make_absolute()` as well as returns `IoResult<TempDir>`.
- `os::getcwd()` uses an internal buffer whose size is 2048 bytes, which is passed to `getcwd(3)`. There is no upper limitation of file paths in the POSIX standard, but typically it is set to 4096 bytes such as in Linux. Should we increase the buffer size? One thing that makes me nervous is that the size of 2048 bytes already seems a bit excessive, thinking that in normal cases, there would be no filenames that even exceeds 512 bytes.
Fixes#16946.
Fixes#16315.
Any ideas are welcomed. Thanks!
os::change_dir() returns bool, without a meaningful error message.
Change it to return IoResult<()> to indicate what IoError caused the
failure.
Fixes#16315.
[breaking-change]
os::getcwd() panics if the current directory is not available. According
to getcwd(3), there are three cases:
- EACCES: Permission denied.
- ENOENT: The current working directory has been removed.
- ERANGE: The buffer size is less than the actual absolute path.
This commit makes os::getcwd() return IoResult<Path>, not just Path,
preventing it from panicking.
As os::make_absolute() depends on os::getcwd(), it is also modified to
return IoResult<Path>.
Fixes#16946.
[breaking-change]
Enough said.
Fixes#18639.
r? @pcwalton (or someone else?)
This is a [breaking-change]. In particular, several feature gates related to unboxed closures were consolidated into one (`overloaded_calls`, `unboxed_closure_sugar` => `unboxed_closures`). Otherwise, I think everything that worked before should still work. File a bug and cc @nikomatsakis if you find otherwise. :)
region binding at the impl site, so for method types that come from impls,
it is necessary to liberate/instantiate late-bound regions at multiple
depths.
Edit: whoops, didn't mean to hit post.
Anyway, this is something I tried to do when I first implemented cloned, but couldn't figure out. Somewhere between then and the PR actually landing, we got Deref of references, so now this works! 🎉
Also turns out the test for the functionality was never marked as a #[test]. Oops!
Also added a Cloned iterator adaptor. If this isn't desirable, it can be taken out of the PR (seperate commits).
Reduces memory usage significantly and opens opportunities for more parallel compilation.
This PR was previously #19002 but I closed it because bors didn't seem to recognize the `r+` annotations there.
The trait has an obvious, sensible implementation directly on vectors so
the MemWriter wrapper is unnecessary. This will halt the trend towards
providing all of the vector methods on MemWriter along with eliminating
the noise caused by conversions between the two types. It also provides
the useful default Writer methods on Vec<u8>.
After the type is removed and code has been migrated, it would make
sense to add a new implementation of MemWriter with seeking support. The
simple use cases can be covered with vectors alone, and ones with the
need for seeks can use a new MemWriter implementation.
The trait has an obvious, sensible implementation directly on vectors so
the MemWriter wrapper is unnecessary. This will halt the trend towards
providing all of the vector methods on MemWriter along with eliminating
the noise caused by conversions between the two types. It also provides
the useful default Writer methods on Vec<u8>.
After the type is removed and code has been migrated, it would make
sense to add a new implementation of MemWriter with seeking support. The
simple use cases can be covered with vectors alone, and ones with the
need for seeks can use a new MemWriter implementation.
