It's surprising that `RefCell::get()` is implicitly doing a clone
on a value. This patch removes it and replaces all users with
either `.borrow()` when we can autoderef, or `.borrow().clone()`
when we cannot.
This was missed when dropping the null-termination from our string
types. An explicit null byte can still be placed anywhere in a string if
desired, but there's no reason to stick one at the end of every string
constant.
Closes#13285 (rustc: Stop using LLVMGetSectionName)
Closes#13280 (std: override clone_from for Vec.)
Closes#13277 (serialize: add a few missing pubs to base64)
Closes#13275 (Add and remove some ignore-win32 flags)
Closes#13273 (Removed managed boxes from libarena.)
Closes#13270 (Minor copy-editing for the tutorial)
Closes#13267 (fix Option<~ZeroSizeType>)
Closes#13265 (Update emacs mode to support new `#![inner(attribute)]` syntax.)
Closes#13263 (syntax: Remove AbiSet, use one Abi)
This change removes the AbiSet from the AST, converting all usage to have just
one Abi value. The current scheme selects a relevant ABI given a list of ABIs
based on the target architecture and how relevant each ABI is to that
architecture.
Instead of this mildly complicated scheme, only one ABI will be allowed in abi
strings, and pseudo-abis will be created for special cases as necessary. For
example the "system" abi exists for stdcall on win32 and C on win64.
Closes#10049
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
