libsyntax: Add `parse_view_item` method to Parser
libsyntax: Add tests for `parse_view_item`
Make os::getcwd() return IoResult<Path>

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]
Make os::change_dir() return IoResult<()>

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]
Make os::setenv() and os::unsetenv() panic if an error occurs

These functions can fail if:

- EINVAL: The name is empty, or contains an '=' character
- ENOMEM: Insufficient memory
auto merge of #18870 : barosl/rust/os-ioresult, r=alexcrichton

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!
auto merge of #19044 : murarth/rust/libsyntax-view-item, r=alexcrichton

Allows parsing view items (`use` and `extern crate`) individually. Does not change behavior of any existing functions.

Closes #19024
rustc: avoid `use`-ing `syntax::ast::*`.
rustc: middle: rename `ty::t` to `Ty` and use it unqualified everywhere.
rustc: middle: ty: replace unsafe pointers with references in Ty.
rustc: fix fallout of adding the `'tcx` lifetime to `Ty`.
rustc: fix fallout of making `Ty` an alias for `&TyS` instead of a wrapper.
rustc: middle: avoid clones in ty_fn_{sig,args}.
rustc: middle: remove obsolete ty::get.
rustc: middle: simplify primitive type declaration in ty.
rustdoc: fix fallout of ty::t -> Ty<'tcx>.
auto merge of #18483 : eddyb/rust/safe-ty, r=nikomatsakis

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.