Don't always run `add_call_guards` pass
It is only needed when `add_retag` runs.
(the pass is run again to split critical edges before codegen, that one is required)
The ioctl(FIONBIO) method of setting a file descriptor to be
non-blocking does not notify the underlying resource in the same way
that fcntl(F_SETFL, O_NONBLOCK) does on illumos and Solaris.
Rollup of 8 pull requests
Successful merges:
- #70657 (Allow `try`-blocks in places where an open delim is expected)
- #70947 (tighten CTFE safety net for accesses to globals)
- #70949 (simplify `vec!` macro)
- #71002 (fix target & runtool args order)
- #71082 (ptr: introduce len() method on raw slices)
- #71128 (Remove unused single_step flag)
- #71133 (Tighten time complexity on the doc of sort_by_key)
- #71135 (Update books)
Failed merges:
r? @ghost
Remove unused single_step flag
This appears to have never been used ever since its introduction in 61c7569d4 --
the plugin discussed on the PR introducing that commit, 34811, never
materialized.
It's also simple to re-add in the current scheme, but given that macro expansion
is already quite complicated, additional useless state seems good to remove
while we're not using it.
ptr: introduce len() method on raw slices
It is already possible to extract the pointer part of a raw slice by a
simple cast, but retrieving the length is not possible without relying
on the representation of the raw slice when it is not valid to convert
the raw slice into a slice reference (i.e. the pointer is null or
unaligned).
~Introduce a new function ptr::slice_len() to add this missing feature.~
Introduce a len() method on raw slices to add this missing feature.
fix target & runtool args order
- `TargetTripple::to_string` converts "path triples" to `<target>-<hash>`, but in this case we need the path. Afaict there is no method to get the real triple other than manually matching
- the order of the runtools arguments is inconsistent with the way tests usually pass arguments ie using `runner` key in `.cargo/config`
simplify `vec!` macro
Simplify `vec!` macro by replacing 2 following branches:
- `($($x:expr),*) => (...)`
- `($($x:expr,)*) => (...)`
with one:
- `($($x:expr),* $(,)?) => (...)`
This is a minor change, however, this will make the documentation cleaner
tighten CTFE safety net for accesses to globals
Previously, we only rejected reading from all statics. Now we also reject reading from any mutable global. Mutable globals are the true culprit here as their run-time value might be different from their compile-time values. Statics are just the approximation we use for that so far.
Also refactor the code a bit to make it clearer what is being checked and allowed.
r? @oli-obk
typeck: always expose repeat count `AnonConst`s' parent in `generics_of`.
This should reduce some of the confusion around #43408, although, if you look at the changed test outputs (for the last commit), they all hit #68436, so nothing new will start compiling.
We can let counts of "repeat expressions" (`N` in `[x; N]`) always have the correct generics parenting, because they're always in a body, so nothing in the `where` clauses or `impl` trait/type of the parent can use it, and therefore no query cycles can occur.
<hr/>
Other potential candidates we might want to apply the same approach to, are:
* ~~(easy) `enum` discriminants (see also #70453)~~ opened #70825
* (trickier) array *type* (not *expression*) lengths nested in:
* bodies
* types of (associated or not) `const`/`static`
* RHS of `type` aliases and associated `type`s
* `fn` signatures
We should've done so from the start, the only reason we haven't is because I was squeamish about blacklisting some of the cases, but if we whitelist instead we should be fine.
Also, lazy normalization is taking forever 😞.
<hr/>
There's also 5 other commits here:
* "typeck: track any errors injected during writeback and taint tables appropriately." - fixes#66706, as the next commit would otherwise trigger an ICE again
* "typeck: workaround WF hole in `to_const`." - its purpose is to emulate most of #70107's direct effect, at least in the case of repeat expressions, where the count always goes through `to_const`
* this is the reason no new code can really compile, as the WF checks require #68436 to bypass
* however, this has more test changes than I hoped, so it should be reviewed separately, and maybe even landed separately (as #70107 might take a while, as it's blocked on a few of my PRs)
* "ty: erase lifetimes early in `ty::Const::eval`." - first attempt at fixing #70773
* still useful, I believe the new approach is less likely to cause issues long-term
* I could take this out or move it into another PR if desired or someone else could take over (cc @skinny121)
* "traits/query/normalize: add some `debug!` logging for the result." - debugging aid for #70773
* "borrow_check/type_check: normalize `Aggregate` and `Call` operands." - actually fixes#70773
r? @nikomatsakis cc @pnkfelix @varkor @yodaldevoid @oli-obk @estebank
It is already possible to extract the pointer part of a raw slice by a
simple cast, but retrieving the length is not possible without relying
on the representation of the raw slice when it is not valid to convert
the raw slice into a slice reference (i.e. the pointer is null or
unaligned).
Introduce a len() method on raw slices to add this missing feature.
This appears to have never been used ever since its introduction in 61c7569d4 --
the plugin discussed on the PR introducing that commit, 34811, never
materialized.
It's also simple to readd in the current scheme, but given that macro expansion
is already quite complicated, additional useless state seems good to remove
while we're not using it.
incremental compilation.
This is symmetric to PR #67020, which handled the case where the LLVM module's
*imports* changed. This commit builds upon the infrastructure added there; the
export map is just the inverse of the import map, so we can build the export map
at the same time that we load the serialized import map.
Fix#69798
Remove the last remnant of unsigned Neg
It's been gone since #23945, before Rust 1.0. The former wrapping
semantics have also been available as inherent methods for a long time
now. There's no reason to keep this unused macro around.
