This includes a slight refactoring of the `cast_shift_rhs` and related
functions in `trans::base`, so that I can call them from much later in
the compiler's control flow (so that we can clearly dilineate where
automatic conversions of the RHS occur, versus where we check it).
The rhs-checking and fallback-masking is generalized to 8- and 16-bit
values, and the fallback-masking is turned on unconditionally.
Fix#10183.
Is this a [breaking-change]? I would argue it is not; it only adds a
strict definition to what was previously undefined behavior; however,
there might be code that was e.g. assuming that `1_i8 << 17` yields 0.
(This happens in certain contexts and at certain optimization levels.)
This commit stabilizes the `ErrorKind` enumeration which is consumed by and
generated by the `io::Error` type. The purpose of this type is to serve as a
cross-platform namespace to categorize errors into. Two specific issues are
addressed as part of this stablization:
* The naming of each variant was scrutinized and some were tweaked. An example
is how `FileNotFound` was renamed to simply `NotFound`. These names should not
show either a Unix or Windows bias and the set of names is intended to grow
over time. For now the names will likely largely consist of those errors
generated by the I/O APIs in the standard library.
* The mapping of OS error codes onto kinds has been altered. Coalescing no
longer occurs (multiple error codes become one kind). It is intended that each
OS error code, if bound, corresponds to only one `ErrorKind`. The current set
of error kinds was expanded slightly to include some networking errors.
This commit also adds a `raw_os_error` function which returns an `Option<i32>`
to extract the underlying raw error code from the `Error`.
Closes#16666
[breaking-change]
This commit stabilizes the `ErrorKind` enumeration which is consumed by and
generated by the `io::Error` type. The purpose of this type is to serve as a
cross-platform namespace to categorize errors into. Two specific issues are
addressed as part of this stablization:
* The naming of each variant was scrutinized and some were tweaked. An example
is how `FileNotFound` was renamed to simply `NotFound`. These names should not
show either a Unix or Windows bias and the set of names is intended to grow
over time. For now the names will likely largely consist of those errors
generated by the I/O APIs in the standard library.
* The mapping of OS error codes onto kinds has been altered. Coalescing no
longer occurs (multiple error codes become one kind). It is intended that each
OS error code, if bound, corresponds to only one `ErrorKind`. The current set
of error kinds was expanded slightly to include some networking errors.
This commit also adds a `raw_os_error` function which returns an `Option<i32>`
to extract the underlying raw error code from the `Error`.
* rustdoc was doubly appending the file name to the path of where to
generate the source files, meanwhile, the [src] hyperlinks were not
* Added a flag to rustdoc::html::render::clean_srcpath to ignore the
last path component, i.e. the file name itself to prevent the issue
* This also avoids creating directories with the same name as source
files, and it makes sure the link to `main.css` is correct as well.
Fixes#23192
I often have to run `ast-json` or look into the pretty-printer source to figure out what the fields of an AST enum mean. I've tried to document most of what I know (and some semi-obvious stuff).
r? @steveklabnik
f? @eddyb
unbreak openbsd/bitrig build
- remove `pub` from `struct` (error: visibility has no effect inside functions)
- move `pthread_main_np` into function
r? @alexcrichton
Require braces when a closure has an explicit return type. This is a [breaking-change]: instead of a closure like `|| -> i32 22`, prefer `|| -> i32 { 22 }`.
Fixes#23420.
Nothing inside of the read/write interface itself can panic, so any
poison must have been the result of user code which the lock isn't
protecting.
This seems safe to me, but if we don't want to go this route we should update the docs to indicate that these methods can panic.
r? @alexcrichton
This commit stabilizes the `cloned` iterator after tweaking the signature to
require that the iterator is over `&T` instead of `U: Deref<T>`. This method has
had time to bake for awhile now and it's not clear whether the `Deref` bound is
worth it. Additionally, there aren't clear conventions on when to bound and/or
implement the `Deref` trait, so for now the conservative route is to require
references instead of `U: Deref<T>`.
To change this signature to using `Deref` would technically be a
backwards-incompatible change, but it is doubtful that any code will actually
break in practice.
Hopefully didn’t miss or mess up anything.
~~EDIT: ah, as usual, just didn’t bother running build before pushing a submit request button. Build pending.~~
* rustdoc was doubly appending the file name to the path of where to
generate the source files, meanwhile, the [src] hyperlinks were not
* Added a flag to rustdoc::html::render::clean_srcpath to ignore the
last path component, i.e. the file name itself to prevent the issue
* This also avoids creating directories with the same name as source
files, and it makes sure the link to `main.css` is correct as well.
* Added regression tests to ensure the rustdoc heirarchy of rendered
source files remains consistent
Fixes#23192
I often have to run `ast-json` or look into the pretty-printer source to figure out what the fields of an AST enum mean. I've tried to document most of what I know (and some semi-obvious stuff).
r? @steveklabnik
f? @eddyb
The alignment field is actually a \"pointer sized\" type instead of always i64,
requiring that the size of the padding field is also calculated slightly
differently.
Closes#23425
Very minor fix: in `std::net::Ipv6Addr::new`, the documentation had an incomplete representation of the resulting address, missing the last two groups.
This commit clarifies some of the unstable features in the `str` module by
moving them out of the blanket `core` and `collections` features.
The following methods were moved to the `str_char` feature which generally
encompasses decoding specific characters from a `str` and dealing with the
result. It is unclear if any of these methods need to be stabilized for 1.0 and
the most conservative route for now is to continue providing them but to leave
them as unstable under a more specific name.
* `is_char_boundary`
* `char_at`
* `char_range_at`
* `char_at_reverse`
* `char_range_at_reverse`
* `slice_shift_char`
The following methods were moved into the generic `unicode` feature as they are
specifically enabled by the `unicode` crate itself.
* `nfd_chars`
* `nfkd_chars`
* `nfc_chars`
* `graphemes`
* `grapheme_indices`
* `width`
