Previously this was an Option::unwrap() which failed for me.
Unfortunately I've since inadvertently worked around the bug and have
been unable to reproduce it. With this patch hopefully the next person
to encounter this will be in a slightly better position to debug it.
* Deprecated `str::from_utf8_owned` in favor of `String::from_utf8`
* Deprecated `str::from_utf8_lossy` in favor of `String::from_utf8_lossy`
* Deprecated `str::from_utf16` in favor of `String::from_utf16`
* Deprecated `str::from_utf16_lossy` in favor of `String::from_utf16_lossy`
* Deprecated `str::from_chars` in favor of `String::from_chars`
* Deprecated `str::from_char` in favor of `String::from_char` and `.to_string()`
* Deprecated `str::from_byte` in favor of `String::from_byte`
[breaking-change]
Use one or more of the following `-Z` flag options to tell the
graphviz renderer to include the corresponding dataflow sets (after
the iterative constraint propagation reaches a fixed-point solution):
* `-Z flowgraph-print-loans` : loans computed via middle::borrowck
* `-Z flowgraph-print-moves` : moves computed via middle::borrowck::move_data
* `-Z flowgraph-print-assigns` : assignments, via middle::borrowck::move_data
* `-Z flowgraph-print-all` : all of the available sets are included.
Fix#15016.
Use one or more of the following `-Z` flag options to tell the
graphviz renderer to include the corresponding dataflow sets (after
the iterative constraint propagation reaches a fixed-point solution):
* `-Z flowgraph-print-loans` : loans computed via middle::borrowck
* `-Z flowgraph-print-moves` : moves computed via middle::borrowck::move_data
* `-Z flowgraph-print-assigns` : assignments, via middle::borrowck::move_data
* `-Z flowgraph-print-all` : all of the available sets are included.
Fix#15016.
----
This also adds a module, `syntax::ast_map::blocks`, that captures a
common abstraction shared amongst code blocks and procedure-like
things. As part of this, moved `ast_map.rs` to subdir
`ast_map/mod.rs`, to follow our directory layout conventions.
(incorporated review feedback from huon, acrichto.)
This was my weekend project, to start breaking up rustc. It first pulls out LLVM into `rustc_llvm`, then parts of `rustc::back` and `rustc::util` to `rustc_back`. The immediate intent is just to reduce the size of rustc, to reduce memory pressure when building rustc, but this is also a good starting point for further refactoring.
The `rustc_back` crate is definitely misnamed (`rustc::back` was never a very cohesive module anyway) - it's mostly just somewhere to stuff parts of rustc that don't have many deps. Right now it's main dep is `syntax`; it has no dep on `rustc_llvm`.
Some next steps might be to split `rustc_back` into `rustc_util` (with no `syntax` dep), and `rustc_syntax_util` (with a syntax dep); move the rest of `rustc::util` into `rustc_syntax_util`; move all of `rustc::front` to a new crate, `rustc_front`. At that point the refactoring necessary to keep extracting crates will get harder.
Currently when a read-only file has unlink() invoked on it on windows, the call
will fail. On unix, however, the call will succeed. In order to have a more
consistent behavior across platforms, this error is recognized on windows and
the file is changed to read-write before removal is attempted.
Currently when a read-only file has unlink() invoked on it on windows, the call
will fail. On unix, however, the call will succeed. In order to have a more
consistent behavior across platforms, this error is recognized on windows and
the file is changed to read-write before removal is attempted.
Not sure how to test this correctly I assume the current tests pass now because of the crate boundaries [and that this is fallout from private by default]?
In order to have the spawning semantics be the same for unix/windows, the
child's PATH environment variable needs to be searched rather than the parent's
environment variable.
If the child is inheriting the parent's PATH, then no action need be taken as
windows will do the heavy lifting. If the child specifies its own PATH, then it
is searched beforehand for the target program and the result is favored if a hit
is found.
cc #15149, but does not close the issue because libgreen still needs to be
updated.
In order to have the spawning semantics be the same for unix/windows, the
child's PATH environment variable needs to be searched rather than the parent's
environment variable.
If the child is inheriting the parent's PATH, then no action need be taken as
windows will do the heavy lifting. If the child specifies its own PATH, then it
is searched beforehand for the target program and the result is favored if a hit
is found.
cc #15149, but does not close the issue because libgreen still needs to be
updated.
