Hopefully this pacifies the 32bit windows. Apparently there’s an ABI out there that not only allows
non-64 bit variadic arguments, but also has differing ABI for them!
Good thing all variadic functions are unsafe.
The only applies to pthread mutexes. We solve this by creating the
mutex with the PTHREAD_MUTEX_NORMAL type, which guarantees that
re-locking from the same thread will deadlock.
Fix a few links in the book
Links to directories and direct links to doc.rust-lang.org don't work properly
when viewing the docs offline so fix them.
r? @steveklabnik
Restore original meaning of std::fs::read_dir's example changed in #33958
`DirEntry.file_type().is_dir()` will not follow symlinks, but the original example (`fs::metadata(&path).is_dir()`) does. Therefore the change in #33958 introduced a subtle difference that now it won't enter linked folders. To preserve the same behavior, we use `Path::is_dir()` instead, which does follow symlink.
(See discussion in the previous PR for detail.)
Implement split_off for BTreeMap and BTreeSet (RFC 509)
Fixes#19986 and refactors common with append methods.
It splits the tree with O(log n) operations and then calculates sizes by traversing the lower one.
CC @gereeter
Open code the __fastfail intrinsic for rtabort! on windows
As described https://msdn.microsoft.com/en-us/library/dn774154.aspx
This is a Windows 8+ mechanism for terminating the process quickly,
which degrades to either an access violation or bugcheck in older versions.
I'm not sure this is better the the current mechanism of terminating
with an illegal instruction, but we recently converted unix to
terminate more correctly with SIGABORT, and this *seems* more correct
for windows.
[breaking-change]
DirEntry.file_type().is_dir() will not follow symlinks, but the original
example (fs::metadata(&path).is_dir()) does. Therefore the change in
#33958 introduced a subtle difference that now it won't enter linked
folders. To preserve the same behavior, we use Path::is_dir() instead,
which does follow symlink.
Add AST validation pass and move some checks to it
The purpose of this pass is to catch constructions that fit into AST data structures, but not permitted by the language. As an example, `impl`s don't have visibilities, but for convenience and uniformity with other items they are represented with a structure `Item` which has `Visibility` field.
This pass is intended to run after expansion of macros and syntax extensions (and before lowering to HIR), so it can catch erroneous constructions that were generated by them. This pass allows to remove ad hoc semantic checks from the parser, which can be overruled by syntax extensions and occasionally macros.
The checks can be put here if they are simple, local, don't require results of any complex analysis like name resolution or type checking and maybe don't logically fall into other passes. I expect most of errors generated by this pass to be non-fatal and allowing the compilation to proceed.
I intend to move some more checks to this pass later and maybe extend it with new checks, like, for example, identifier validity. Given that syntax extensions are going to be stabilized in the measurable future, it's important that they would not be able to subvert usual language rules.
In this patch I've added two new checks - a check for labels named `'static` and a check for lifetimes and labels named `'_`. The first one gives a hard error, the second one - a future compatibility warning.
Fixes https://github.com/rust-lang/rust/issues/33059 ([breaking-change])
cc https://github.com/rust-lang/rfcs/pull/1177
r? @nrc
stable features lint warning mentions version stabilized
To accomplish this, we alter the checks in `rustc::middle::stability` to
use the `StabilityLevel` defined in `syntax::attr` (which includes the
version in which the feature was stabilized) rather than the local
`StabilityLevel` in the same module, and make the
`declared_stable_lang_features` field of
`syntax::feature_gate::Features` hold a Vec of feature-name, span
tuples (in analogy to the `declared_lib_features` field) rather than
just spans.
Fixes#33394.
r? @brson (tagging Brian because he [wrote](https://github.com/rust-lang/rust/pull/21958) the lint)
resolve: record pattern def when `resolve_pattern` returns `Err(true)`
I propose a fix for issue #33293.
In 1a374b8, (pr #33046) fixed the error reporting of a specific case, but the change that was introduced did not make sure that `record_def` was called in all cases, which lead to an ICE in [1].
This change restores the original `else` case, but keeps the changes that were committed in 1a374b8.
[1] `rustc::middle::mem_categorization::MemCategorizationContext::cat_pattern_`
Inline simple Cursor write calls
Implementing the Write trait for Cursors over slices is so light-weight that under some circumstances multiple writes can be fused into a single instruction. In general I think inlining these functions is a good idea because most of the code can be constant-folded and copy-propagated away.
Closes issue #33916.
r? @alexcrichton
core: check pointer equality when comparing byte slices
If pointer address and length are the same, it should be the same slice.
In experiments, I've seen that this doesn't happen as often in debug builds, but release builds seem to optimize to using a single pointer more often.
Reject a LHS formed of a single sequence TT during `macro_rules!` checking.
This was already rejected during expansion. Encountering malformed LHS or RHS during expansion is now considered a bug.
Follow up to #33689.
r? @pnkfelix
Note: this can break code that defines such macros but does not use them.
