summaryrefslogtreecommitdiff
path: root/compiler/parser/cutils.c
Commit message (Collapse)AuthorAgeFilesLines
* Minor refactor in ghc.cabal.in:Ömer Sinan Ağacan2019-12-261-24/+0
| | | | | | - Remove outdated comments - Move cutils.c from parser to cbits - Remove unused cutils.h
* Clean up `#include`s in the compilerJohn Ericson2019-10-051-2/+2
| | | | | | | | - Remove unneeded ones - Use <..> for inter-package. Besides general clean up, helps distinguish between the RTS we link against vs the RTS we compile for.
* Remove unused `#include`s from parser/cutils.cJohn Ericson2019-09-121-6/+0
| | | | | Looks like these have been unused since 7c665f9ce0980ee7c81a44c8f861686395637453.
* Refactor LitStringSylvain Henry2018-05-131-17/+0
| | | | | | | | | | | | | | | | | | Refactor LitString so that the string length is computed at most once and then stored. Also remove strlen and memcmp wrappers (it seems like they were a workaround for a very old GCC when using -fvia-C). Bumps haddock submodule. Reviewers: bgamari, dfeuer, nickkuk Reviewed By: bgamari, nickkuk Subscribers: nickkuk, dfeuer, thomie, carter Differential Revision: https://phabricator.haskell.org/D4630
* Prefer #if defined to #ifdefBen Gamari2017-04-281-1/+1
| | | | Our new CPP linter enforces this.
* compiler/parser/cutils: drop unused 'ghc_memcmp_off' helperSergei Trofimovich2015-01-201-6/+0
| | | | | | | | | | | | | | | Function came out of use in 2006: > commit 9d7da331989abcd1844e9d03b8d1e4163796fa85 > Author: simonmar <unknown> > Date: Fri Jan 6 16:30:19 2006 +0000 > > [project @ 2006-01-06 16:30:17 by simonmar] > Add support for UTF-8 source files Found by uselex.rb: ghc_memcmp_off: [R]: exported from: ./compiler/stage1/build/parser/cutils.o ./compiler/stage2/build/parser/cutils.o Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* parser: detabify/dewhitespace cutils.cAustin Seipp2014-07-201-5/+3
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Remove code that is dead now that we need >= 6.12 to buildIan Lynagh2010-12-151-3/+0
|
* RTS tidyup sweep, first phaseSimon Marlow2009-08-021-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first phase of this tidyup is focussed on the header files, and in particular making sure we are exposinng publicly exactly what we need to, and no more. - Rts.h now includes everything that the RTS exposes publicly, rather than a random subset of it. - Most of the public header files have moved into subdirectories, and many of them have been renamed. But clients should not need to include any of the other headers directly, just #include the main public headers: Rts.h, HsFFI.h, RtsAPI.h. - All the headers needed for via-C compilation have moved into the stg subdirectory, which is self-contained. Most of the headers for the rest of the RTS APIs have moved into the rts subdirectory. - I left MachDeps.h where it is, because it is so widely used in Haskell code. - I left a deprecated stub for RtsFlags.h in place. The flag structures are now exposed by Rts.h. - Various internal APIs are no longer exposed by public header files. - Various bits of dead code and declarations have been removed - More gcc warnings are turned on, and the RTS code is more warning-clean. - More source files #include "PosixSource.h", and hence only use standard POSIX (1003.1c-1995) interfaces. There is a lot more tidying up still to do, this is just the first pass. I also intend to standardise the names for external RTS APIs (e.g use the rts_ prefix consistently), and declare the internal APIs as hidden for shared libraries.
* Remove code that is dead, as we require __GLASGOW_HASKELL__ >= 504Ian Lynagh2007-04-061-14/+0
|
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+70
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.