The recent pull request to remove libc from libstd has hit a wall in compiling
on windows, and I've been trying to investigate on the try bots as to why (it
compiles locally just fine). To the best of my knowledge, the LLVM section
iterator is behaving badly when iterating over the sections of the libc DLL.
Upon investigating the LLVMGetSectionName function in LLVM, I discovered that
this function doesn't always return a null-terminated string. It returns the
data pointer of a StringRef instance (LLVM's equivalent of &str essentially),
but it has no method of returning the length of the name of the section.
This commit modifies the section iteration when loading libraries to invoke a
custom LLVMRustGetSectionName which will correctly return both the length and
the data pointer.
I have not yet verified that this will fix landing liblibc, as it will require a
snapshot before doing a full test. Regardless, this is a worrisome situation
regarding the LLVM API, and should likely be fixed anyway.
Fix#13266.
There is a little bit of acrobatics in the definition of `crate_paths`
to avoid calling `clone()` on the dylib/rlib unless we actually are
going to need them.
The other oddity is that I have replaced the `root_ident: Option<&str>`
parameter with a `root: &Option<CratePaths>`, which may surprise one
who was expecting to see something like: `root: Option<&CratePaths>`.
I went with the approach here because I could not come up with code for
the alternative that was acceptable to the borrow checker.
This commit tightens up the restriction on types used to index slices to require
exactly `uint` indices. Previously any integral type was accepted, but this
leads to a few subtle problems:
* 64-bit indices don't make much sense on 32-bit systems
* Signed indices for slices used as negative indexing isn't implemented
This was discussed at the recent work week, and also has some discussion on
issue #10453.
Closes#10453
This commit deals with the fallout of the previous change by making tuples
structs have public fields where necessary (now that the fields are private by
default).
This is a continuation of the work done in #13184 to make struct fields private
by default. This commit finishes RFC 4 by making all tuple structs have private
fields by default. Note that enum variants are not affected.
A tuple struct having a private field means that it cannot be matched on in a
pattern match (both refutable and irrefutable), and it also cannot have a value
specified to be constructed. Similarly to private fields, switching the type of
a private field in a tuple struct should be able to be done in a backwards
compatible way.
The one snag that I ran into which wasn't mentioned in the RFC is that this
commit also forbids taking the value of a tuple struct constructor. For example,
this code now fails to compile:
mod a {
pub struct A(int);
}
let a: fn(int) -> a::A = a::A; //~ ERROR: first field is private
Although no fields are bound in this example, it exposes implementation details
through the type itself. For this reason, taking the value of a struct
constructor with private fields is forbidden (outside the containing module).
RFC: 0004-private-fields
This commit switches privacy's checking of fields to have *all* fields be
private by default. This does not yet change tuple structs, this only affects
structs with named fields. The fallout of this change will follow shortly.
RFC: 0004-private-fields
cc #8122Closes#11809
`collections::list::List` was decided in a [team meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2014-03-25) that it was unnecessary, so this PR removes it. Additionally, it removes an old and redundant purity test and fixes some warnings.
Only supports crate level statics. No debug info is generated for function level statics. Closes#9227.
As discussed at the end of the comments for #9227, I took an initial stab at adding support for function level statics and decided it would be enough work to warrant being split into a separate issue.
See #13144 for the new issue describing the need to add support for function level static variables.
r? @nikomatsakis
Fix#13140
Includes two fixes, and a semi-thorough regression test.
(There is another set of tests that I linked from #5121, but those are sort of all over the place, while the ones I've included here are more directly focused on the issues at hand.)
Summary:
So far, we've used the term POD "Plain Old Data" to refer to types that
can be safely copied. However, this term is not consistent with the
other built-in bounds that use verbs instead. This patch renames the Pod
kind into Copy.
RFC: 0003-opt-in-builtin-traits
Test Plan: make check
Reviewers: cmr
Differential Revision: http://phabricator.octayn.net/D3
A variety of stuff here, mostly aimed at making `make install` work correctly with `--libdir` and `--mandir`. `make install` again goes through `install.sh`.
This commit removes implicitly adding the Send bound to ~Trait objects and
procedure types. It will now be manually required to specify that a procedure
or trait must be send-able.
Closes#10296
The `_match.rs` takes advantage of passes prior to `trans` and
aggressively prunes the sub-match tree based on exact equality. When it
comes to literal or range, the strategy may lead to wrong result if
there's guard function or multiple patterns inside tuple.
Closes#12582.
Closes#13027.
This change prepares `rustc` to accept private fields by default. These changes will have to go through a snapshot before the rest of the changes can happen.
This change is in preparation for #8122. Nothing is currently done with these
visibility qualifiers, they are just parsed and accepted by the compiler.
RFC: 0004-private-fields
The problem was that we need to apply the substitution, so that the
formal lifetime parameters get replaced with (unifiable)
free-lifetimes that can actually be fed into the constraint solver.
Also, refactor code os that substitution for `check_item` and
`check_method`, moving both down the control flow into `check_bare_fn`.
----
Finally, there was another (similar) spot where we needed to
substitute early-bound lifetimes when invoking an object method of a
trait.
This is not sufficient for finding the library directory for binary
installs, but it does make the build more complex by requiring
env vars be set to build rustc.
It was possible to borrow unsafe static items in static initializers.
This patch implements a small `Visitor` that walks static initializer's
expressions and checks borrows aliasability.
Fixes#13005
cc @nikomatsakis r?
Summary:
It was possible to borrow unsafe static items in static initializers.
This patch implements a small `Visitor` that walks static initializer's
expressions and checks borrows aliasability.
Fixes#13005
Test Plan: make check
Differential Revision: http://phabricator.octayn.net/D2
Fixes#12992
Store compressed bitcode files in rlibs with a different extension. Compression doesn't interfere with --emit=bc.
Regression test compares outputs.
This needs to be removed as part of removing `~[T]`. Partial type hints
are now allowed, and will remove the need to add a version of this
method for `Vec<T>`. For now, this involves a few workarounds for
partial type hints not completely working.
These are superfluous now that we have fixed rvalue lifetimes and Deref.
I'd also like to kill off `get` and `set`, but that'll be a large change so I want to make sure that we actually want to do that first.
Replace syntax::opt_vec with syntax::owned_slice
The `owned_slice::OwnedSlice` is `(*T, uint)` (i.e. a direct equivalent to DSTs `~[T]`).
This shaves two words off the old OptVec type; and also makes substituting in other implementations easy, by removing all the mutation methods. (And also everything that's very rarely/never used.)
The compiler will no longer inject libgreen as the default runtime for rust
programs, this commit switches it over to libnative by default. Now that
libnative has baked for some time, it is ready enough to start getting more
serious usage as the default runtime for rustc generated binaries.
We've found that there isn't really a correct decision in choosing a 1:1 or M:N
runtime as a default for all applications, but it seems that a larger number of
programs today would work more reasonable with a native default rather than a
green default.
With this commit come a number of bugfixes:
* The main native task is now named "<main>"
* The main native task has the stack bounds set up properly
* #[no_uv] was renamed to #[no_start]
* The core-run-destroy test was rewritten for both libnative and libgreen and
one of the tests was modified to be more robust.
* The process-detach test was locked to libgreen because it uses signal handling
This is the first step to replacing OptVec with a new representation:
remove all mutability. Any mutations have to go via `Vec` and then make
to `OptVec`.
Many of the uses of OptVec are unnecessary now that Vec has no-alloc
emptiness (and have been converted to Vec): the only ones that really
need it are the AST and sty's (and so on) where there are a *lot* of
instances of them, and they're (mostly) immutable.
In Rust, the strongest guarantee that `&mut` provides is that the memory
pointed to is *not aliased*, whereas `&`'s guarantees are much weaker:
that the value can be aliased, and may be mutated under proper precautions
(interior mutability).
Our atomics though use `&mut` for mutation even while creating multiple
aliases, so this changes them to use 'interior mutability', mutating
through immutable references.
Most of the standard distribution is still using ~[] instead of Vec, so this
lint is essentially useless currently. When the standard distribution has been
ported to not use ~[], then we can turn the lint back on.
Previously, any library of the pattern `lib<name>-<hash>-<version>.so` was
>considered a candidate (rightly so) for loading a crate. Sets are generated for
each unique `<hash>`, and then from these sets a candidate is selected. If a set
contained more than one element, then it immediately generated an error saying
that multiple copies of the same dylib were found.
This is incorrect because each candidate needs to be validated to actually
contain a rust library (valid metadata). This commit alters the logic to filter
each set of candidates for a hash to only libraries which are actually rust
libraries. This means that if multiple false positives are found with the right
name pattern, they're all ignored.
Closes#13010
`Share` implies that all *reachable* content is *threadsafe*.
Threadsafe is defined as "exposing no operation that permits a data race if multiple threads have access to a &T pointer simultaneously". (NB: the type system should guarantee that if you have access to memory via a &T pointer, the only other way to gain access to that memory is through another &T pointer)...
Fixes#11781
cc #12577
What this PR will do
================
- [x] Add Share kind and
- [x] Replace usages of Freeze with Share in bounds.
- [x] Add Unsafe<T> #12577
- [x] Forbid taking the address of a immutable static item with `Unsafe<T>` interior
What's left to do in a separate PR (after the snapshot)?
===========================================
- Remove `Freeze` completely
These variants occur rarely but inflate the whole enum for the other variants, leaving a lot of wasted space. In total this reduces `ty::sty` from 160 bytes to 96 (on a 64-bit platform).
After this, `ty_struct` and `ty_enum` are the largest variants, with the 80-byte `substs` being the major contributor.
Previously, any library of the pattern `lib<name>-<hash>-<version>.so` was
>considered a candidate (rightly so) for loading a crate. Sets are generated for
each unique `<hash>`, and then from these sets a candidate is selected. If a set
contained more than one element, then it immediately generated an error saying
that multiple copies of the same dylib were found.
This is incorrect because each candidate needs to be validated to actually
contain a rust library (valid metadata). This commit alters the logic to filter
each set of candidates for a hash to only libraries which are actually rust
libraries. This means that if multiple false positives are found with the right
name pattern, they're all ignored.
Closes#13010
This fixes struct passing abi on x86 ffi: Structs are now passed
indirectly with byval attribute (as clang does).
Empty structs are also explicitly ignored rather than directly passed.
Fixes#5744Fixes#11198Fixes#11343
This reduces the size of sty from 112 to 96; like with the ty_trait
variant, this variant of sty occurs rarely (~1%) so the benefits are
large and the costs small.
This reduces ty::sty from 160 bytes to just 112, and some measurements
eddyb made suggest that the ty_trait variant occurs very
rarely (e.g. ~1% of all sty instances) hence this will result in a large
memory saving, and the cost of the indirection is unlikely to be an
issue.
